Door Kristijan Sekereš
Azure Cloud Services (extended support) stopt op 31 maart 2027: web- en workerrollen verhuizen

Microsoft heeft Azure Cloud Services (extended support) op 31 maart 2025 als verouderd aangemerkt en fasert de dienst op 31 maart 2027 volledig uit. Draait een van uw bedrijfsapplicaties als webrollen en workerrollen, dan moet die vóór die datum ergens anders op Azure draaien. De FAQ over de uitfasering is kort over de twee vragen die iedereen als eerste stelt: Microsoft “kan geen verzoeken om uitstel inwilligen”, en “er is geen migratietool met één klik beschikbaar.”
Vanaf vandaag, 3 oktober 2026, laat dat zes maanden over.
Voor wie dit is
Het typische geval: een ASP.NET-applicatie op .NET Framework, een webrol aan de voorkant en een of twee workerrollen erachter die wachtrijen verwerken, acht of tien jaar geleden gebouwd door een bureau. Het bureau is vaak uit beeld, de applicatie draait nog steeds orderverwerking of een klantportaal, en niemand heeft het .csdef-bestand geopend sinds de vorige migratie.
Om te controleren of u wordt geraakt, opent u de Azure-portal en vraagt u de resources op van het type “Cloud services (extended support)”. De uitfaseringsmelding van Microsoft linkt rechtstreeks naar die weergave. Is die leeg, dan bent u klaar.
Dit artikel gaat niet over Cloud Services (classic), dat in 2024 is uitgefaseerd. Host een leverancier het product voor u, dan is de migratie zijn werk: vraag zijn datum schriftelijk op. Alles hieronder is voor teams die de code bezitten, of die op papier bezitten en iemand moeten vinden die haar begrijpt.
Waarom dit moeilijker is dan de verhuizing van 2024
Veel bedrijven stapten in 2024 over op extended support, toen classic werd uitgefaseerd. Die overstap was bewust goedkoop. Het overzicht van extended support van Microsoft zegt dat de bestanden .csdef, .cscfg en .cspkg “worden meegenomen zonder wijziging in de formaten”, en dat “er geen wijzigingen in de runtimecode nodig zijn”. Er was zelfs een in-place migratie. Dezelfde pagina raadde extended support aan voor applicaties die niet meer doorontwikkeld worden, omdat het “een snel migratiepad biedt.”
Deze keer is er geen gelijkwaardige bestemming. In de woorden van Microsoft draait het bij Cloud Services “om het uitrollen van applicaties als VM's. De code die u schrijft, is nauw verbonden met een VM-instantie”. Uw code weet dat ze in een rol draait. Ze leest configuratie uit de rol, vindt schijfruimte via de rol, krijgt certificaten geïnstalleerd door de rol, en draait setupscripts als beheerder voordat de rol start. Dat moet allemaal worden vervangen.
Nog één ding voordat u de officiële richtlijnen leest. De uitfaseringsmelding en de FAQ van Microsoft noemen één bestemming: Service Fabric managed cluster. De overzichtspagina noemt er vijf, en de eigen beslismatrix voor migratie van Microsoft vergelijkt er zeven. Service Fabric is een standaardkeuze, geen verplichting, en voor veel webrollen de verkeerde.
De bestemmingen, en wanneer elk past
Web- en workerrollen hoeven niet op dezelfde plek te landen. Kies per rol een bestemming.
App Service (Windows). Het dichtst bij een webrol voor een ASP.NET-applicatie. Windows-instanties hebben de ondersteunde .NET Framework-versies geïnstalleerd, dus Web Forms en MVC 5 draaien zonder herschrijving. Workerrollen kunnen volgen als WebJobs, die “in dezelfde instantie als een web-app” draaien, zonder extra kosten. De grens is de machine zelf: Microsoft stuurt apps die COM-componenten, registertoegang of MSI-installatieprogramma's nodig hebben naar Managed Instance, dus startuptaken met verhoogde rechten kunnen op een standaardplan nergens heen.
App Service Managed Instance. Gebouwd voor verouderde Windows-web-apps. Volgens het overzicht van Microsoft is het “algemeen beschikbaar voor Windows-web-apps in geselecteerde regio's”, beperkt tot de plannen Pv4 en Pmv4, met .NET Framework 3.5 en 4.8 vooraf geïnstalleerd en PowerShell-installatiescripts die COM-componenten kunnen registreren, registersleutels kunnen schrijven, MSI-installatieprogramma's kunnen draaien en IIS kunnen configureren. Dat dekt het meeste van wat startuptaken met verhoogde rechten deden. De beperkingen: alleen web-apps (geen WebJobs), geen containers, alleen Entra ID en managed identity (geen domeinkoppeling, NTLM of Kerberos), en op het moment van schrijven is North Europe de enige Europese regio op de lijst.
Container Apps. Goed voor workerrollen zodra ze op modern .NET draaien: schalen op basis van wachtrijen, geplande en door gebeurtenissen gestarte taken, schalen naar nul. Maar de eisen voor containers zeggen dat “Linux-gebaseerde (linux/amd64) containerimages vereist zijn.” Code op .NET Framework draait daar niet tot ze is overgezet.
Azure Kubernetes Service. Draait Windows Server-containers in Windows-nodepools, dus een .NET Framework-rol kan in een container worden gezet en verhuizen. De beslismatrix beoordeelt zowel de migratiecomplexiteit als de operationele last als hoog. Het past als u al Kubernetes draait, niet als eerste cluster voor één verouderde app.
Virtual Machine Scale Sets. De matrix noemt het “dichter bij het model van Cloud Services, met eenvoudiger lift-and-shift”. U krijgt de VM terug, samen met het patchen, het bouwen van images en de IIS-setup die de rol vroeger voor u deed.
Service Fabric managed cluster. De bestemming die Microsoft noemt. Workerrollen passen er netjes op. Webrollen vaak niet: Service Fabric “ondersteunt IIS niet”, en de conversiegids noemt ASP.NET Web Forms als niet ondersteund, met omzetting naar ASP.NET Core MVC als route. De migratiegids voor Service Fabric voegt toe dat managed clusters “momenteel geen containers ondersteunen”, dus een app die van IIS afhangt, heeft een traditioneel cluster nodig, met meer beheer.
Beslistabel
| Uw rol ziet er zo uit | Waarschijnlijke bestemming | Waar het werk zit |
|---|---|---|
| ASP.NET Web Forms- of MVC 5-webrol, startuptaken triviaal of afwezig | App Service (Windows) | Configuratie, certificaten, deploymentpijplijn |
| Webrol waarvan de startuptaken COM-componenten, MSI's of registersleutels installeren | App Service Managed Instance | Startuptaken herschrijven als installatiescripts; regio en plan controleren |
| .NET Framework-workerrol die een wachtrij pollt, bescheiden belasting | WebJob naast de web-app | RoleEntryPoint vervangen door een consolehost |
| Workerrol die u naar modern .NET wilt overzetten | Container Apps | De overzetting zelf, daarna een containerimage |
| Veel rollen, en een team dat al Kubernetes draait | AKS met Windows-nodepools | Images, clusterbeheer |
| Zware native afhankelijkheden, geen zin in codewijzigingen | VM Scale Sets | Patchen van het besturingssysteem en onderhoud van images, voorgoed |
| Systeem met veel workers, webtier al op ASP.NET Core | Service Fabric managed cluster | Het platform leren; geen IIS, geen containers |
Wat er in de code verandert
Doorzoek de solution op Microsoft.WindowsAzure.ServiceRuntime. Elk bestand dat het importeert, staat op de lijst.
RoleEntryPoint
Een workerrol is een klasse die van RoleEntryPoint erft en OnStart, Run en OnStop overschrijft. Keert Run terug, dan wordt de instantie gerecycled. Service Fabric voegt alle drie samen in één RunAsync die moet stoppen “wanneer het CancellationToken van de RunAsync-methode wordt gesignaleerd”. Op App Service of in een container wordt dezelfde logica een consoleapplicatie of een gehoste achtergronddienst met een lus en een cancellation token.
Het deel dat mensen missen, is het afsluiten. OnStop gaf u even de tijd om het bericht dat u in handen had af te maken. Zorg dat de nieuwe host een annuleringssignaal doorgeeft, en dat een bericht dat halverwege de verwerking wordt achtergelaten veilig twee keer kan worden verwerkt.
Webrollen hebben er vaak ook een, meestal WebRole.cs. Doet de OnStart daarvan iets (IIS-aanpassingen, cache opwarmen), zoek dan uit wat, voordat u hem verwijdert.
RoleEnvironment
RoleEnvironment.GetConfigurationSettingValue("Key") leest instellingen uit de .cscfg. Buiten Cloud Services levert niets dat. Verpak elke aanroep, voordat u iets verhuist, in één kleine configuratie-interface en laat die interface op de nieuwe host verwijzen naar app-instellingen, omgevingsvariabelen of Key Vault. Het is de goedkoopste wijziging in het project, en ze maakt de rest testbaar op een laptop.
Drie andere toepassingen om naar te zoeken:
RoleEnvironment.Changed, dat configuratiewijzigingen doorvoerde zonder herstart. Service Fabric heeft een equivalente gebeurtenis. Ga er elders van uit dat een gewijzigde instelling het proces herstart, en test wat dat doet met werk dat onderweg is.RoleEnvironment.CurrentRoleInstance, gebruikt om één instantie aan te wijzen voor gepland werk. Getriggerde WebJobs draaien op één instantie; continue WebJobs draaien op alle instanties, tenzij u dat beperkt. Beslis het expliciet.- Vertakkingen op
RoleEnvironment.IsAvailableenIsEmulated. Die scheiden het pad voor de “cloud” van het “lokale” pad, en een van de twee wordt binnenkort dode code.
.cscfg en .csdef
De .cscfg bevat instellingen per omgeving, aantallen instanties en vingerafdrukken van certificaten. De .csdef bevat endpoints, VM-grootte, lokale opslag, startuptaken, certificaatstores en soms meerdere IIS-sites binnen één webrol. Loop beide regel voor regel door en noteer waar elke regel daarna terechtkomt: een app-instelling, een Key Vault-verwijzing, infrastructuurcode, of nergens. Interne endpoints waarmee rollen elkaar rechtstreeks aanroepen, hebben een vervanging nodig: een serviceadres of een wachtrij.
Certificaten
Extended support dwong certificaten al naar Key Vault, dus dat deel van het werk uit 2024 betaalt zich nu uit. Wat verandert, is hoe code ze vindt. Een .csdef installeert certificaten in een benoemde store, vaak LocalMachine. Op Windows App Service maakt de instelling WEBSITE_LOAD_CERTIFICATES ze beschikbaar in Current User\My. Code die de store LocalMachine opent, vindt niets, en de eerste aanroep die het certificaat nodig heeft, mislukt. Laad het in Linux-containers in plaats daarvan bij het opstarten uit Key Vault.
Startuptaken
Open Startup.cmd. Hier zitten de verrassingen, meestal gedraaid met executionContext="elevated": lettertypen voor pdf-generatie, een COM-component, een IIS-rewritemodule, een registerwijziging voor TLS. Elke regel kan drie kanten op: niet meer nodig, verplaatst naar een installatiescript op Managed Instance, of ingebakken in een container- of VM-image.
Lokale opslag
Een LocalStorage-resource in de .csdef, gelezen via RoleEnvironment.GetLocalResource, gaf elke instantie kladschijfruimte. Gebruik de tijdelijke map van het platform voor echte kladbestanden. Alles wat een herstart moet overleven, inclusief bestanden waarvan iemand aannam dat ze blijvend waren, gaat naar Blob Storage.
Web Forms
Dit is de beslissing die de rest bepaalt. Web Forms is gebouwd op System.Web en heeft geen ASP.NET Core-versie, dus een Web Forms-applicatie naar Service Fabric of Container Apps verhuizen betekent haar gebruikersinterface herschrijven. App Service, Managed Instance, een Windows-container of een scale set kunnen haar allemaal ongewijzigd draaien. Verhuis haar zoals ze is en maak van modernisering een apart project met een eigen budget. Een herschrijving van de UI hoort niet op het kritieke pad van een uitschakeldatum.
De rest
Een VIP swap tussen twee cloudservices wordt deployment slots op App Service of revisies op Container Apps. Logs die via de diagnostics-extensie (WAD) worden verstuurd, hebben een nieuwe bestemming nodig, meestal Application Insights. Standaard App Service en Container Apps bieden geen extern bureaublad; Managed Instance staat dat toe via Azure Bastion, alleen voor diagnose.
Een plan van zes maanden
Terugtellend vanaf 31 maart 2027, met de decembervakantie in het midden.
Oktober: inventarisatie en keuze van bestemming. Maak een lijst van elke deployment op extended support. Noteer per rol de .NET Framework-versie, Web Forms of MVC, elke aanroep van RoleEnvironment, elke startuptaak, lokale-opslagresource, elk certificaat en endpoint. Controleer daarna het ongemakkelijke deel: kunt u het uitgerolde pakket bouwen uit de broncode die u hebt? Bij systemen die een bureau heeft gebouwd, is het antwoord soms nee, en oktober is de maand om daarachter te komen. Kies per rol een bestemming.
November: één rol, van begin tot eind. Voeg de configuratiewrapper toe, schrijf de doelomgeving als infrastructuurcode, en krijg één rol (meestal de eenvoudigste worker) draaiend in een testomgeving, met logs, certificaten en een pijplijn.
December en januari: de rest overzetten. Vervang entrypoints, startuptaken en lokale opslag. Test een stagingomgeving onder belasting met productieachtige data: een WebJob of container haalt misschien niet de doorvoer van een eigen VM per rol.
Februari: parallel draaien. Draai de nieuwe omgeving tegen echt verkeer. Voor workers die een wachtrij delen met de oude rollen: maak de verwerking eerst idempotent, of stop de oude workers voordat u de nieuwe start.
Begin maart: overschakelen. Schakel DNS om met tijd over. Houd de oude deployment een week of twee gestopt maar intact, en verwijder haar daarna. Plan de overschakeling niet in de laatste week van maart: een mislukte overschakeling heeft dan geen tweede kans.
Begint u pas in januari, laat de modernisering dan helemaal vallen. Kies de bestemming die de minste codewijzigingen vraagt (App Service, Managed Instance of scale sets), verhuis, en refactor daarna.
Wat niet duidelijk is
Microsoft zegt dat de dienst “volledig wordt uitgefaseerd” en dat migratie nodig is “om onderbreking van de dienst te voorkomen”. De pagina's die wij lazen, zeggen niet wat er gebeurt met een deployment die op 1 april 2027 nog draait. Reken er niet op dat u daar achter komt. Ook de regio's en plannen van Managed Instance zullen de komende maanden waarschijnlijk veranderen, dus controleer ze wanneer u beslist, niet op basis van dit artikel.
Waar u hulp krijgt
Wij nemen applicaties over die anderen hebben gebouwd, zoeken uit hoe ze draaien en verhuizen ze: de inventarisatie, de bestemming per rol, de wijzigingen aan RoleEnvironment en startuptaken, en de overschakeling. Ons werk voor onderhoud van legacysystemen dekt .NET Framework en Web Forms; voert uw eigen team de migratie uit en heeft het extra handen nodig, kijk dan bij staff augmentation.
Hebt u een deployment op Cloud Services en een datum die zes maanden weg is, schrijf dan naar office@c9group.dev.