.NET 8 und .NET 9 laufen aus: Der Upgrade‑Fahrplan auf .NET 10 LTS

Jetzt beraten lassen!

Der Termin steht fest, und er ist näher, als viele Betriebskalender es abbilden: Am 10. November 2026 endet der Support für .NET 8 und .NET 9 – für beide Versionen am selben Tag. Ab dann liefert Microsoft keine Sicherheitsupdates, keine Servicing‑Releases und keinen technischen Support mehr. Die Anwendungen laufen weiter, aber jede danach bekannt werdende Schwachstelle in der Runtime bleibt offen.

Für Unternehmen, deren Website, Portal oder Individualsoftware auf .NET 8 oder 9 basiert, ist das weniger eine technische Fußnote als eine Frage der Betriebssicherheit und Compliance. Dieser Beitrag ordnet ein, was am Stichtag konkret passiert, warum .NET 10 LTS das richtige Ziel ist, was das Upgrade in der Praxis umfasst – und wie ein realistischer Fahrplan für die verbleibenden Wochen aussieht.

Inhaltsverzeichnis

• TLDR
• Was am 10. November 2026 konkret passiert
• Warum .NET 10 LTS das richtige Ziel ist – und nicht .NET 11
• Der Umbraco‑Faktor: CMS‑Version und .NET‑Version hängen zusammen
• Was ein .NET‑10‑Upgrade in der Praxis umfasst
• Der Fahrplan bis November
• Wie Cyber‑Solutions Kunden beim .NET‑10‑Upgrade unterstützt
• Fazit: Ein Upgrade beginnt man nicht im November

TLDR

• .NET 8 (LTS) und .NET 9 (STS) erreichen am 10. November 2026 gemeinsam das End of Support – danach gibt es keine Security‑Patches mehr.
• Das empfohlene Ziel ist .NET 10 LTS, unterstützt bis November 2028. .NET 11 erscheint zwar im November 2026, ist aber eine STS‑Version mit kürzerem Support.
• Umbraco 13 läuft auf .NET 8 und erreicht am 14. Dezember 2026 selbst das End of Life. Der Weg führt auf Umbraco 17 LTS auf .NET 10 – inklusive neuem Backoffice.
• Das Upgrade der Runtime ist selten das Problem. Aufwand entsteht durch Drittpakete, Individualcode, Hosting‑Umgebung und Tests.
• Wer jetzt inventarisiert und priorisiert, migriert geordnet. Wer im November beginnt, migriert unter Druck.

Was am 10. November 2026 konkret passiert

Microsoft hat den Termin eindeutig kommuniziert: Am 10. November 2026 – einem Patch Tuesday – enden die Support‑Zeiträume von .NET 8 und .NET 9 gleichzeitig. Bei .NET 8 sind damit die drei Jahre Long‑Term Support seit November 2023 vorbei. .NET 9 als Standard‑Term‑Support‑Version endet nach 24 Monaten am selben Tag. Beide Versionen erhalten an diesem Tag gegebenenfalls ein letztes Update, danach nichts mehr.

Was das bedeutet, ist im Kern einfach: Die Anwendungen laufen weiter, es ändert sich zunächst nichts an ihrem Verhalten. Was sich ändert, ist die Risikolage. Sicherheitslücken in Runtime, ASP.NET Core oder den Basisbibliotheken, die nach dem Stichtag entdeckt werden, bleiben in .NET 8 und 9 ungepatcht. Für öffentlich erreichbare Websites, Portale mit Login und Anwendungen mit Kundendaten ist das ein Zustand, den kein IT‑Verantwortlicher lange verantworten möchte – und den Auditoren, Versicherer und Compliance‑Vorgaben zunehmend explizit abfragen.

Hinzu kommt ein praktischer Effekt: Microsoft kündigt an, dass Visual Studio 2022 die .NET‑8‑ und .NET‑9‑Komponenten künftig als „out of support“ kennzeichnet. Auch Drittanbieter von Bibliotheken und Plattformen ziehen ihre Unterstützung typischerweise mit dem Microsoft‑Lifecycle zurück. Wer auf einer nicht mehr unterstützten Runtime bleibt, verliert also schrittweise auch die Aktualisierbarkeit seiner Abhängigkeiten.

Warum .NET 10 LTS das richtige Ziel ist – und nicht .NET 11

Microsoft empfiehlt das Upgrade auf .NET 10. Die Version ist seit November 2025 verfügbar, trägt das LTS‑Label und wird bis November 2028 unterstützt. Für Plattformen, die über Jahre stabil laufen sollen, ist das der entscheidende Punkt: drei Jahre Planungssicherheit statt eines erneuten Upgrade‑Zwangs nach zwei Jahren.

Die Frage nach .NET 11 kommt in Gesprächen regelmäßig, weil die Version voraussichtlich im November 2026 erscheint – also fast zeitgleich mit dem Support‑Ende von 8 und 9. Für den Betrieb von Unternehmensplattformen ist sie trotzdem nicht die bessere Wahl. .NET 11 ist nach dem Release‑Rhythmus von Microsoft eine STS‑Version mit 24 Monaten Support. Wer darauf setzt, steht Ende 2028 erneut vor einem Upgrade – ohne gegenüber .NET 10 nennenswert länger abgesichert zu sein. Für Web‑Plattformen, CMS‑Installationen und Individualsoftware im Unternehmenseinsatz ist der Wechsel von LTS zu LTS die ruhigere Linie.

Wer aktuell noch ältere Versionen wie .NET 6 betreibt, deren Support bereits Ende 2024 ausgelaufen ist, sollte das Upgrade ohnehin nicht weiter aufschieben und direkt auf .NET 10 zielen, statt Zwischenschritte einzulegen.

Der Umbraco‑Faktor: CMS‑Version und .NET‑Version hängen zusammen

Bei CMS‑basierten Plattformen ist die .NET‑Version keine freie Entscheidung, sondern an die CMS‑Version gekoppelt. Umbraco richtet seine Major‑Releases explizit am .NET‑Rhythmus aus: Umbraco 13 LTS basiert auf .NET 8, Umbraco 16 auf .NET 9, Umbraco 17 LTS auf .NET 10.

Daraus ergibt sich für viele Umbraco‑Betreiber eine doppelte Deadline. Umbraco 13 – die verbreitete LTS‑Version der letzten Jahre – erreicht am 14. Dezember 2026 selbst das End of Life. Umbraco 16 auf .NET 9 ist bereits seit Juni 2026 ohne Support. Der stabile Zielpunkt ist Umbraco 17 LTS auf .NET 10, das bis November 2028 unterstützt wird – also im Gleichschritt mit der .NET‑Basis.

Der Weg von Umbraco 13 auf 17 ist dabei mehr als ein Framework‑Wechsel. Mit Umbraco 14 wurde das Backoffice vollständig neu aufgebaut. Individuelle Backoffice‑Erweiterungen wie eigene Property‑Editoren, Dashboards oder Sektionen aus der 13er‑Welt laufen in der neuen Architektur nicht einfach weiter, sondern müssen neu umgesetzt werden. Das Frontend, die Content‑Struktur und die meisten Standardfunktionen migrieren dagegen in der Regel geordnet. Wer Umbraco 13 mit vielen Backoffice‑Anpassungen betreibt, plant hier realistisch mehr Aufwand ein – wer nahe am Standard geblieben ist, deutlich weniger.

Für Xperience by Kentico gilt das Prinzip ähnlich: Neue Versionen folgen der jeweils aktuellen .NET‑Basis, und welcher Stand im eigenen Projekt läuft, gehört ganz vorne in die Bestandsaufnahme. Auch bei Individualsoftware ohne CMS lohnt der Blick auf die Abhängigkeiten: Bibliotheken für Authentifizierung, PDF‑Erzeugung, Reporting oder Schnittstellen haben eigene Kompatibilitätsmatrizen, die den Upgrade‑Pfad mitbestimmen.

Was ein .NET‑10‑Upgrade in der Praxis umfasst

Der oft zitierte Satz „einfach das TargetFramework auf net10.0 stellen“ stimmt – und beschreibt zugleich den kleinsten Teil der Arbeit. In Projekten zeigt sich immer wieder, dass der Aufwand nicht in der Runtime steckt, sondern in dem, was um sie herum gewachsen ist.

Da sind zunächst die Abhängigkeiten: NuGet‑Pakete, die für .NET 10 aktualisiert werden müssen, Pakete, die es in einer kompatiblen Version noch nicht gibt, und Pakete, deren Anbieter nicht mehr weiterentwickeln. Jede dieser Kategorien braucht eine Entscheidung – aktualisieren, ersetzen oder ablösen. Dann die Breaking Changes zwischen den Versionen: Sie sind pro Release überschaubar und dokumentiert, betreffen aber gerne genau die Stellen, an denen Individualcode tief in Framework‑Verhalten eingreift – Middleware, Serialisierung, Authentifizierung, Hintergrunddienste.

Der dritte Block ist die Umgebung: Build‑Pipelines, Container‑Images, App‑Service‑Konfigurationen in Azure, lokale Entwicklungsumgebungen und Server, auf denen die neue Runtime installiert und die alte abgelöst wird. Und schließlich das Testen. Ein Upgrade ohne Regressionstests ist ein Upgrade auf Verdacht. Wo automatisierte Tests fehlen, braucht es zumindest einen belastbaren manuellen Testplan für die kritischen Pfade: Login, Formulare, Schnittstellen, Suche, Checkout.

Der Aufwand ist deshalb keine pauschale Größe. Eine schlanke Anwendung mit aktuellen Abhängigkeiten ist in kurzer Zeit umgestellt. Eine gewachsene Plattform mit vielen Integrationen und älteren Paketen braucht ein eigenes kleines Projekt. Genau das lässt sich aber im Vorfeld einschätzen – wenn man es tut.

Der Fahrplan bis November

Bis zum Stichtag bleiben von heute aus gerechnet rund zwei Monate. Das ist für die meisten Anwendungen ausreichend, wenn der Ablauf strukturiert ist – und knapp, wenn erst im Oktober begonnen wird. Ein bewährter Fahrplan sieht so aus:

Am Anfang steht die Inventur: Welche Anwendungen laufen auf welcher .NET‑Version? Welche CMS‑Version steckt dahinter? Welche Abhängigkeiten sind kritisch? Darauf folgt die Priorisierung nach Exposition und Geschäftsrelevanz – öffentlich erreichbare Systeme mit Login oder Kundendaten zuerst, interne Werkzeuge danach. Für jede Anwendung wird der Aufwand geschätzt und das Zeitfenster festgelegt.

Die Umstellung selbst beginnt in einer Staging‑Umgebung: TargetFramework anheben, Abhängigkeiten aktualisieren, Build lauffähig machen, Breaking Changes abarbeiten. Danach Regressionstests, Freigabe durch die Fachseite und ein geplanter Rollout mit Rückfallmöglichkeit. Wo die Anwendung ohnehin vor einem größeren Schritt steht – etwa Umbraco 13 auf 17 –, wird das .NET‑Upgrade Teil dieses Projekts, nicht ein separater Vorlauf.

Wichtig ist, den Fahrplan an den realen Rahmenbedingungen auszurichten: Freigabefenster der Fachabteilungen, Change‑Freezes im Jahresendgeschäft, Verfügbarkeit der Entwickler. Wer diese Faktoren jetzt einplant, erlebt den 10. November als Termin im Kalender – nicht als Ereignis.

Wie Cyber‑Solutions Kunden beim .NET‑10‑Upgrade unterstützt

Cyber‑Solutions betreut als Microsoft Gold Partner, Umbraco Platinum Partner und Kentico Partner eine Vielzahl von .NET‑basierten Plattformen im laufenden Betrieb – von Corporate Websites über Portale bis zu Individualsoftware. Aktuell gehen wir gezielt auf unsere Kunden zu, deren Anwendungen auf .NET 8 oder 9 laufen, und legen pro Anwendung eine konkrete Aufwandseinschätzung und ein Zeitfenster vor.

Das Vorgehen ist dabei immer dasselbe: Bestandsaufnahme der Anwendungen und Abhängigkeiten, Einschätzung pro System, Upgrade in Staging inklusive Aktualisierung der Pakete und Anpassung der Hosting‑Umgebung, Regressionstests und geordneter Rollout. Bei Umbraco‑Plattformen bewerten wir zusätzlich den Weg auf Umbraco 17 LTS und den Anteil an Backoffice‑Erweiterungen, der neu umgesetzt werden muss. Unternehmen, die ihre .NET‑Anwendungen nicht bei uns betreiben, können denselben Upgrade‑Check als eigenständige Leistung anfragen.

Fazit: Ein Upgrade beginnt man nicht im November

Der 10. November 2026 ist kein überraschender Termin, sondern ein seit Jahren angekündigter Lifecycle‑Schritt. Das Ziel ist klar: .NET 10 LTS, bei Umbraco‑Plattformen in Verbindung mit Umbraco 17 LTS. Der Aufwand hängt weniger von der Runtime ab als von Abhängigkeiten, Individualcode und Umgebung – und lässt sich jetzt zuverlässig einschätzen. Wer diese Einschätzung in den nächsten Wochen macht, entscheidet über Reihenfolge und Zeitpunkt selbst.

Jetzt Upgrade-Check anfragen