Letzte Woche saß ich bei einem Fertigungsbetrieb mit 80 Mitarbeitenden. Schönes Unternehmen, solide Margen, IT-seitig betreut von einem einzelnen Admin, der nebenbei noch die Telefonanlage am Laufen hält. Auf dem Server läuft eine Eigenentwicklung — Auftragsplanung, historisch gewachsen, .NET 8. Die Anwendung läuft stabil. Niemand hat Probleme. Niemand denkt über .NET nach.
Genau das ist das Problem.
Was Microsoft sagt
Der .NET-Blog hat es letzte Woche klar kommuniziert: .NET 8 (LTS, erschienen November 2023) und .NET 9 (STS, erschienen November 2024) verlieren beide am 10. November 2026 ihren Support. Kein Zufall, dass das zusammenfällt — Microsoft hat die STS-Laufzeit von 18 auf 24 Monate verlängert, womit beide Versionen auf denselben Stichtag landen. Danach: keine Sicherheitsupdates, keine Bugfixes, kein technischer Support. Empfehlung des Blogs ist ein Upgrade auf .NET 10, das als LTS-Release bis November 2028 läuft. Technisch ist das ein überschaubarer Eingriff — TargetFramework im Projektfile ändern, Umgebung aktualisieren, fertig. Klingt nach einem Nachmittag Arbeit.
Wie das im KMU wirklich landet
Der Microsoft-Beitrag ist technisch korrekt und gut geschrieben. Er richtet sich an Entwickler, die ihre eigene Codebasis pflegen, Zugang zu einem CI/CD-Setup haben und wissen, was ein Projektfile ist. Das ist die Realität in Konzernen und Tech-Startups.
In einem KMU mit 30 bis 300 Mitarbeitenden sieht die Ausgangslage oft anders aus:
Szenario 1: Eigenentwicklung ohne Inhouse-Entwickler. Die Anwendung wurde vor drei oder fünf Jahren von einer Agentur gebaut. Der ursprüngliche Entwickler ist weg, die Agentur macht heute was anderes, und der Source-Code liegt irgendwo auf einem Server, den keiner mehr richtig kennt. Wer soll da upgraden?
Szenario 2: ISV-Software. Du nutzt ein branchenspezifisches Tool — ERP, MES, CRM, was auch immer — das intern auf .NET 8 läuft, aber du weißt das gar nicht, weil der Hersteller das nicht kommuniziert. Ich erlebe das regelmäßig: Die IT entdeckt die .NET-Version erst dann, wenn ein Audit oder ein Penetrationstest sie auf den Tisch legt.
Szenario 3: Der Klassiker. Die Anwendung läuft auf einem Windows Server 2016, der selbst nicht mehr lang supported sein wird. Da ist das .NET-Upgrade das kleinste Problem — aber niemand schaut aufs Gesamtbild.
Was der Microsoft-Artikel nicht adressiert, weil er das nicht muss: Die Lücke zwischen "technisch möglich" und "organisatorisch umsetzbar" ist im Mittelstand oft enorm. Ein Upgrade auf .NET 10 ist kein Nachmittag, wenn man keinen Entwickler hat, der die Anwendung kennt. Es ist dann ein Beschaffungsvorgang, eine Ausschreibung, ein Budget-Gespräch mit der Geschäftsführung — und das alles unter Zeitdruck, wenn man zu lang gewartet hat.
Der andere blinde Fleck: Breaking Changes. Microsoft verlinkt sie brav in der Ressourcenliste. Wer diese Liste öffnet, sieht schnell, dass nicht jedes Upgrade ein Selbstläufer ist. Je nach Abhängigkeiten — NuGet-Pakete, Datenbankzugriff, externe APIs — kann ein .NET-8-zu-.NET-10-Sprung Anpassungen erfordern, die über das Projektfile hinausgehen. Für jemanden mit eigenem Entwicklerteam ist das handhabbar. Für jemanden, der die Agentur erst wieder anrufen muss: Einplan sechs bis acht Wochen Vorlauf, nicht zwei.
Was du konkret tun solltest
Drei Schritte, je nach Situation:
1. Bestandsaufnahme jetzt, nicht im Oktober.
Lass prüfen, welche deiner Anwendungen auf .NET 8 oder .NET 9 laufen. Das geht oft mit einem simplen dotnet --list-runtimes auf den relevanten Servern, oder dein Hersteller/deine Agentur kann dir das in fünf Minuten sagen. Wenn du diese Frage heute nicht beantworten kannst, ist das selbst schon ein Finding.
2. ISV-Software: Hersteller aktiv befragen.
Schreib deinem Softwareanbieter jetzt eine kurze Mail: "Auf welcher .NET-Version läuft eure Software aktuell, und plant ihr ein Upgrade auf .NET 10 vor November 2026?" Wenn der Hersteller keine klare Antwort liefert oder das Thema wegwischt, ist das ein Warnsignal, das nichts mit .NET zu tun hat, aber alles mit Wartbarkeit und Zuverlässigkeit.
3. Eigenentwicklung: Budget und Verantwortlichkeit klären.
Wer ist zuständig? Falls das niemand beantworten kann — nicht weil man es vergessen hat, sondern weil es keine klare Antwort gibt — dann hast du ein strukturelles Problem. Das .NET-Upgrade ist dann nicht die Lösung, sondern nur der Anlass, diese Frage endlich zu stellen.
Was ich nicht empfehle: Panik. .NET 8-Anwendungen laufen nach dem 10. November weiter. Die Welt geht nicht unter. Was aufhört, ist die Sicherheitspflege — und das ist ein Risiko, das du kalkuliert tragen oder eben mitigieren kannst. Für eine intern genutzte Planungsanwendung ohne Internetzugang ist das Risikoniveau ein anderes als für eine öffentlich erreichbare Webanwendung mit Kundendaten.
Unterscheidung macht die Priorität. Und Priorität macht daraus ein planbares Vorhaben statt eine Notfallübung im Oktober.
Der vollständige Original-Beitrag von .NET Blog (MS): .NET 8 and .NET 9 will reach End of Support on November 10, 2026
Wenn du wissen willst, wie das konkret bei euch aussieht — welche Anwendungen betroffen sind, was realistisch bis November machbar ist und wo ihr anfangen sollt — dann lass uns das in 30 Minuten durchsprechen. Kein Vortrag, kein Pitch.
— Bernhard