Support-Ende für .NET 8 und .NET 9: Was bis zum 10. November 2026 - zu tun ist

Was am 10. November passiert — und was nicht

Zunächst die Entwarnung: Deine Anwendungen laufen am 11. November genauso weiter wie am 9. Es gibt keinen Schalter, der umgelegt wird, keine Runtime, die sich deaktiviert.

Was sich ändert, ist unsichtbar — und genau deshalb relevant: Am 10. November kann bei einer bekannten kritischen Schwachstelle noch ein letztes Update erscheinen. Danach liefert Microsoft für .NET 8 und .NET 9 keine Sicherheitsupdates mehr. Neu entdeckte Schwachstellen werden für diese Versionen nicht mehr durch Microsoft-Updates geschlossen. Ob eine konkrete Anwendung betroffen ist, muss dann im Einzelfall bewertet und gegebenenfalls anderweitig mitigiert werden. Weil Patches für neuere Versionen öffentlich dokumentiert sind, erhalten Angreifer zugleich Hinweise darauf, wonach sie in älteren Versionen suchen können.

Warum zwei Versionen gleichzeitig?

Das ist kein Versehen, sondern Microsofts Release-Rhythmus. Jedes Jahr im November erscheint eine neue .NET-Version — in ungeraden Jahren als LTS (Long Term Support, 3 Jahre), in geraden als STS (Standard Term Support, inzwischen 24 Monate). .NET 8 (LTS, November 2023) erreicht nun das Ende seiner drei Jahre; .NET 9 (STS, November 2024) das Ende seiner 24 Monate — beides am 10. November 2026.

Die Konsequenz: Anders als bei manchem früheren Übergang gibt es diesmal kein „wir sind ja schon auf der neueren Version". Wer auf 8 oder 9 ist, muss auf 10 — und das steht als LTS seit November 2025 bereit (Support bis November 2028).

Warum das ein Business-Thema ist, kein reines Tech-Thema

„Keine Patches mehr" klingt nach einem Problem für die Entwicklungsabteilung. In der Praxis landet es woanders:

Audits und Zertifizierungen. Nicht mehr unterstützte Software in Produktion wird bei Audits und Kunden-Assessments regelmäßig hinterfragt — insbesondere dann, wenn Sicherheitsupdates fehlen und kein dokumentierter Risikoplan existiert. „Wir wussten es nicht" ist dabei die schlechteste aller Antworten.

Kundenverträge und Lieferkette. Wer Software an andere Unternehmen liefert oder betreibt, hat oft vertragliche Zusagen zum Sicherheitsniveau. Und wer selbst einkauft, sollte die Frage umdrehen: Welche eingekauften Produkte bringen ihre eigene .NET-8-Runtime mit — und was sagt deren Hersteller zum 10. November?

Bin ich betroffen? Der 15-Minuten-Erstcheck

Die ehrliche Antwort vieler Teams auf „Welche Services laufen bei euch auf .NET 8 oder 9?" ist: „Müssten wir nachsehen." Genau das ist der erste Schritt — und er ist klein:

Eigener Code: Alle Repositories nach net8.0 und net9.0 durchsuchen — nicht nur in .csproj-Dateien, sondern auch in zentralen Build-Dateien wie Directory.Build.props. Zusätzlich global.json auf festgelegte SDK-Versionen prüfen.
Server, Container und Deployment-Artefakte: dotnet --list-runtimes auf den Hosts ausführen, Container-Base-Images und Deployment-Manifeste prüfen (z. B. auf mcr.microsoft.com/dotnet/aspnet:8.0). Self-contained veröffentlichte Anwendungen separat erfassen, da ihre Runtime nicht in der systemweiten Liste erscheint.
Die vergessenen Ecken: CI/CD-Agents, Windows-Services, interne Tools, geplante Tasks — die kleinen Helfer, die seit Jahren unbeachtet laufen.
Fremdsoftware: Eingekaufte Produkte mit eigener .NET-Runtime identifizieren und die Hersteller nach ihrem Zeitplan fragen. Diese Antworten dauern erfahrungsgemäß am längsten — deshalb früh fragen.

Das Ergebnis des Erstchecks ist eine vorläufige Liste: Service, Version und Kritikalität (extern erreichbar? Kundendaten?). Sie ist die Grundlage für eine vollständige Inventur und eine grobe Aufwandsschätzung — und macht aus einem diffusen Thema ein planbares Arbeitspaket.

Der Weg zu .NET 10 — realistischer Aufwand

Die gute Nachricht: Der Sprung von .NET 8 oder 9 auf .NET 10 ist in den meisten Fällen ein moderates Upgrade, keine Migration im großen Stil. Der typische Ablauf pro Service:

Entwicklungsumgebung und Build-Agents auf das .NET-10-SDK vorbereiten; festgelegte SDK-Versionen in global.json aktualisieren
Target Framework auf net10.0 anheben
NuGet-Pakete und Vendor-SDKs auf Kompatibilität prüfen und bei Bedarf aktualisieren
Breaking Changes prüfen: beim Sprung von 8 auf 10 sowohl die Änderungen in .NET 9 als auch in .NET 10 berücksichtigen, einschließlich der verwendeten ASP.NET-Core- und EF-Core-Komponenten
Tests laufen lassen, Auffälligkeiten beheben
CI/CD-Pipelines, Hosting-Runtimes und Container-Base-Images umstellen; self-contained Anwendungen mit aktueller Runtime neu veröffentlichen
Deployment und Beobachtung

Microsoft dokumentiert den Upgrade-Ablauf und die Breaking Changes für .NET 9 und .NET 10. Auch nach dem Upgrade gehören aktuelle .NET-10-Patches zum laufenden Betrieb.

Bei einer gut getesteten Codebasis kann das pro Service in wenigen Tagen erledigt sein. Bei komplexen Abhängigkeiten, veralteten Paketen oder schwacher Testabdeckung kann der Aufwand deutlich höher liegen. Häufig bestimmt die langsamste Abhängigkeit den Zeitplan: das NuGet-Paket, das .NET 10 noch nicht unterstützt, oder das Vendor-SDK, dessen Hersteller sich Zeit lässt. Deshalb gehört der Blick in die Paketliste an den Anfang der Planung, nicht ans Ende.

Zwei Hinweise aus der Praxis:

Nicht auf „stabiler werden" warten. .NET 10 ist seit November 2025 auf dem Markt und hat bereits zahlreiche monatliche Updates erhalten. Die Phase, in der Vorsichtige das erste Patch-Release abwarten, ist längst vorbei. Der Reflex „wir schauen erst mal" bedeutet in diesem Fall: bewusst ohne Security-Patches durch den Winter, während die ausgereifte Alternative bereitsteht.

Das Upgrade nicht mit einem Umbau koppeln. „Wenn wir schon dabei sind, modernisieren wir gleich richtig" klingt effizient — koppelt aber eine harte Security-Deadline an ein Projekt mit offenem Ende. Erst supported, dann schöner. Die Modernisierung verdient einen eigenen Plan, mit .NET 10 als stabilem Fundament.

Wenn der 10. November nicht mehr zu halten ist

Manchmal ist die Landschaft zu groß oder die Abhängigkeit zu störrisch. Dann gilt: Priorisieren statt resignieren.

Extern erreichbare Services und alles, was Kundendaten hält, zuerst. Für den Rest: das Restrisiko schriftlich festhalten und Übergangsmaßnahmen treffen — Erreichbarkeit einschränken, Netzwerk segmentieren, vorgelagerte Schutzschichten. Wichtig ist der Charakter dieser Maßnahmen: eine Brücke mit Enddatum, kein Dauerzustand. Ein dokumentiertes Restrisiko mit Abbauplan ist bei Audits und Kunden-Assessments zumindest nachvollziehbar; ein unbemerktes ist es nicht.

Checkliste

Inventur: alle Services, Versionen, Kritikalität (diese Woche)
Abhängigkeiten prüfen: NuGet-Pakete und Vendor-SDKs mit .NET-10-Status
Hersteller von Fremdsoftware anschreiben
Reihenfolge festlegen: extern erreichbar und kundendatennah zuerst
Upgrades durchführen: SDK, Target Framework, Paketkompatibilität, Breaking Changes, Tests, Hosting, Pipelines, Images
Für Nachzügler: Restrisiko dokumentieren, Übergangsmaßnahmen mit Enddatum
Für 2027 ff.: Runtime-Upgrades als festen Kalenderpunkt etablieren

Brauchst du Unterstützung?

Ich helfe Unternehmen seit 15+ Jahren dabei, .NET-Landschaften zu modernisieren — von der Bestandsaufnahme über das Upgrade bis zur Architektur, die das nächste Support-Ende zur Routine macht. Remote, planbar, ohne Drama.

Wenn du wissen willst, wie das für eure Landschaft aussehen könnte: Kostenloses Erstgespräch buchen → — 60 Minuten über das, woran ihr arbeitet, und ob ich dabei helfen kann. Kein Verkaufsgespräch.