Azure Functions und App Service: Welche Laufzeiten ab 10. November keinen Support mehr haben

Die Termine im Überblick

Jeweils mit dem Ziel, das Microsoft für die Umstellung nennt:

Microsoft richtet die Daten nach den Supportzeiträumen der jeweiligen Sprache aus. .NET 9 war ursprünglich nur bis Mai 2026 vorgesehen. Weil Microsoft den Support für .NET-Versionen mit Standardlaufzeit auf 24 Monate verlängert hat, endet .NET 9 jetzt am selben Tag wie .NET 8. Das Ziel .NET 10 wird bis 14. November 2028 unterstützt.

Was nach dem Stichtag passiert

Für Functions beschreibt Microsoft das Vorgehen genauer als für App Service. Apps mit einer ausgelaufenen Version lassen sich weiter erstellen und bereitstellen und laufen weiter. Sie erhalten aber keine Sicherheitsupdates, Fehlerbehebungen und Leistungsverbesserungen mehr.

Ein Satz in der Richtlinie wird leicht überlesen: Wenn nötig, begrenzt Microsoft in bestimmten Fällen die Zahl der Instanzen solcher Apps, bis hin zur Skalierung auf eine einzige Instanz. Für eine App, die unter Last auf zehn Instanzen wächst, wird aus der Supportfrage damit eine Verfügbarkeitsfrage.

App Service formuliert es knapper: Die App läuft unverändert weiter, Sicherheitspatches und Support für die Laufzeit gibt es nach dem Stichtag nicht mehr.

Das In-Process-Modell ist der größte Aufwand

Für .NET 8 im isolierten Modell reicht in der Regel ein Wechsel der Zielversion auf .NET 10 mit aktualisierten Paketen und anschließendem Test. Apps im In-Process-Modell müssen zuerst in das isolierte Modell migriert werden, denn das In-Process-Modell unterstützt nur .NET 8 und endet am selben Tag. Das bedeutet Änderungen an Projektdatei, Paketen, Startcode, Funktionssignaturen und Bindungen.

Zwei Details aus dem Leitfaden von Microsoft sind in der Praxis wichtig. Das isolierte Modell nutzt System.Text.Json statt Newtonsoft.Json und ignoriert Attribute wie [JsonProperty] ohne Fehlermeldung, betroffene Eigenschaften erhalten dann still ihren Standardwert. Und wer die App-Einstellung FUNCTIONS_WORKER_RUNTIME auf dotnet-isolated stellt, bevor der neue Code bereitgestellt ist, erzeugt bis dahin den Fehler AZFD0013. Microsoft empfiehlt dafür einen Staging-Slot. Im Flex-Consumption-Plan gibt es keine Slots.

Wer auf Bibliotheken angewiesen ist, die nur unter .NET Framework laufen, kann im isolierten Modell .NET Framework 4.8 als Ziel wählen.

Linux-Verbrauchsplan: zuerst der Plan, dann die Version

Für Apps im Linux-Verbrauchsplan (Consumption) kommt eine Hürde dazu. Microsoft fügt dort keine neuen Sprachversionen mehr hinzu. .NET 9, Node.js 22, Python 3.12, Java 21 und PowerShell 7.4 sind dort die letzten Versionen. Für .NET 10, Node.js 24 oder PowerShell 7.6 muss die App vorher in den Flex-Consumption-Plan wechseln.

Der Linux-Verbrauchsplan selbst wird am 30. September 2028 eingestellt. Apps mit der Functions-Laufzeit v3 laufen dort laut Microsoft seit dem 30. September 2026 nicht mehr. Der Verbrauchsplan unter Windows ist von beidem nicht betroffen.

Betroffene Apps finden

Das Skript listet für alle Function Apps der aktuellen Subscription das Laufzeitmodell und die eingestellten Versionen. Der Wert dotnet bei FUNCTIONS_WORKER_RUNTIME steht für das In-Process-Modell, dotnet-isolated für das isolierte.

(az functionapp list --query "[].{name:name, rg:resourceGroup}" | ConvertFrom-Json) | ForEach-Object {
  $c = az functionapp config show -n $_.name -g $_.rg | ConvertFrom-Json
  $s = az functionapp config appsettings list -n $_.name -g $_.rg | ConvertFrom-Json
  [pscustomobject]@{
    App        = $_.name
    Worker     = ($s | Where-Object name -eq 'FUNCTIONS_WORKER_RUNTIME').value
    Linux      = $c.linuxFxVersion
    DotNet     = $c.netFrameworkVersion
    PowerShell = $c.powerShellVersion
    Node       = ($s | Where-Object name -eq 'WEBSITE_NODE_DEFAULT_VERSION').value
  }
} | Format-Table

Bei Linux-Apps zählt linuxFxVersion, bei Windows-Apps netFrameworkVersion. Zum Lesen der App-Einstellungen genügt die Rolle Leser nicht. Für Web-Apps in App Service liefern az webapp list und az webapp config show dieselben Angaben.

Die Erinnerungen erreichen oft die Falschen

App Service schickt die Hinweise auf auslaufende Laufzeiten an die klassischen Rollen Kontoadministrator, Dienstadministrator und Co-Administrator. Mitwirkende und Leser erhalten sie nur, wenn sie über Service-Health-Warnungen eingebunden sind. In Umgebungen, die nur mit Azure-RBAC arbeiten, landen die Mails so leicht bei Personen, die die App nicht betreuen. Eine Service-Health-Warnung an die zuständigen Teams schließt diese Lücke.

Was ich vor dem 10. November prüfen würde

• Alle Function Apps mit FUNCTIONS_WORKER_RUNTIME dotnet: Sie brauchen die Migration in das isolierte Modell, ein Versionswechsel allein genügt nicht.
• Apps im Linux-Verbrauchsplan: zuerst der Wechsel zu Flex Consumption, dann die neue Version.
• CI/CD-Pipelines und Infrastrukturvorlagen, die Laufzeit und Version fest setzen. Sonst stellt die nächste Bereitstellung den alten Stand wieder her.
• Einen Staging-Slot für jede produktive App, die einen haben kann. Die Umstellung startet die App neu, laut Microsoft typischerweise für 30 bis 60 Sekunden.

Wie sich die Umstellung planen lässt

Ein Architekturreview erfasst alle Function Apps und Web-Apps mit Laufzeit, Hostingplan und Bereitstellungsweg und legt die Reihenfolge fest: zuerst, was am 10. November ausläuft, danach Node.js und Java im Jahr 2027. Umgestellt wird von Ihrem Team oder Ihrem Dienstleister, das Review liefert die Liste dazu.