.NET-Support endet: Fragen Sie Ihren Softwarelieferanten

Ein Stichtag für eine Software, die Sie nie gesehen haben

.NET sieht man nicht. Man sieht die Warenwirtschaft, in der die Aufträge erfasst werden. Das Kassensystem an der Theke. Das Programm, mit dem die Disposition ihre Touren plant. Dass unter vielen dieser Anwendungen eine Laufzeitumgebung von Microsoft arbeitet, steht weder im Angebot noch auf der Rechnung — es ist eine technische Voraussetzung, die der Hersteller Ihrer Software gewählt hat, nicht Sie.

Genau deshalb ist der 10. November 2026 ein ungewöhnlicher Termin: An diesem Tag endet Microsofts Support für .NET 8 und .NET 9 — für beide Versionen am selben Tag, obwohl .NET 9 die neuere ist. Und weil Sie diese Schicht nie ausgewählt haben, werden Sie das Support-Ende auch nicht an Ihrer Software bemerken. Bemerkbar wird es an einer anderen Stelle: dann nämlich, wenn Ihr Lieferant Ihnen eine neue Programmversion ankündigt, die plötzlich andere Anforderungen an den Server stellt — oder wenn er es versäumt, das rechtzeitig zu tun.

Vorweg die Einordnung, um die es in diesem Beitrag geht: Der 10. November 2026 beendet die Pflege durch Microsoft. Er beendet nicht zwangsläufig die Pflege Ihres Systems. Das hängt davon ab, woher das .NET auf Ihrem Server stammt.

Auf einen Blick

• .NET 8 und .NET 9 erreichen beide am 10. November 2026 das Ende von Microsofts Support. .NET 10 ist bis zum 14. November 2028 versorgt.
• Ihre Anwendung läuft danach technisch unverändert weiter. Was endet, ist der Nachschub aus Microsofts eigener Pflege: Sicherheitsupdates und technischer Support für diese beiden Versionen.
• Die neuere Version ist hier die schlechter gestellte. .NET 8 liegt in den Ubuntu-LTS-Releases im Hauptarchiv und hat dadurch einen zugesagten Puffer über den Stichtag hinaus. Für .NET 9 aus dem Backports-Archiv gibt es diesen Puffer ausdrücklich nicht.
• Auf Red Hat Enterprise Linux gibt es keinen abweichenden Pfad: Red Hat verweist für den Lebenszyklus von .NET auf Microsoft.
• Die entscheidende Frage richtet sich nicht an Ihre IT, sondern an Ihren Softwarelieferanten — und sie lautet nicht „ist das schlimm", sondern „auf welcher Version laufen wir, und was ist Ihr Plan".

Was am 10. November tatsächlich endet

Zunächst das Naheliegende: An diesem Tag fällt nichts aus. Eine Anwendung auf .NET 8 oder .NET 9 startet am 11. November wie am 9. November, die Masken sehen gleich aus, die Buchungen laufen durch. Ein Support-Ende ist kein Abschaltdatum.

Was endet, ist der Nachschub aus Redmond. Für diese beiden Versionen stellt Microsoft danach keine Sicherheitsupdates und keinen technischen Support mehr bereit; die Entwicklungsumgebung Visual Studio 2022 wird die betreffenden Komponenten künftig als nicht unterstützt kennzeichnen. Das Letztere betrifft zunächst denjenigen, der Ihre Software baut — es ist aber ein brauchbarer Frühindikator, denn ein Hersteller, dessen eigenes Werkzeug ihn auf eine überholte Grundlage hinweist, hat den Termin in aller Regel längst auf dem Schirm.

Wichtig ist die Art des Risikos, das damit entsteht. Es entsteht nicht am Stichtag. Ihr Server ist am 11. November exakt so sicher wie am 9. — dieselbe Software, dieselben bekannten und behobenen Lücken. Das Risiko wächst erst mit jeder Schwachstelle, die danach gefunden und in diesem Zweig nicht mehr geschlossen wird. Ein Support-Ende ist deshalb ein Planungsthema mit Vorlauf und kein Notfall — vorausgesetzt, es wird tatsächlich geplant.

Zwei Versionen, ein Datum — und die neuere steht schlechter da

Die erste Überraschung liegt in der Gleichzeitigkeit. .NET 8 ist als Langzeitversion (LTS) eingestuft, .NET 9 als Standardversion (STS) — an diesem Termin ändert das nichts: Beide erreichen ihn gemeinsam. Wer bisher davon ausging, dass eine spätere Versionsnummer automatisch länger versorgt ist, korrigiert das hier am besten gleich mit. Der nächste Langzeitzweig, .NET 10, ist bis zum 14. November 2028 versorgt und damit das Ziel, über das zu sprechen ist.

Die zweite Überraschung liegt tiefer und wird selten erzählt. Zum selben Termin gehören für die beiden Versionen gegensätzliche Ausgangslagen — und zwar nicht wegen Microsoft, sondern wegen der Frage, wie das Paket auf Ihren Server gekommen ist.

Woher stammt das .NET auf Ihrem Server?

Bei Software, die über die Paketverwaltung eines Betriebssystems verteilt wird, ist der Hersteller nicht zwangsläufig derjenige, der Ihre Updates liefert. Häufig stellt der Anbieter des Betriebssystems die Sicherheitskorrekturen selbst zusammen und liefert sie aus. Ob er das zusagt und wie lange, hängt davon ab, in welchem Archiv das Paket geführt wird. Daraus ergeben sich Fälle, die man auseinanderhalten muss.

Direkt aus Microsofts Quellen installiert

Wurde die Laufzeitumgebung direkt aus den Paketquellen von Microsoft eingerichtet — oder bringt Ihre Anwendung sie selbst mit —, gilt Microsofts Aussage unmittelbar: Für .NET 8 und .NET 9 kommt nach dem 10. November 2026 nichts mehr nach. Hier ist der Termin ein echter Handlungstermin, und hier gehört ein Wechsel jetzt in die Planung.

Aus dem Ubuntu-Hauptarchiv — der Fall von .NET 8

Läuft Ihr Server unter Ubuntu, lohnt der Blick auf ein Detail, das nach Formsache klingt und keine ist: in welchem Archiv das Paket liegt.

.NET 8 liegt in den Langzeit-Releases im Hauptarchiv — dem Bereich, für den Canonical die Sicherheitspflege einer LTS-Version zusagt. Für .NET 8 hat Canonical das zusätzlich ausdrücklich erklärt: Es werde auf Ubuntu 24.04 LTS und 22.04 LTS über den gesamten Lebenszyklus beider Releases hinweg vollständig unterstützt.

Zum Zeitrahmen: Ubuntu 22.04 LTS erhält Standard-Sicherheitspflege bis Mai 2027, mit einem Ubuntu-Pro-Abonnement bis Mai 2032. Ubuntu 24.04 LTS erhält sie bis Mai 2029, mit Ubuntu Pro bis Mai 2034. Damit liegt für diesen Fall ein Puffer vor, der deutlich über den 10. November 2026 hinausreicht. Wie weit genau er in Ihrem Fall trägt — insbesondere im verlängerten Zeitraum mit Ubuntu Pro —, ist die Angabe, die Sie sich von demjenigen bestätigen lassen sollten, der Ihren Server betreut. Dass überhaupt eine Zusage existiert, auf die man sich berufen kann, ist der entscheidende Unterschied zum nächsten Fall.

Aus dem Backports-Archiv — der Fall von .NET 9

.NET 9 wird in den Langzeit-Releases über das Backports-Archiv bereitgestellt. Für dieses Archiv benennt Canonical die Grenze der Pflege selbst: Sie ist begrenzt auf die Lebensdauer der jeweiligen .NET-Version beim Hersteller beziehungsweise auf den Supportzeitraum der betreffenden Ubuntu-Serie. Das Backports-Archiv ist dabei nicht zu verwechseln mit dem Bereich universe, den ein Ubuntu-Pro-Abonnement zusätzlich abdeckt — für Backports gilt diese Erweiterung nicht.

Das ist keine Lücke in der Auskunft, sondern eine ausgesprochene Begrenzung — und für .NET 9 fällt sie mit dem 10. November 2026 zusammen. Anders gesagt: Der Puffer, den .NET 8 über das Hauptarchiv hat, ist für .NET 9 gerade nicht zugesagt. Wer also im Vertrauen darauf, „möglichst aktuell" zu sein, auf .NET 9 gesetzt hat, steht an diesem Termin schwächer da als ein Betrieb, der bei .NET 8 geblieben ist. Eine Ausnahme zeigt die Tabelle: In Ubuntu 25.10 liegt auch .NET 9 im Hauptarchiv. Ob dieser Fall bei Ihnen vorliegt, ist eine Frage an Ihre Serverbetreuung — nicht an die Versionsnummer Ihrer Anwendung.

Auf Red Hat Enterprise Linux

Hier ist die Lage schnell erzählt, weil Red Hat sie selbst erzählt: Microsoft legt die Lebenszyklus-Richtlinie für .NET auf Red Hat Enterprise Linux fest und pflegt sie. Unterstützung, die über Installation und Laufzeitnutzung hinausgeht, kommt ebenfalls von Microsoft. Maßgeblich ist damit Microsofts Zeitplan — der 10. November 2026.

Die Fragen an Ihren Softwarelieferanten

Der praktische Wert dieses Termins liegt darin, dass Sie ihn nicht selbst auflösen müssen. Sie müssen ihn nur adressieren — beim Hersteller Ihrer Fachanwendung oder bei dem Haus, das sie für Sie betreut. Drei Fragen genügen, und sie passen in eine einzige E-Mail:

• Auf welcher .NET-Version läuft unsere Anwendung heute? Die Antwort ist eine Zahl, kein Gefühl. Ohne sie lässt sich nichts weiter beurteilen.
• Wann liefern Sie eine Fassung, die auf .NET 10 aufsetzt — und was ändert sich dadurch bei uns am Server? Diese Frage trennt Anbieter mit Fahrplan von Anbietern ohne.
• Wer liefert bis dahin die Sicherheitsupdates für die Laufzeitumgebung, und aus welcher Quelle stammt sie auf unserem System? Damit klären Sie, welcher der oben genannten Fälle bei Ihnen zutrifft.

Eine belastbare Antwort nennt eine Version, einen Zeitraum und einen Zuständigen. Eine ausweichende Antwort ist ebenfalls ein Ergebnis — dann wissen Sie, dass die Grundlage Ihrer Fachanwendung derzeit niemand aktiv verfolgt, und das lässt sich besser jetzt feststellen als in einem Jahr.

Warum der Wechsel auf .NET 10 keine Wartungsaufgabe ist

Es liegt nahe, sich das Ganze als Update vorzustellen: neue Version einspielen, fertig. So funktioniert es an dieser Stelle nicht. Der Wechsel auf einen neuen .NET-Zweig ist eine Anpassung an der Anwendung selbst, die der Hersteller vornehmen, prüfen und ausliefern muss. Danach folgt bei Ihnen der zweite Teil: die Umstellung des Servers auf die passende Grundlage, ein Test mit Ihren echten Abläufen und ein Zeitfenster, in dem ein Rückweg offensteht, falls etwas klemmt.

Wie aufwendig das im Einzelfall wird, hängt von der Anwendung ab und lässt sich nicht pauschal beziffern — von einer reinen Neuauslieferung bis hin zu einem Vorhaben mit Abstimmung, Testphase und Termin reicht die Spanne. Planbar ist es in jedem Fall, solange man den Vorlauf nicht verschenkt. Die Zeitrechnung dafür beginnt nicht am 10. November 2026, sondern in dem Moment, in dem Ihr Lieferant Ihnen sagt, wann seine .NET-10-Fassung kommt.

Einordnung

Das Support-Ende von .NET 8 und .NET 9 ist keine Nachricht, die Ihren Betrieb heute stört, und für einen Teil der Leser ist es eine vergleichsweise entspannte: Wer eine Anwendung auf .NET 8 betreibt, die aus dem Hauptarchiv einer Ubuntu-LTS-Version versorgt wird, hat eine Zusage im Rücken und Zeit zum Planen. Wer auf .NET 9 aus dem Backports-Archiv sitzt, hat diese Zeit nicht in gleicher Weise — ausgerechnet mit der neueren Version. Und wer nicht weiß, welcher Fall zutrifft, hat kein technisches Problem, sondern eine offene Frage.

Darin liegt der Wert eines solchen Termins: Er gibt einen Anlass, eine Schicht einmal bewusst anzusehen, die sonst niemand ansieht, weil sie einfach läuft. Die ehrliche Botschaft lautet nicht „Ihre Anwendung ist ab November offen", sondern: Klären Sie, auf welcher Version Sie laufen, woher sie stammt und wann Ihr Lieferant nachzieht.

Wenn Sie nicht sicher sind, welche Laufzeitumgebung hinter Ihrer Fachanwendung arbeitet und wer sie mit Sicherheitsupdates versorgt, übernehmen wir die Bestandsaufnahme. Wir klären mit Ihnen und den beteiligten Anbietern, was tatsächlich im Einsatz ist, welcher Fall zutrifft — und begleiten den Übergang so, dass Ihr Tagesgeschäft davon möglichst wenig merkt.