Supportende am 10. November 2026: .NET 8, .NET 9 und Azure Functions In-Process — was jetzt zu tun ist

Am 10. November 2026 passiert in vielen Unternehmen: nichts. Kein Ausfall, kein Alarm, keine Fehlermeldung. Die Anwendungen laufen einfach weiter — und genau das ist das Problem. An diesem Tag endet der Support für .NET 8, für .NET 9 und für das In-Process-Modell von Azure Functions. Ab dann gibt es dafür keine Sicherheitsupdates mehr.

Dieser Artikel fasst zusammen, was genau ausläuft, warum das Energieversorger mit öffentlich erreichbaren Kundenportalen besonders trifft und wie ein Upgrade aussieht, das in Produktion nicht wehtut. Stand: Oktober 2026.

Das Wichtigste in Kürze

• 10. November 2026: Supportende für .NET 8 (LTS), .NET 9 (STS) und Azure Functions im In-Process-Modell.
• Die Apps laufen weiter, bekommen aber keine Sicherheitsupdates mehr; Microsoft und Azure leisten für diese Versionen keinen Support mehr.
• Das Ziel heißt .NET 10 (LTS, Support bis 14. November 2028).
• Azure Functions im In-Process-Modell können nicht einfach auf .NET 10 — sie müssen auf das Isolated-Worker-Modell umziehen.
• Das Upgrade ist mehr als eine Versionsnummer: Code und NuGet-Pakete, Functions, Pipelines und Infrastruktur müssen zusammenpassen.

Was genau endet

.NET 8 ist eine LTS-Version mit drei Jahren Support. .NET 9 wäre eigentlich schon im Mai 2026 ausgelaufen; Microsoft hat den Support für STS-Versionen aber von 18 auf 24 Monate verlängert. Deshalb enden beide am selben Tag.

Der dritte Punkt wird am häufigsten übersehen: Azure Functions im In-Process-Modell laufen nur mit .NET 8. Einen Weg auf eine neuere Version gibt es dort nicht. Wer mit seinen Functions auf .NET 10 will, muss das Modell wechseln.

Und .NET 11? Es erscheint im November 2026 und wird dank der neuen STS-Regel ebenfalls bis 2028 unterstützt. Für ein Upgrade unter Zeitdruck ist .NET 10 trotzdem die bessere Wahl: Es ist seit fast einem Jahr im Einsatz und gut erprobt.

Was „Supportende" wirklich heißt

Supportende heißt nicht Abschaltung. Microsoft schreibt selbst, dass Anwendungen auf .NET 8 und 9 weiterlaufen; Azure App Service und Azure Functions betreiben sie weiter.

Was fehlt, sind Updates. .NET bekommt in der Regel jeden Monat am Patch Tuesday neue Versionen, oft mit geschlossenen Sicherheitslücken. Für .NET 8 und 9 ist nach dem 10. November damit Schluss. Die nächste kritische Lücke, die bekannt wird, bleibt in der Anwendung offen.

Dazu kommt der Support: Für Azure App Service gilt, dass eine App auf einer Runtime ohne Support erst auf eine unterstützte Version gebracht werden muss, bevor es Support gibt.

Warum es Energieversorger besonders trifft

1. Kundenportale sind öffentlich erreichbar. Sie verarbeiten personenbezogene Daten: Adressen, Zählerstände, Bankverbindungen. Eine offene Lücke ist hier kein theoretisches Risiko.
2. Regulierung. Seit dem 6. Dezember 2025 gilt in Deutschland das NIS-2-Umsetzungsgesetz, und Energie gehört zu den Sektoren mit hoher Kritikalität. § 30 BSIG verlangt ausdrücklich „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung …, einschließlich Management und Offenlegung von Schwachstellen". In einem Audit liegt die Frage nahe: Warum läuft auf unserem Kundenportal Software ohne Sicherheitsupdates?
3. Zeit. Change-Prozesse, Freigaben, Testfenster: In regulierten Umgebungen dauert ein Upgrade oft nicht Tage, sondern Wochen.

Mehr als eine Versionsnummer

Auf dem Papier ist ein .NET-Upgrade eine Zeile im Projekt:

<!-- vorher -->
<TargetFramework>net8.0</TargetFramework>
<!-- nachher -->
<TargetFramework>net10.0</TargetFramework>

In der Praxis betrifft es vier Ebenen.

1. Code und NuGet-Abhängigkeiten

Jede Bibliothek muss mitziehen. Manche Pakete gibt es nicht mehr, manche bringen Breaking Changes mit. Dazu gehört auch das SDK für Dynamics 365, wenn die Anwendung mit dem CRM spricht. Ein dotnet list package --outdated und --deprecated zeigt früh, wo die eigentliche Arbeit liegt.

2. Azure Functions: vom In-Process- zum Isolated-Worker-Modell

Der Wechsel ist ein echter Umbau:

• neue Pakete (Microsoft.Azure.Functions.Worker.* statt Microsoft.Azure.WebJobs.*)
• eine neue Program.cs statt FunctionsStartup
• [Function] statt [FunctionName], Input- und Output-Bindings heißen anders
• Logging über Dependency Injection (ILogger<T>) statt ILogger-Parameter
• FUNCTIONS_WORKER_RUNTIME = dotnet-isolated

public class Zaehler
{
    // In-Process (Newtonsoft.Json): wird aus "zaehler_nr" befüllt.
    // Isolated (System.Text.Json): Attribut wird ignoriert → Zaehlernummer bleibt null.
    [JsonProperty("zaehler_nr")]
    public string Zaehlernummer { get; set; }
}

Lösung: die Attribute auf [JsonPropertyName("zaehler_nr")] umstellen oder Newtonsoft.Json für diese Payloads bewusst konfigurieren — und dafür Tests schreiben, die genau diese Felder prüfen.

3. Pipelines

Wenn die Azure-DevOps-Pipeline noch das SDK für .NET 8 installiert, bricht der Build mit NETSDK1045 ab:

- task: UseDotNet@2
  inputs:
    version: '10.x'   # vorher '8.x'

Und ohne automatisierte Tests fallen Breaking Changes erst in Produktion auf.

4. Infrastruktur als Code

Wenn Terraform noch die alte Runtime-Einstellung kennt, setzt das nächste Deployment sie zurück. Dann passen Konfiguration und Code nicht mehr zusammen, und die Functions laufen nicht (Fehler AZFD0013). Runtime-Version und Worker-Modell gehören deshalb in denselben Change wie der Code:

app_settings = {
  FUNCTIONS_WORKER_RUNTIME = "dotnet-isolated"
}

Der Plan in fünf Schritten

1. Inventur. Welche Anwendungen laufen auf .NET 8 oder 9? Welche Function Apps nutzen noch das In-Process-Modell? Für Azure Functions liefert Microsoft ein PowerShell-Skript, das diese Apps auflistet — im Kern:

   Get-AzFunctionApp | Where-Object Runtime -eq 'dotnet'

2. Priorisieren. Was öffentlich erreichbar ist und Kundendaten verarbeitet, kommt zuerst. Interne Batch-Jobs danach.

3. Upgrade in einem eigenen Branch, mit automatisierten Tests. Der Upgrade-Agent in GitHub Copilot kann einen Teil der Fleißarbeit übernehmen; die Entscheidungen und die Tests bleiben beim Team.

4. Deployment über einen Staging-Slot. Erst dort testen, dann tauschen. Die Produktion sieht keinen Zwischenzustand, und ein Rollback ist ein zweiter Tausch.

5. Beobachten. Application Insights und Azure Monitor zeigen in den ersten Tagen, ob sich Fehlerraten oder Antwortzeiten verändern.

Wenn es bis zum 10. November nicht klappt

Dann fällt am 11. November trotzdem nichts aus. Aber treffen Sie eine bewusste Entscheidung:

• Risiko dokumentieren.
• Angriffsfläche verkleinern, zum Beispiel indem interne APIs nur noch über Private Endpoints erreichbar sind.
• Einen festen Termin für das Upgrade setzen.

Ein dokumentierter Plan mit Datum ist besser als ein stilles „läuft doch".

Das nächste Datum: 12. Januar 2027

Am 12. Januar 2027 endet der Support für Windows Server 2016. Das betrifft Sie, wenn .NET-Anwendungen noch auf eigenen Servern mit IIS laufen — ein guter Anlass, die Migration nach Azure App Service gleich mitzuplanen.

Aus der Praxis

In meinem letzten Projekt bei einem Energiekonzern habe ich eine Anwendung von .NET 5 auf .NET 8 gebracht. Die eigentliche Arbeit war nicht die Versionsnummer, sondern veraltete Abhängigkeiten zu ersetzen und ihre Breaking Changes sauber aufzulösen. Dort habe ich auch die komplette Infrastruktur in Terraform und alle Pipelines in Azure DevOps geschrieben und Anwendungen von IIS nach Azure App Service migriert. Details in den Projektseiten unten.

Quellen

• .NET Blog: .NET 8 and .NET 9 will reach End of Support on November 10, 2026
• .NET Support Policy
• .NET STS releases supported for 24 months
• Azure Functions: Migrate C# apps from the in-process model to the isolated worker model
• Azure App Service: Language runtime support policy
• BSI: NIS-2-Umsetzungsgesetz in Kraft
• § 30 BSIG
• Windows Server 2016 end of support