Azure Cloud Services (extended support) läggs ner 31 mars 2027: så flyttar du webb- och arbetsroller

Microsoft fasade ut Azure Cloud Services (extended support) den 31 mars 2025 och lägger ner tjänsten helt den 31 mars 2027. Om en av dina verksamhetsapplikationer körs som web roles och worker roles måste den köras någon annanstans i Azure före det datumet. Vanliga frågor om nedläggningen är rakt på sak om de två frågor alla ställer först: Microsoft ”kan inte bevilja förlängningar”, och ”det finns inget migreringsverktyg med ett klick”.

Räknat från i dag, 3 oktober 2026, återstår sex månader.

Vem artikeln är till för

Det typiska fallet: en ASP.NET-applikation på .NET Framework, en web role längst fram och en eller två worker roles som bearbetar köer bakom den, byggd av en byrå för åtta eller tio år sedan. Byrån har ofta gått vidare, applikationen sköter fortfarande orderhanteringen eller en kundportal, och ingen har öppnat .csdef-filen sedan förra migreringen.

För att se om du berörs öppnar du Azure-portalen och listar resurser av typen ”Cloud services (extended support)”. Microsofts meddelande om nedläggningen länkar direkt till den vyn. Är den tom är du klar.

Artikeln handlar inte om Cloud Services (classic), som lades ner 2024. Om en leverantör driftar produkten åt dig är migreringen deras jobb: be om deras datum skriftligt. Allt nedan gäller team som äger koden, eller äger den på papperet och måste hitta någon som förstår den.

Varför det är svårare än flytten 2024

Många företag gick över till extended support 2024, när classic lades ner. Den flytten var billig med flit. Microsofts översikt över extended support säger att filerna .csdef, .cscfg och .cspkg ”förs vidare och formaten ändras inte”, och att ”inga ändringar krävs i körtidskoden”. Det fanns till och med en migrering på plats. Samma sida rekommenderade extended support för applikationer som inte vidareutvecklas, eftersom ”det ger en snabb migreringsväg”.

Den här gången finns inget likvärdigt mål. Med Microsofts ord handlar Cloud Services ”om att driftsätta applikationer som virtuella maskiner. Koden du skriver är tätt kopplad till en VM-instans”. Din kod vet att den körs i en roll. Den läser konfiguration från rollen, hittar diskutrymme genom rollen, får certifikat installerade av rollen och kör installationsskript som administratör innan rollen startar. Allt det måste ersättas.

En sak till innan du läser den officiella vägledningen. Microsofts meddelande och FAQ om nedläggningen nämner ett enda mål, Service Fabric managed cluster. Översiktssidan räknar upp fem, och Microsofts egen beslutsmatris för migrering jämför sju. Service Fabric är ett förval, inget krav, och för många web roles är det fel val.

Målen, och när vart och ett passar

Web roles och worker roles behöver inte hamna på samma ställe. Välj mål per roll.

App Service (Windows). Det som ligger närmast en web role för en ASP.NET-applikation. Windows-instanserna har de .NET Framework-versioner som stöds förinstallerade, så Web Forms och MVC 5 körs utan omskrivning. Worker roles kan följa med som WebJobs, som körs ”i samma instans som en webbapp” utan extra kostnad. Begränsningen är själva maskinen: Microsoft hänvisar appar som behöver COM-komponenter, registeråtkomst eller MSI-installationer till Managed Instance, så startuppgifter med förhöjda rättigheter har ingenstans att ta vägen i en standardplan.

App Service Managed Instance. Byggt för äldre webbappar på Windows. Enligt Microsofts översikt är det ”allmänt tillgängligt för webbappar på Windows i utvalda regioner”, begränsat till planerna Pv4 och Pmv4, med .NET Framework 3.5 och 4.8 förinstallerade och installationsskript i PowerShell som kan registrera COM-komponenter, skriva registernycklar, köra MSI-installationer och konfigurera IIS. Det täcker det mesta som startuppgifterna med förhöjda rättigheter gjorde. Begränsningarna: bara webbappar (inga WebJobs), inga containrar, bara Entra ID och managed identity (ingen domänanslutning, NTLM eller Kerberos), och när detta skrivs är North Europe den enda europeiska region som listas.

Container Apps. Bra för worker roles när de väl körs på modern .NET: köstyrd skalning, schemalagda och händelsestyrda jobb, skalning ner till noll. Men kraven på containrar säger att ”Linux-baserade containeravbildningar (linux/amd64) krävs”. Kod på .NET Framework kan inte köras där förrän den har portats.

Azure Kubernetes Service. Kör Windows Server-containrar i Windows-nodpooler, så en .NET Framework-roll kan containeriseras och flyttas. Beslutsmatrisen bedömer både migreringens komplexitet och driftbördan som hög. Det passar om du redan kör Kubernetes, inte som ett första kluster för en enda äldre app.

Virtual Machine Scale Sets. Matrisen kallar det ”närmare Cloud Services-modellen, med enklare lift-and-shift”. Du får tillbaka den virtuella maskinen, tillsammans med patchningen, avbildningsbyggena och IIS-konfigurationen som rollen tidigare skötte åt dig.

Service Fabric managed cluster. Microsofts utpekade mål. Worker roles passar in utan problem. Web roles gör det ofta inte: Service Fabric ”stöder inte IIS”, och konverteringsguiden anger ASP.NET Web Forms som inte stött, med konvertering till ASP.NET Core MVC som väg framåt. Migreringsguiden för Service Fabric tillägger att managed clusters ”för närvarande inte stöder containrar”, så en app som är beroende av IIS behöver ett traditionellt kluster, med mer att drifta.

Beslutstabell

Vad som ändras i koden

Sök i lösningen efter Microsoft.WindowsAzure.ServiceRuntime. Varje fil som importerar det hamnar på listan.

RoleEntryPoint

En worker role är en klass som ärver RoleEntryPoint och överskuggar OnStart, Run och OnStop. Om Run returnerar startas instansen om. Service Fabric slår ihop alla tre till en enda RunAsync som ska avslutas ”när RunAsync-metodens CancellationToken signaleras”. I App Service eller i en container blir samma logik en konsolapplikation eller en hostad bakgrundstjänst med en loop och en cancellation token.

Det man brukar missa är nedstängningen. OnStop gav dig en stund att göra klart meddelandet du höll på med. Se till att den nya värden skickar vidare en avbrottssignal, och att ett meddelande som överges mitt i bearbetningen tål att bearbetas två gånger.

Web roles har ofta en sådan klass också, typiskt WebRole.cs. Om dess OnStart gör något (IIS-justeringar, uppvärmning av cache), ta reda på vad innan du tar bort den.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") läser inställningar från .cscfg. Ingenting utanför Cloud Services tillhandahåller det. Innan du flyttar något, kapsla in varje anrop i ett litet konfigurationsgränssnitt och peka sedan gränssnittet mot app settings, miljövariabler eller Key Vault på den nya värden. Det är den billigaste ändringen i projektet och den gör resten testbart på en bärbar dator.

Tre andra användningar att leta efter:

• RoleEnvironment.Changed, som tillämpade konfigurationsändringar utan omstart. Service Fabric har en motsvarande händelse. På andra ställen ska du räkna med att en ändrad inställning startar om processen, och testa vad det gör med pågående arbete.
• RoleEnvironment.CurrentRoleInstance som används för att utse en instans för schemalagt arbete. Triggered WebJobs körs på en enda instans; continuous körs på alla instanser om de inte begränsas. Bestäm det uttryckligen.
• Grenar med RoleEnvironment.IsAvailable och IsEmulated. De skiljer vägen för ”molnet” från vägen för ”lokalt”, och en av dem håller på att bli död kod.

.cscfg och .csdef

.cscfg innehåller inställningar per miljö, antal instanser och tumavtryck för certifikat. .csdef innehåller slutpunkter, VM-storlek, lokal lagring, startuppgifter, certifikatarkiv och ibland flera IIS-webbplatser i en och samma web role. Gå igenom båda rad för rad och skriv ner var varje post hamnar efteråt: en app setting, en Key Vault-referens, infrastrukturkod eller ingenstans. Interna slutpunkter som låter roller anropa varandra direkt behöver en ersättare, antingen en tjänsteadress eller en kö.

Certifikat

Extended support tvingade redan in certifikaten i Key Vault, så den delen av arbetet från 2024 lönar sig nu. Det som ändras är hur koden hittar dem. En .csdef installerar certifikat i ett namngivet arkiv, ofta LocalMachine. I App Service på Windows gör inställningen WEBSITE_LOAD_CERTIFICATES dem tillgängliga i Current User\My. Kod som öppnar arkivet LocalMachine hittar ingenting, och det första anropet som behöver certifikatet misslyckas. I Linux-containrar laddar du det i stället från Key Vault vid start.

Startuppgifter

Öppna Startup.cmd. Det är här överraskningarna finns, oftast körda med executionContext="elevated": typsnitt för PDF-generering, en COM-komponent, en IIS-modul för omskrivning, en registerändring för TLS. Varje rad har tre möjliga öden: behövs inte längre, flyttas in i ett installationsskript på Managed Instance, eller bakas in i en container- eller VM-avbildning.

Lokal lagring

En LocalStorage-resurs i .csdef, läst via RoleEnvironment.GetLocalResource, gav varje instans en temporär disk. Använd plattformens temp-katalog för verkliga temporära filer. Allt som måste överleva en omstart, inklusive filer som någon trodde var permanenta, flyttas till Blob Storage.

Web Forms

Det här är beslutet som styr resten. Web Forms bygger på System.Web och har ingen ASP.NET Core-version, så att flytta en Web Forms-applikation till Service Fabric eller Container Apps innebär att skriva om användargränssnittet. App Service, Managed Instance, en Windows-container eller en scale set kan alla köra den oförändrad. Flytta den som den är och gör moderniseringen till ett separat projekt med en egen budget. En omskrivning av gränssnittet hör inte hemma på den kritiska linjen fram till ett nedstängningsdatum.

Resten

VIP swap mellan två molntjänster blir deployment slots i App Service eller revisioner i Container Apps. Loggar som skickas via diagnostiktillägget (WAD) behöver en ny destination, oftast Application Insights. Standardversionen av App Service och Container Apps erbjuder inget fjärrskrivbord; Managed Instance tillåter det via Azure Bastion, enbart för felsökning.

En plan på sex månader

Räknat baklänges från 31 mars 2027, med julledigheterna mitt i.

Oktober: inventering och val av mål. Lista varje driftsättning med extended support. Anteckna för varje roll .NET Framework-versionen, Web Forms eller MVC, varje anrop till RoleEnvironment, varje startuppgift, resurs för lokal lagring, certifikat och slutpunkt. Kontrollera sedan den obekväma delen: kan du bygga det driftsatta paketet från den källkod du har? Med system som byggts av byråer är svaret ibland nej, och oktober är månaden att ta reda på det. Välj mål per roll.

November: en roll, hela vägen. Lägg in konfigurationsgränssnittet, skriv målmiljön som infrastrukturkod och få en roll (oftast den enklaste workern) att köra i en testmiljö med loggar, certifikat och en pipeline.

December och januari: porta resten. Ersätt startpunkter, startuppgifter och lokal lagring. Lasttesta en stagingmiljö med produktionslik data: ett WebJob eller en container kanske inte klarar samma genomströmning som en dedikerad VM för rollen.

Februari: parallelldrift. Kör den nya miljön mot verklig trafik. För workers som delar kö med de gamla rollerna: gör antingen bearbetningen idempotent först, eller stoppa de gamla workers innan du startar de nya.

Början av mars: växla över. Byt DNS med god marginal. Låt den gamla driftsättningen stå stoppad men intakt en eller två veckor och ta sedan bort den. Lägg inte överväxlingen i sista veckan i mars: en misslyckad överväxling har då inget andra försök.

Om du i stället börjar i januari: stryk moderniseringen helt. Välj det mål som kräver minst kodändringar (App Service, Managed Instance eller scale sets), flytta, och refaktorera efteråt.

Vad som är oklart

Microsoft säger att tjänsten kommer att vara ”helt nedlagd” och att migrering krävs ”för att undvika avbrott i tjänsten”. Sidorna vi har läst säger inte vad som händer med en driftsättning som fortfarande körs den 1 april 2027. Planera inte för att ta reda på det. Regioner och planer för Managed Instance kommer sannolikt också att ändras under de kommande månaderna, så kontrollera dem när du fattar beslutet, inte utifrån den här artikeln.

Var du får hjälp

Vi tar över applikationer som andra har byggt, räknar ut hur de körs och flyttar dem: inventeringen, målet per roll, ändringarna av RoleEnvironment och startuppgifterna, och överväxlingen. Vårt arbete med underhåll av äldre system omfattar .NET Framework och Web Forms; om ditt eget team gör migreringen och behöver fler händer, se konsultförstärkning.

Om du har en driftsättning i Cloud Services och ett datum sex månader bort, skriv till office@c9group.dev.