Azure Cloud Services (Extended Support) udfases 31. marts 2027: sådan flytter I web- og workerroller

Microsoft udfasede Azure Cloud Services (extended support) 31. marts 2025 og lukker den helt 31. marts 2027. Kører en af jeres forretningsapplikationer som webroller og workerroller, skal den køre et andet sted i Azure før den dato. FAQ'en om udfasningen er ligefrem om de to spørgsmål, alle stiller først: Microsoft »kan ikke imødekomme anmodninger om forlængelse«, og »der findes intet migreringsværktøj med ét klik«.

Fra i dag, 3. oktober 2026, efterlader det seks måneder.

Hvem det her er til

Det typiske tilfælde: en ASP.NET-applikation på .NET Framework, en webrolle foran og en eller to workerroller, der behandler køer bagved, bygget af et bureau for otte eller ti år siden. Bureauet er ofte gået videre, applikationen kører stadig ordrebehandling eller en kundeportal, og ingen har åbnet .csdef-filen siden sidste migrering.

For at tjekke, om I er berørt, så åbn Azure-portalen og list ressourcer af typen »Cloud services (extended support)«. Microsofts meddelelse om udfasningen linker direkte til den visning. Er den tom, er I færdige.

Denne artikel handler ikke om Cloud Services (classic), som blev udfaset i 2024. Hoster en leverandør produktet for jer, er migreringen leverandørens opgave: bed om deres dato skriftligt. Alt nedenfor er til teams, der ejer koden, eller ejer den på papiret og skal finde en, der forstår den.

Hvorfor det er sværere end flytningen i 2024

Mange virksomheder flyttede til extended support i 2024, da classic blev udfaset. Den flytning var billig med vilje. Microsofts oversigt over extended support siger, at filerne .csdef, .cscfg og .cspkg »føres videre, og formaterne ændres ikke«, og at »der kræves ingen ændringer i runtimekoden«. Der fandtes endda en migrering på stedet. Samme side anbefalede extended support til applikationer, der ikke videreudvikles, fordi »den giver en hurtig migreringsvej«.

Denne gang findes der intet tilsvarende mål. Med Microsofts ord handler Cloud Services »om at udrulle applikationer som VM'er. Den kode, I skriver, er tæt koblet til en VM-instans«. Jeres kode ved, at den kører i en rolle. Den læser konfiguration fra rollen, finder diskplads gennem rollen, får certifikater installeret af rollen og kører opsætningsscripts som administrator, før rollen starter. Alt det skal erstattes.

Én ting mere, før I læser den officielle vejledning. Microsofts meddelelse om udfasningen og FAQ'en nævner én destination, Service Fabric managed cluster. Oversigtssiden nævner fem, og Microsofts egen beslutningsmatrix for migrering sammenligner syv. Service Fabric er et standardvalg, ikke et krav, og for mange webroller er det det forkerte.

Målene, og hvornår hvert passer

Web- og workerroller behøver ikke lande samme sted. Vælg et mål pr. rolle.

App Service (Windows). Det nærmeste, man kommer en webrolle for en ASP.NET-applikation. Windows-instanser leveres med de understøttede .NET Framework-versioner installeret, så Web Forms og MVC 5 kører uden omskrivning. Workerroller kan følge med som WebJobs, der kører »i samme instans som en webapp« uden ekstra omkostning. Begrænsningen er selve maskinen: Microsoft sender apps, der har brug for COM-komponenter, adgang til registreringsdatabasen eller MSI-installationsprogrammer, videre til Managed Instance, så forhøjede opstartsopgaver har ingen steder at gå hen på en standardplan.

App Service Managed Instance. Bygget til ældre Windows-webapps. Ifølge Microsofts oversigt er den »generelt tilgængelig for Windows-webapps i udvalgte regioner«, begrænset til planerne Pv4 og Pmv4, med .NET Framework 3.5 og 4.8 forudinstalleret og PowerShell-installationsscripts, der kan registrere COM-komponenter, skrive nøgler i registreringsdatabasen, køre MSI-installationsprogrammer og konfigurere IIS. Det dækker det meste af, hvad forhøjede opstartsopgaver gjorde. Begrænsningerne: kun webapps (ingen WebJobs), ingen containere, kun Entra ID og managed identity (ingen domænetilmelding, NTLM eller Kerberos), og da dette skrives, er North Europe den eneste europæiske region på listen.

Container Apps. God til workerroller, når de først er på moderne .NET: købaseret skalering, planlagte og hændelsesudløste job, skalering til nul. Men kravene til containere siger: »Linux-baserede containerimages (linux/amd64) er påkrævet.« Kode på .NET Framework kører ikke dér, før den er porteret.

Azure Kubernetes Service. Kører Windows Server-containere i Windows-nodepuljer, så en .NET Framework-rolle kan containeriseres og flyttes. Beslutningsmatrixen vurderer både migreringskompleksiteten og driftsbyrden som høj. Den passer, hvis I allerede kører Kubernetes, ikke som første cluster til én ældre app.

Virtual Machine Scale Sets. Matrixen kalder det »tættere på Cloud Services-modellen og med lettere lift-and-shift«. I får VM'en tilbage, sammen med patching, opbygning af images og den IIS-opsætning, som rollen tidligere klarede for jer.

Service Fabric managed cluster. Microsofts navngivne destination. Workerroller passer pænt ind. Webroller gør ofte ikke: Service Fabric »understøtter ikke IIS«, og konverteringsvejledningen opfører ASP.NET Web Forms som ikke understøttet, med konvertering til ASP.NET Core MVC som vejen. Migreringsvejledningen til Service Fabric tilføjer, at managed clusters »i øjeblikket ikke understøtter containere«, så en app, der afhænger af IIS, kræver et traditionelt cluster med mere at drive.

Beslutningstabel

Hvad der ændres i koden

Søg i løsningen efter Microsoft.WindowsAzure.ServiceRuntime. Hver fil, der importerer det, står på listen.

RoleEntryPoint

En workerrolle er en klasse, der arver fra RoleEntryPoint og overskriver OnStart, Run og OnStop. Returnerer Run, genstartes instansen. Service Fabric samler alle tre i én RunAsync, der skal stoppe, »når RunAsync-metodens CancellationToken signaleres«. På App Service eller i en container bliver samme logik til en konsolapplikation eller en hostet baggrundstjeneste med en løkke og et cancellation token.

Det, folk overser, er nedlukningen. OnStop gav jer et øjeblik til at gøre den aktuelle besked færdig. Sørg for, at den nye vært sender et annulleringssignal videre, og at en besked, der efterlades midt i behandlingen, kan behandles to gange uden skade.

Webroller har ofte også en, typisk WebRole.cs. Gør dens OnStart noget (IIS-justeringer, opvarmning af cache), så find ud af hvad, før I sletter den.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") læser indstillinger fra .cscfg. Intet uden for Cloud Services leverer den. Før I flytter noget, så pak hvert kald ind i én lille konfigurationsgrænseflade, og peg derefter den grænseflade på app settings, miljøvariabler eller Key Vault på den nye vært. Det er den billigste ændring i projektet, og den gør resten testbart på en bærbar.

Tre andre anvendelser at kigge efter:

• RoleEnvironment.Changed, som anvendte konfigurationsændringer uden genstart. Service Fabric har en tilsvarende hændelse. Andre steder skal I gå ud fra, at en ændret indstilling genstarter processen, og teste, hvad det gør ved igangværende arbejde.
• RoleEnvironment.CurrentRoleInstance brugt til at vælge én instans til planlagt arbejde. Udløste WebJobs kører på én instans; kontinuerlige kører på alle instanser, medmindre de begrænses. Beslut det udtrykkeligt.
• Forgreninger på RoleEnvironment.IsAvailable og IsEmulated. De adskiller »cloud«-vejen fra den »lokale« vej, og en af dem er ved at blive død kode.

.cscfg og .csdef

.cscfg indeholder indstillinger pr. miljø, antal instanser og certifikaters thumbprints. .csdef indeholder endpoints, VM-størrelse, lokal lagring, opstartsopgaver, certifikatlagre og nogle gange flere IIS-websites i én webrolle. Gå begge igennem linje for linje, og skriv ned, hvor hver post bor bagefter: en app setting, en Key Vault-reference, infrastrukturkode eller ingen steder. Interne endpoints, der lader roller kalde hinanden direkte, skal erstattes, enten af en tjenesteadresse eller en kø.

Certifikater

Extended support tvang allerede certifikater ind i Key Vault, så den del af arbejdet fra 2024 betaler sig nu. Det, der ændrer sig, er, hvordan koden finder dem. En .csdef installerer certifikater i et navngivet lager, ofte LocalMachine. På Windows App Service gør indstillingen WEBSITE_LOAD_CERTIFICATES dem tilgængelige i Current User\My. Kode, der åbner lageret LocalMachine, finder ingenting, og det første kald, der har brug for certifikatet, fejler. På Linux-containere skal det i stedet indlæses fra Key Vault ved opstart.

Opstartsopgaver

Åbn Startup.cmd. Det er her, overraskelserne bor, typisk kørt med executionContext="elevated": skrifttyper til PDF-generering, en COM-komponent, et IIS-rewritemodul, en ændring i registreringsdatabasen for TLS. Hver linje har tre mulige skæbner: ikke længere nødvendig, flyttet ind i et installationsscript på Managed Instance eller bagt ind i et container- eller VM-image.

Lokal lagring

En LocalStorage-ressource i .csdef, læst via RoleEnvironment.GetLocalResource, gav hver instans en kladdedisk. Brug platformens midlertidige mappe til rigtige midlertidige filer. Alt, der skal overleve en genstart, inklusive filer, som nogen gik ud fra var permanente, skal i Blob Storage.

Web Forms

Det er beslutningen, der styrer resten. Web Forms bygger på System.Web og har ingen ASP.NET Core-version, så at flytte en Web Forms-applikation til Service Fabric eller Container Apps betyder at omskrive dens brugergrænseflade. App Service, Managed Instance, en Windows-container eller et scale set kan alle køre den uændret. Flyt den, som den er, og gør moderniseringen til et separat projekt med sit eget budget. En omskrivning af brugergrænsefladen hører ikke hjemme på den kritiske vej mod en lukkedato.

Resten

VIP swap mellem to cloudtjenester bliver til deployment slots på App Service eller revisioner på Container Apps. Logs, der sendes via diagnostikudvidelsen (WAD), skal have en ny destination, som regel Application Insights. Standard-App Service og Container Apps tilbyder ikke fjernskrivebord; Managed Instance tillader det via Azure Bastion, kun til diagnosticering.

En plan på seks måneder

Talt baglæns fra 31. marts 2027, med juleferien i midten.

Oktober: overblik og valg af mål. List hver udrulning på extended support. Registrér for hver rolle .NET Framework-versionen, Web Forms eller MVC, hvert kald til RoleEnvironment, hver opstartsopgave, ressource til lokal lagring, certifikat og endpoint. Tjek derefter den ubehagelige del: kan I bygge den udrullede pakke ud fra den kildekode, I har? Med systemer bygget af bureauer er svaret nogle gange nej, og oktober er måneden til at finde ud af det. Vælg et mål pr. rolle.

November: én rolle, hele vejen igennem. Tilføj konfigurationsindpakningen, skriv målmiljøet som infrastrukturkode, og få én rolle (som regel den enkleste worker) til at køre i et testmiljø med logs, certifikater og en pipeline.

December og januar: portér resten. Udskift indgangspunkter, opstartsopgaver og lokal lagring. Belastningstest et stagingmiljø med produktionslignende data: et WebJob eller en container matcher måske ikke kapaciteten i en dedikeret rolle-VM.

Februar: parallel drift. Kør det nye miljø mod rigtig trafik. For workere, der deler kø med de gamle roller, skal I enten gøre behandlingen idempotent først eller stoppe de gamle workere, før de nye startes.

Begyndelsen af marts: omstilling. Skift DNS med tid til overs. Hold den gamle udrulning stoppet, men intakt i en uge eller to, og slet den derefter. Planlæg ikke omstillingen til den sidste uge af marts: en mislykket omstilling har så ikke noget andet forsøg.

Starter I i stedet i januar, så drop moderniseringen helt. Vælg det mål, der kræver mindst kodeændring (App Service, Managed Instance eller scale sets), flyt, og refaktorér bagefter.

Hvad der ikke er klart

Microsoft siger, at tjenesten vil være »fuldt udfaset«, og at migrering er nødvendig »for at undgå afbrydelse af tjenesten«. De sider, vi har læst, siger ikke, hvad der sker med en udrulning, der stadig kører 1. april 2027. Planlæg ikke efter at finde ud af det. Regioner og planer for Managed Instance vil sandsynligvis også ændre sig de kommende måneder, så bekræft dem, når I beslutter jer, og ikke ud fra denne artikel.

Hvor I kan få hjælp

Vi overtager applikationer, som andre har bygget, finder ud af, hvordan de kører, og flytter dem: overblikket, målet pr. rolle, ændringerne i RoleEnvironment og opstartsopgaver samt omstillingen. Vores arbejde med vedligeholdelse af ældre systemer dækker .NET Framework og Web Forms; laver jeres eget team migreringen og mangler ekstra hænder, så se teamforstærkning.

Har I en Cloud Services-udrulning og en dato seks måneder ude i fremtiden, så skriv til office@c9group.dev.