Azure Cloud Services (Extended Support) wird am 31. März 2027 eingestellt: Web- und Workerrollen umziehen

Microsoft hat Azure Cloud Services (Extended Support) am 31. März 2025 abgekündigt und stellt den Dienst am 31. März 2027 vollständig ein. Wenn eine Ihrer Fachanwendungen als Webrollen und Workerrollen läuft, muss sie vor diesem Datum anderswo auf Azure laufen. Die FAQ zur Einstellung beantwortet die beiden Fragen, die alle zuerst stellen, ohne Umschweife: Microsoft „kann keine Verlängerungsanträge bewilligen“, und „es gibt keine Migrationswerkzeuge mit einem Klick“.

Ab heute, dem 3. Oktober 2026, bleiben damit sechs Monate.

Für wen dieser Artikel ist

Der typische Fall: eine ASP.NET-Anwendung auf .NET Framework, vorne eine Webrolle und dahinter eine oder zwei Workerrollen, die Warteschlangen abarbeiten, gebaut von einer Agentur vor acht oder zehn Jahren. Die Agentur ist oft nicht mehr da, die Anwendung wickelt weiterhin Bestellungen ab oder betreibt ein Kundenportal, und seit der letzten Migration hat niemand die .csdef-Datei geöffnet.

Um zu prüfen, ob Sie betroffen sind, öffnen Sie das Azure-Portal und lassen Sie sich die Ressourcen vom Typ „Cloud services (extended support)“ anzeigen. Microsofts Mitteilung zur Einstellung verlinkt direkt auf diese Ansicht. Ist sie leer, sind Sie fertig.

Dieser Artikel behandelt nicht Cloud Services (classic), das 2024 eingestellt wurde. Wenn ein Anbieter das Produkt für Sie hostet, ist die Migration seine Aufgabe: Lassen Sie sich seinen Termin schriftlich geben. Alles Folgende richtet sich an Teams, denen der Code gehört, oder denen er auf dem Papier gehört und die jemanden finden müssen, der ihn versteht.

Warum das schwerer ist als der Umzug 2024

Viele Unternehmen sind 2024, als classic eingestellt wurde, auf Extended Support umgezogen. Dieser Umzug war absichtlich billig. Microsofts Überblick zu Extended Support sagt, die Dateien .csdef, .cscfg und .cspkg „werden übernommen, und an den Formaten ändert sich nichts“, und „am Laufzeitcode sind keine Änderungen erforderlich“. Es gab sogar eine Migration an Ort und Stelle. Dieselbe Seite empfahl Extended Support für Anwendungen, die nicht weiterentwickelt werden, weil es „einen schnellen Migrationspfad bietet“.

Diesmal gibt es kein gleichwertiges Ziel. In Microsofts Worten geht es bei Cloud Services darum, „Anwendungen als VMs bereitzustellen. Der Code, den Sie schreiben, ist eng an eine VM-Instanz gekoppelt“. Ihr Code weiß, dass er in einer Rolle läuft. Er liest die Konfiguration aus der Rolle, findet Speicherplatz über die Rolle, bekommt Zertifikate von der Rolle installiert und führt vor dem Start der Rolle Einrichtungsskripte als Administrator aus. All das muss ersetzt werden.

Noch etwas, bevor Sie die offizielle Anleitung lesen. Microsofts Mitteilung zur Einstellung und die FAQ nennen ein Ziel, den Service Fabric Managed Cluster. Die Überblicksseite nennt fünf, und Microsofts eigene Entscheidungsmatrix für die Migration vergleicht sieben. Service Fabric ist ein Standardvorschlag, keine Pflicht, und für viele Webrollen ist es das falsche Ziel.

Die Ziele und wann welches passt

Web- und Workerrollen müssen nicht am selben Ort landen. Wählen Sie das Ziel je Rolle.

App Service (Windows). Das, was einer Webrolle für eine ASP.NET-Anwendung am nächsten kommt. Windows-Instanzen haben die unterstützten .NET-Framework-Versionen installiert, Web Forms und MVC 5 laufen also ohne Neuentwicklung. Workerrollen können als WebJobs folgen, die „in derselben Instanz wie eine Web-App“ ohne Zusatzkosten laufen. Die Grenze ist die Maschine selbst: Microsoft lenkt Apps, die COM-Komponenten, Registry-Zugriff oder MSI-Installer brauchen, zu Managed Instance, erhöhte Starttasks haben auf einem Standardplan also keinen Platz.

App Service Managed Instance. Gebaut für ältere Windows-Web-Apps. Laut Microsofts Überblick ist es „für Windows-Web-Apps in ausgewählten Regionen allgemein verfügbar“, beschränkt auf die Pläne Pv4 und Pmv4, mit vorinstalliertem .NET Framework 3.5 und 4.8 und PowerShell-Installationsskripten, die COM-Komponenten registrieren, Registry-Schlüssel schreiben, MSI-Installer ausführen und IIS konfigurieren können. Das deckt das meiste ab, was erhöhte Starttasks erledigt haben. Die Grenzen: nur Web-Apps (keine WebJobs), keine Container, nur Entra ID und verwaltete Identität (kein Domänenbeitritt, kein NTLM, kein Kerberos), und zum Zeitpunkt dieses Artikels ist North Europe die einzige aufgeführte europäische Region.

Container Apps. Gut für Workerrollen, sobald sie auf modernem .NET laufen: Skalierung anhand von Warteschlangen, geplante und ereignisgesteuerte Jobs, Skalierung auf null. Aber die Anforderungen an Container sagen: „Linux-basierte Container-Images (linux/amd64) sind erforderlich.“ Code auf .NET Framework läuft dort erst, wenn er portiert ist.

Azure Kubernetes Service. Betreibt Windows-Server-Container in Windows-Knotenpools, eine Rolle auf .NET Framework lässt sich also containerisieren und umziehen. Die Entscheidungsmatrix bewertet sowohl die Migrationskomplexität als auch den Betriebsaufwand als hoch. Es passt, wenn Sie Kubernetes bereits betreiben, nicht als erster Cluster für eine einzelne Altanwendung.

Virtual Machine Scale Sets. Die Matrix nennt es „näher am Cloud-Services-Modell, mit einfacherem Lift-and-Shift“. Sie bekommen die VM zurück, zusammen mit dem Patchen, dem Bau der Images und der IIS-Einrichtung, die bisher die Rolle für Sie erledigt hat.

Service Fabric Managed Cluster. Microsofts genanntes Ziel. Workerrollen lassen sich sauber darauf abbilden. Webrollen oft nicht: Service Fabric „unterstützt IIS nicht“, und die Anleitung zur Umstellung führt ASP.NET Web Forms als nicht unterstützt auf, mit der Umstellung auf ASP.NET Core MVC als Weg. Der Migrationsleitfaden für Service Fabric ergänzt, dass Managed Cluster „derzeit keine Container unterstützen“, eine Anwendung, die von IIS abhängt, braucht also einen klassischen Cluster mit mehr Betriebsaufwand.

Entscheidungstabelle

Was sich im Code ändert

Durchsuchen Sie die Solution nach Microsoft.WindowsAzure.ServiceRuntime. Jede Datei, die es importiert, steht auf der Liste.

RoleEntryPoint

Eine Workerrolle ist eine Klasse, die von RoleEntryPoint erbt und OnStart, Run und OnStop überschreibt. Wenn Run zurückkehrt, wird die Instanz neu gestartet. Service Fabric fasst alle drei in einer einzigen Methode RunAsync zusammen, die anhalten soll, „wenn das CancellationToken der Methode RunAsync signalisiert wird“. Auf App Service oder in einem Container wird dieselbe Logik zu einer Konsolenanwendung oder einem gehosteten Hintergrunddienst mit einer Schleife und einem Cancellation Token.

Was übersehen wird, ist das Herunterfahren. OnStop gab Ihnen einen Moment, um die gerade bearbeitete Nachricht abzuschließen. Stellen Sie sicher, dass der neue Host ein Abbruchsignal durchreicht und dass eine mitten in der Verarbeitung abgebrochene Nachricht gefahrlos zweimal verarbeitet werden kann.

Auch Webrollen haben oft eine solche Klasse, typischerweise WebRole.cs. Wenn ihr OnStart irgendetwas tut (IIS-Anpassungen, Aufwärmen des Caches), finden Sie heraus, was, bevor Sie sie löschen.

RoleEnvironment

RoleEnvironment.GetConfigurationSettingValue("Key") liest Einstellungen aus der .cscfg. Außerhalb von Cloud Services stellt das nichts bereit. Bevor Sie irgendetwas umziehen, kapseln Sie jeden Aufruf in einer kleinen Konfigurationsschnittstelle und lassen diese Schnittstelle auf dem neuen Host auf App-Einstellungen, Umgebungsvariablen oder Key Vault zeigen. Das ist die billigste Änderung im ganzen Projekt, und sie macht den Rest auf einem Laptop testbar.

Drei weitere Verwendungen, nach denen Sie suchen sollten:

• RoleEnvironment.Changed, das Konfigurationsänderungen ohne Neustart übernommen hat. Service Fabric hat ein entsprechendes Ereignis. Anderswo sollten Sie davon ausgehen, dass eine Änderung der Einstellungen den Prozess neu startet, und testen, was das mit laufender Arbeit macht.
• RoleEnvironment.CurrentRoleInstance, verwendet, um eine Instanz für geplante Arbeit auszuwählen. Ausgelöste WebJobs laufen auf einer einzigen Instanz; fortlaufende laufen auf allen Instanzen, sofern nicht eingeschränkt. Entscheiden Sie das bewusst.
• Verzweigungen über RoleEnvironment.IsAvailable und IsEmulated. Sie trennen den „Cloud“-Pfad vom „lokalen“ Pfad, und einer davon wird gleich zu totem Code.

.cscfg und .csdef

Die .cscfg enthält Einstellungen je Umgebung, Instanzanzahlen und Fingerabdrücke von Zertifikaten. Die .csdef enthält Endpunkte, VM-Größe, lokalen Speicher, Starttasks, Zertifikatspeicher und manchmal mehrere IIS-Sites innerhalb einer Webrolle. Gehen Sie beide Zeile für Zeile durch und schreiben Sie auf, wo jeder Eintrag danach lebt: eine App-Einstellung, ein Key-Vault-Verweis, Infrastrukturcode oder nirgends. Interne Endpunkte, über die Rollen einander direkt aufrufen, brauchen einen Ersatz, entweder eine Dienstadresse oder eine Warteschlange.

Zertifikate

Extended Support hat Zertifikate bereits in Key Vault gezwungen, dieser Teil der Arbeit von 2024 zahlt sich also aus. Was sich ändert, ist, wie der Code sie findet. Eine .csdef installiert Zertifikate in einen benannten Speicher, oft LocalMachine. Auf Windows App Service macht die Einstellung WEBSITE_LOAD_CERTIFICATES sie in Current User\My verfügbar. Code, der den Speicher LocalMachine öffnet, findet nichts, und der erste Aufruf, der das Zertifikat braucht, scheitert. In Linux-Containern laden Sie es stattdessen beim Start aus Key Vault.

Starttasks

Öffnen Sie Startup.cmd. Hier leben die Überraschungen, typischerweise ausgeführt mit executionContext="elevated": Schriftarten für die PDF-Erzeugung, eine COM-Komponente, ein IIS-Rewrite-Modul, eine Registry-Änderung für TLS. Jede Zeile hat drei mögliche Schicksale: nicht mehr nötig, in ein Installationsskript auf Managed Instance verlagert oder in ein Container- oder VM-Image eingebaut.

Lokaler Speicher

Eine LocalStorage-Ressource in der .csdef, gelesen über RoleEnvironment.GetLocalResource, gab jeder Instanz Arbeitsspeicher auf der Platte. Verwenden Sie für echte Arbeitsdateien das temporäre Verzeichnis der Plattform. Alles, was einen Neustart überdauern muss, einschließlich Dateien, die jemand für dauerhaft gehalten hat, gehört in Blob Storage.

Web Forms

Das ist die Entscheidung, die alles andere bestimmt. Web Forms baut auf System.Web auf und hat keine Version für ASP.NET Core, eine Web-Forms-Anwendung nach Service Fabric oder Container Apps zu verschieben heißt also, ihre Benutzeroberfläche neu zu schreiben. App Service, Managed Instance, ein Windows-Container oder ein Scale Set können sie unverändert betreiben. Ziehen Sie sie so um, wie sie ist, und machen Sie die Modernisierung zu einem eigenen Projekt mit eigenem Budget. Eine Neuentwicklung der Oberfläche gehört nicht auf den kritischen Pfad eines Abschaltdatums.

Der Rest

Der VIP-Swap zwischen zwei Cloud Services wird zu Deployment-Slots auf App Service oder zu Revisionen auf Container Apps. Protokolle, die über die Diagnoseerweiterung (WAD) gesendet wurden, brauchen ein neues Ziel, meist Application Insights. Standard-App-Service und Container Apps bieten keinen Remotedesktop; Managed Instance erlaubt ihn über Azure Bastion, nur zur Diagnose.

Ein Sechsmonatsplan

Rückwärts vom 31. März 2027, mit den Dezemberfeiertagen in der Mitte.

Oktober: Bestandsaufnahme und Wahl der Ziele. Listen Sie jedes Deployment mit Extended Support auf. Halten Sie für jede Rolle die .NET-Framework-Version fest, Web Forms oder MVC, jeden Aufruf von RoleEnvironment, jeden Starttask, jede Ressource für lokalen Speicher, jedes Zertifikat und jeden Endpunkt. Prüfen Sie dann den unangenehmen Teil: Können Sie das bereitgestellte Paket aus dem Quellcode bauen, den Sie haben? Bei Systemen, die eine Agentur gebaut hat, lautet die Antwort manchmal nein, und Oktober ist der Monat, um das herauszufinden. Wählen Sie für jede Rolle ein Ziel.

November: eine Rolle, von Anfang bis Ende. Fügen Sie die Konfigurationskapsel hinzu, beschreiben Sie die Zielumgebung als Infrastrukturcode und bringen Sie eine Rolle (meist den einfachsten Worker) in einer Testumgebung zum Laufen, mit Protokollen, Zertifikaten und einer Pipeline.

Dezember und Januar: den Rest portieren. Ersetzen Sie Einstiegspunkte, Starttasks und lokalen Speicher. Testen Sie eine Staging-Umgebung unter Last mit produktionsähnlichen Daten: Ein WebJob oder Container erreicht möglicherweise nicht den Durchsatz einer dedizierten Rollen-VM.

Februar: Parallelbetrieb. Lassen Sie die neue Umgebung gegen echten Datenverkehr laufen. Bei Workern, die sich eine Warteschlange mit den alten Rollen teilen, machen Sie die Verarbeitung entweder vorher idempotent oder stoppen die alten Worker, bevor Sie die neuen starten.

Anfang März: umstellen. Schalten Sie das DNS mit zeitlichem Puffer um. Lassen Sie das alte Deployment ein bis zwei Wochen gestoppt, aber intakt, und löschen Sie es dann. Planen Sie die Umstellung nicht für die letzte Märzwoche: Eine gescheiterte Umstellung hat dann keinen zweiten Versuch.

Wenn Sie erst im Januar anfangen, streichen Sie die Modernisierung vollständig. Wählen Sie das Ziel mit den wenigsten Codeänderungen (App Service, Managed Instance oder Scale Sets), ziehen Sie um und refaktorieren Sie danach.

Was nicht klar ist

Microsoft sagt, der Dienst werde „vollständig eingestellt“ und eine Migration sei nötig, „um eine Unterbrechung des Dienstes zu vermeiden“. Die Seiten, die wir gelesen haben, sagen nicht, was mit einem Deployment passiert, das am 1. April 2027 noch läuft. Planen Sie nicht damit, es herauszufinden. Auch Regionen und Pläne für Managed Instance werden sich in den kommenden Monaten wahrscheinlich ändern, prüfen Sie sie also zum Zeitpunkt Ihrer Entscheidung und nicht anhand dieses Artikels.

Wo Sie Hilfe bekommen

Wir übernehmen Anwendungen, die andere gebaut haben, finden heraus, wie sie laufen, und ziehen sie um: die Bestandsaufnahme, das Ziel je Rolle, die Änderungen an RoleEnvironment und den Starttasks und die Umstellung. Unsere Wartung von Bestandssystemen deckt .NET Framework und Web Forms ab; wenn Ihr eigenes Team die Migration durchführt und zusätzliche Hände braucht, sehen Sie sich unsere Personalverstärkung an.

Wenn Sie ein Deployment auf Cloud Services haben und ein Datum, das sechs Monate entfernt ist, schreiben Sie an office@c9group.dev.