Azure Cloud Services (extended support) fases ut 31. mars 2027: slik flytter du web- og worker-roller

Microsoft avviklet Azure Cloud Services (extended support) 31. mars 2025 og faser tjenesten helt ut 31. mars 2027. Kjører en av forretningsapplikasjonene deres som web-roller og worker-roller, må den kjøre et annet sted i Azure før den datoen. Spørsmålene og svarene om utfasingen er rett på sak om de to spørsmålene alle stiller først: Microsoft «kan ikke innvilge forespørsler om forlengelse», og «det finnes ikke noe migreringsverktøy med ett klikk».

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

Hvem dette er for

Det typiske tilfellet: en ASP.NET-applikasjon på .NET Framework, en web-rolle foran og én eller to worker-roller som behandler køer bak, bygget av et byrå for åtte eller ti år siden. Byrået har ofte gått videre, applikasjonen kjører fortsatt ordrebehandling eller en kundeportal, og ingen har åpnet .csdef-filen siden forrige migrering.

For å sjekke om dere er berørt, åpne Azure-portalen og list opp ressurser av typen «Cloud services (extended support)». Microsofts varsel om utfasingen lenker rett til den visningen. Er den tom, er du ferdig.

Denne artikkelen handler ikke om Cloud Services (classic), som ble faset ut i 2024. Er det en leverandør som drifter produktet for deg, er migreringen deres jobb: be om datoen deres skriftlig. Alt nedenfor er for team som eier koden, eller eier den på papiret og må finne noen som forstår den.

Hvorfor dette er vanskeligere enn flyttingen i 2024

Mange selskaper gikk over til extended support i 2024, da classic ble faset ut. Den flyttingen var billig med vilje. Microsofts oversikt over extended support sier at filene .csdef, .cscfg og .cspkg «videreføres, og det er ingen endringer i formatene», og at «det kreves ingen endringer i kjøretidskoden». Det fantes til og med en migrering på stedet. Den samme siden foreslo extended support for applikasjoner som ikke videreutvikles, fordi den «gir en rask migreringsvei».

Denne gangen finnes det ikke noe tilsvarende mål. Med Microsofts ord handler Cloud Services «om å rulle ut applikasjoner som VM-er. Koden du skriver, er tett koblet til en VM-instans». Koden din vet at den kjører i en rolle. Den leser konfigurasjon fra rollen, finner diskplass gjennom rollen, får sertifikater installert av rollen og kjører oppstartsskript som administrator før rollen starter. Alt det må erstattes.

Én ting til før du leser den offisielle veiledningen. Microsofts varsel om utfasingen og spørsmålene og svarene nevner ett mål, Service Fabric managed cluster. Oversiktssiden lister opp fem, og Microsofts egen beslutningsmatrise for migrering sammenligner sju. Service Fabric er et standardvalg, ikke et krav, og for mange web-roller er det feil valg.

Målene, og når hvert av dem passer

Web- og worker-roller trenger ikke havne på samme sted. Velg et mål per rolle.

App Service (Windows). Det nærmeste du kommer en web-rolle for en ASP.NET-applikasjon. Windows-instansene har de støttede .NET Framework-versjonene installert, så Web Forms og MVC 5 kjører uten omskriving. Worker-roller kan følge med som WebJobs, som kjører «i samme instans som en webapp» uten ekstra kostnad. Begrensningen er selve maskinen: Microsoft styrer apper som trenger COM-komponenter, registertilgang eller MSI-installasjoner, til Managed Instance, så oppstartsoppgaver med forhøyede rettigheter har ingen plass å gå på en standardplan.

App Service Managed Instance. Laget for eldre Windows-webapper. Ifølge Microsofts oversikt er den «generelt tilgjengelig for Windows-webapper i utvalgte regioner», begrenset til planene Pv4 og Pmv4, med .NET Framework 3.5 og 4.8 forhåndsinstallert og PowerShell-installasjonsskript som kan registrere COM-komponenter, skrive registernøkler, kjøre MSI-installasjoner og konfigurere IIS. Det dekker det meste av det oppstartsoppgaver med forhøyede rettigheter gjorde. Begrensningene: bare webapper (ingen WebJobs), ingen containere, bare Entra ID og managed identity (ingen domenetilknytning, NTLM eller Kerberos), og da dette ble skrevet, var North Europe den eneste europeiske regionen på listen.

Container Apps. Bra for worker-roller når de først er på moderne .NET: køstyrt skalering, planlagte og hendelsesutløste jobber, skalering til null. Men kravene til containere sier at «Linux-baserte (linux/amd64) containeravbildninger er påkrevd». Kode på .NET Framework kjører ikke der før den er portert.

Azure Kubernetes Service. Kjører Windows Server-containere i Windows-nodepooler, så en .NET Framework-rolle kan containeriseres og flyttes. Beslutningsmatrisen vurderer både migreringskompleksiteten og driftsbelastningen som høy. Det passer hvis dere allerede kjører Kubernetes, ikke som første klynge for én eldre app.

Virtual Machine Scale Sets. Matrisen kaller det «nærmere Cloud Services-modellen, med enklere lift-and-shift». Du får VM-en tilbake, sammen med oppdateringene, avbildningsbyggene og IIS-oppsettet som rollen pleide å gjøre for deg.

Service Fabric managed cluster. Microsofts navngitte mål. Worker-roller passer greit inn. Web-roller gjør det ofte ikke: Service Fabric «støtter ikke IIS», og konverteringsveiledningen oppgir ASP.NET Web Forms som ikke støttet, med konvertering til ASP.NET Core MVC som veien videre. Migreringsveiledningen for Service Fabric legger til at administrerte klynger «foreløpig ikke støtter containere», så en app som er avhengig av IIS, trenger en tradisjonell klynge, med mer å drifte.

Beslutningstabell

Hva som endres i koden

Søk i løsningen etter Microsoft.WindowsAzure.ServiceRuntime. Hver fil som importerer det, står på listen.

RoleEntryPoint

En worker-rolle er en klasse som arver RoleEntryPoint og overstyrer OnStart, Run og OnStop. Returnerer Run, resirkuleres instansen. Service Fabric slår alle tre sammen til én RunAsync, som skal stoppe «når CancellationToken i RunAsync-metoden signaliseres». På App Service eller i en container blir den samme logikken en konsollapplikasjon eller en vertsbasert bakgrunnstjeneste med en løkke og et avbruddssignal (cancellation token).

Delen folk overser, er nedstengningen. OnStop ga deg et øyeblikk til å gjøre ferdig meldingen du holdt på med. Sørg for at den nye verten sender et avbruddssignal videre, og at en melding som forlates midt i behandlingen, trygt kan behandles to ganger.

Web-roller har ofte også en slik klasse, typisk WebRole.cs. Gjør OnStart der noe (IIS-justeringer, oppvarming av hurtigbuffer), finn ut hva før du sletter den.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") leser innstillinger fra .cscfg. Ingenting utenfor Cloud Services tilbyr det. Før du flytter noe, pakk inn hvert kall i ett lite konfigurasjonsgrensesnitt, og pek deretter det grensesnittet mot app-innstillinger, miljøvariabler eller Key Vault på den nye verten. Det er den billigste endringen i prosjektet, og den gjør resten testbart på en bærbar PC.

Tre andre bruksmåter å se etter:

• RoleEnvironment.Changed, som tok i bruk konfigurasjonsendringer uten omstart. Service Fabric har en tilsvarende hendelse. Andre steder bør du anta at en endret innstilling starter prosessen på nytt, og teste hva det gjør med arbeid som pågår.
• RoleEnvironment.CurrentRoleInstance, brukt til å velge én instans for planlagt arbeid. Utløste WebJobs kjører på én instans; kontinuerlige kjører på alle instanser med mindre de begrenses. Bestem det uttrykkelig.
• Forgreninger på RoleEnvironment.IsAvailable og IsEmulated. De skiller «sky»-løypa fra den «lokale» løypa, og én av dem er i ferd med å bli død kode.

.cscfg og .csdef

.cscfg inneholder innstillinger per miljø, antall instanser og sertifikatavtrykk. .csdef inneholder endepunkter, VM-størrelse, lokal lagring, oppstartsoppgaver, sertifikatlagre og noen ganger flere IIS-nettsteder inne i én web-rolle. Gå gjennom begge linje for linje, og skriv ned hvor hver oppføring havner etterpå: en app-innstilling, en Key Vault-referanse, infrastrukturkode eller ingen steder. Interne endepunkter som lar roller kalle hverandre direkte, trenger en erstatning, enten en tjenesteadresse eller en kø.

Sertifikater

Extended support tvang allerede sertifikatene inn i Key Vault, så den delen av arbeidet fra 2024 betaler seg. Det som endres, er hvordan koden finner dem. En .csdef installerer sertifikater i et navngitt lager, ofte LocalMachine. På Windows App Service gjør innstillingen WEBSITE_LOAD_CERTIFICATES dem tilgjengelige i Current User\My. Kode som åpner LocalMachine-lageret, finner ingenting, og det første kallet som trenger sertifikatet, feiler. I Linux-containere laster du det i stedet fra Key Vault ved oppstart.

Oppstartsoppgaver

Åpne Startup.cmd. Det er her overraskelsene bor, som regel kjørt med executionContext="elevated": skrifttyper for PDF-generering, en COM-komponent, en omskrivingsmodul for IIS, en registerendring for TLS. Hver linje har tre mulige skjebner: ikke lenger nødvendig, flyttet inn i et installasjonsskript på Managed Instance, eller bakt inn i en container- eller VM-avbildning.

Lokal lagring

En LocalStorage-ressurs i .csdef, lest gjennom RoleEnvironment.GetLocalResource, ga hver instans midlertidig diskplass. Bruk plattformens temp-katalog for ekte midlertidige filer. Alt som må overleve en omstart, inkludert filer noen antok var permanente, går til Blob Storage.

Web Forms

Dette er beslutningen som styrer resten. Web Forms er bygget på System.Web og har ingen ASP.NET Core-versjon, så å flytte en Web Forms-applikasjon til Service Fabric eller Container Apps betyr å skrive om brukergrensesnittet. App Service, Managed Instance, en Windows-container eller et skaleringssett kan alle kjøre den uendret. Flytt den som den er, og gjør modernisering til et eget prosjekt med eget budsjett. En omskriving av brukergrensesnittet hører ikke hjemme på den kritiske linjen mot en nedstengningsdato.

Resten

VIP-bytte mellom to skytjenester blir utrullingsspor (deployment slots) på App Service eller revisjoner på Container Apps. Logger som ble sendt gjennom diagnostikkutvidelsen (WAD), trenger et nytt mål, som regel Application Insights. Standard App Service og Container Apps har ikke eksternt skrivebord; Managed Instance tillater det gjennom Azure Bastion, bare til diagnostikk.

En plan over seks måneder

Regnet bakover fra 31. mars 2027, med juleferien midt i.

Oktober: kartlegging og valg av mål. List opp hver utrulling på extended support. For hver rolle registrerer du .NET Framework-versjonen, Web Forms eller MVC, hvert RoleEnvironment-kall, hver oppstartsoppgave, hver ressurs for lokal lagring, hvert sertifikat og hvert endepunkt. Sjekk deretter den ubehagelige delen: kan dere bygge den utrullede pakken fra kildekoden dere har? Med systemer bygget av byråer er svaret av og til nei, og oktober er måneden for å finne det ut. Velg et mål per rolle.

November: én rolle, fra ende til ende. Legg til konfigurasjonsinnpakningen, skriv målmiljøet som infrastrukturkode, og få én rolle (som regel den enkleste workeren) til å kjøre i et testmiljø med logger, sertifikater og en utrullingsløype.

Desember og januar: porter resten. Erstatt inngangspunkter, oppstartsoppgaver og lokal lagring. Belastningstest et staging-miljø med produksjonslignende data: en WebJob eller container matcher kanskje ikke kapasiteten til en dedikert rolle-VM.

Februar: parallell drift. Kjør det nye miljøet mot ekte trafikk. For workers som deler kø med de gamle rollene, gjør enten behandlingen idempotent først, eller stopp de gamle workerne før du starter de nye.

Begynnelsen av mars: overgang. Bytt DNS med god margin. Behold den gamle utrullingen stoppet, men intakt, i en uke eller to, og slett den deretter. Ikke legg overgangen til siste uke i mars: en mislykket overgang har da ikke noe nytt forsøk.

Starter du i januar i stedet, dropp moderniseringen helt. Velg målet som krever minst kodeendring (App Service, Managed Instance eller skaleringssett), flytt, og refaktorer etterpå.

Hva som ikke er klart

Microsoft sier at tjenesten vil bli «fullstendig faset ut», og at migrering er nødvendig «for å unngå avbrudd i tjenesten». Sidene vi har lest, sier ikke hva som skjer med en utrulling som fortsatt kjører 1. april 2027. Ikke planlegg med å finne det ut. Regioner og planer for Managed Instance vil trolig også endre seg de kommende månedene, så bekreft dem når dere bestemmer dere, ikke ut fra denne artikkelen.

Hvor du får hjelp

Vi tar over applikasjoner andre har bygget, finner ut hvordan de kjører, og flytter dem: kartleggingen, målet per rolle, endringene i RoleEnvironment og oppstartsoppgavene, og overgangen. Arbeidet vårt med vedlikehold av eldre systemer dekker .NET Framework og Web Forms; gjør deres eget team migreringen og trenger flere hender, se teamforsterkning.

Har dere en Cloud Services-utrulling og en dato seks måneder unna, skriv til office@c9group.dev.