CH
PL
Was das Supportende praktisch bedeutet
Eine Anwendung hört am 10. November nicht auf zu funktionieren. Sie läuft weiter, wird aber nicht mehr mit Sicherheitsupdates versorgt. Neu entdeckte Schwachstellen in der Laufzeitumgebung oder in Framework-Bibliotheken bleiben offen. Das ist vor allem bei Anwendungen kritisch, die aus dem Internet erreichbar sind, personenbezogene Daten verarbeiten oder an zentrale Systeme angebunden sind.
Hinzu kommen regulatorische Aspekte. Wer unter das NISG 2026 fällt oder nach ISO/IEC 27001 arbeitet, muss nachweisen, wie mit Schwachstellen und veralteter Software umgegangen wird. Nicht mehr unterstützte Laufzeitumgebungen fallen in Audits schnell auf.
Schritt 1: Bestand erfassen
Der erste Schritt ist eine vollständige Übersicht. In vielen Unternehmen ist nicht auf Anhieb klar, welche Anwendungen auf welcher .NET-Version laufen. Eine Bestandsaufnahme sollte mindestens folgende Punkte enthalten:
- Name und Zweck der Anwendung sowie verantwortliche Person oder Team
- Zielframework im Projekt und tatsächlich installierte Laufzeit auf den Servern
- Betriebsumgebung: On-Premises, Container, Cloud-Dienst
- Erreichbarkeit: intern, extern, über Schnittstellen angebunden
- Kritikalität für den Geschäftsbetrieb
Hilfreich ist es, nicht nur Quellcode-Repositories zu durchsuchen, sondern auch Server, Container-Images und Build-Pipelines. Gerade ältere Dienste laufen manchmal auf Maschinen, die niemand mehr aktiv betreut.
Schritt 2: Abhängigkeiten prüfen
Die Umstellung des Zielframeworks ist oft der kleinere Teil der Arbeit. Aufwand entsteht durch Abhängigkeiten: NuGet-Pakete, die noch nicht für .NET 10 aktualisiert wurden, interne Bibliotheken, die mehrere Anwendungen gemeinsam nutzen, oder Drittanbieter-Komponenten mit eigenen Freigabezyklen.
Für jede Anwendung lohnt sich eine kurze Einschätzung: Ist der Wechsel weitgehend technisch, also Zielframework anpassen, Pakete aktualisieren, testen? Oder sind Breaking Changes, veraltete APIs oder größere Anpassungen zu erwarten? Microsoft dokumentiert die Änderungen zwischen den Versionen ausführlich, und Werkzeuge wie der .NET Upgrade Assistant unterstützen bei der Analyse.
Schritt 3: Reihenfolge festlegen
Nicht alle Anwendungen müssen gleichzeitig umgestellt werden. Eine sinnvolle Priorisierung berücksichtigt zwei Dimensionen: Risiko und Aufwand.
- Hohe Kritikalität, geringer Aufwand: zuerst umstellen. Diese Anwendungen bringen schnell Sicherheit.
- Hohe Kritikalität, hoher Aufwand: früh planen, Ressourcen reservieren, gegebenenfalls Übergangsmaßnahmen definieren.
- Geringe Kritikalität, geringer Aufwand: gebündelt in einem Sprint umstellen.
- Geringe Kritikalität, hoher Aufwand: prüfen, ob die Anwendung noch gebraucht wird oder abgelöst werden kann.
Gerade der letzte Punkt wird oft unterschätzt. Eine Migration ist eine gute Gelegenheit, Altlasten zu bereinigen.
Schritt 4: Testen und ausrollen
Eine Migration ist erst abgeschlossen, wenn die Anwendung im Betrieb zuverlässig läuft. Dazu gehören automatisierte Tests, ein Testlauf in einer produktionsnahen Umgebung und ein Plan für den Rollback. Besonders wichtig sind Lasttests bei Anwendungen mit hohem Datenvolumen sowie Tests aller Schnittstellen zu Partnersystemen.
Vergesst auch die Build- und Deployment-Pipelines nicht. SDK-Versionen, Container-Basisimages und Hosting-Konfigurationen müssen ebenfalls aktualisiert werden.
Schritt 5: Zuständigkeiten klären
Die häufigste Ursache für verzögerte Migrationen ist nicht die Technik, sondern fehlende Zuständigkeit. Wer entscheidet über die Reihenfolge? Wer stellt Entwicklerkapazität bereit? Wer verantwortet Tests und Abnahme im Fachbereich?
Ein einfacher Migrationsplan mit Verantwortlichen, Meilensteinen und Abhängigkeiten schafft Klarheit. Er sollte von IT-Leitung, Entwicklung und Betrieb gemeinsam getragen werden.
Typische Stolpersteine bei .NET-Migrationen
Aus Migrationsprojekten kennen wir einige Muster, die immer wieder Zeit kosten:
- Vergessene Dienste: Ein Windows-Dienst oder ein geplanter Task, der seit Jahren unauffällig läuft, taucht erst auf, wenn der Server aktualisiert wird.
- Gemeinsame Bibliotheken: Eine interne Bibliothek wird von zehn Anwendungen genutzt. Wird sie umgestellt, müssen alle zehn mitziehen, oder es braucht eine Übergangsversion für mehrere Zielframeworks.
- Fehlende Tests: Ohne automatisierte Tests wird jede Änderung zum manuellen Kraftakt. Oft lohnt es sich, vor der eigentlichen Migration grundlegende Tests aufzubauen.
- Unklare Konfiguration: Einstellungen, Zertifikate und Verbindungszeichenfolgen sind nicht dokumentiert und müssen erst rekonstruiert werden.
- Wissen in einzelnen Köpfen: Die Person, die eine Anwendung gebaut hat, ist nicht mehr im Unternehmen.
Wer diese Punkte in der Bestandsaufnahme gezielt abfragt, kann Aufwand und Risiken deutlich realistischer einschätzen.
Was die Geschäftsführung wissen sollte
Für die Geschäftsführung ist eine .NET-Migration selten ein Thema, bis ein Audit oder ein Sicherheitsvorfall sie sichtbar macht. Dabei lassen sich die Kernpunkte in wenigen Sätzen zusammenfassen: Wie viele Anwendungen sind betroffen? Welche davon sind geschäftskritisch? Bis wann ist welcher Teil umgestellt? Welche Kapazität und welches Budget braucht es dafür? Und wie wird das Risiko für Anwendungen bewertet, die vorübergehend weiterlaufen?
Eine kurze, regelmäßige Statusmeldung in diesem Format schafft Vertrauen und erleichtert Entscheidungen über zusätzliche Ressourcen.
Was tun, wenn die Zeit nicht reicht?
Viele Teams werden den 10. November nicht für alle Anwendungen einhalten können. Das ist realistisch, sollte aber eine bewusste Entscheidung sein. Für Anwendungen, die vorübergehend auf .NET 8 oder 9 weiterlaufen, braucht es eine dokumentierte Risikobewertung und zusätzliche Schutzmaßnahmen, zum Beispiel eingeschränkte Erreichbarkeit, verstärktes Monitoring oder eine Web Application Firewall. Am Markt gibt es außerdem Anbieter von kommerziellem Extended Support. Ob das sinnvoll ist, hängt von Umfang, Budget und Zeithorizont ab.
Wichtig ist: Übergangslösungen sind Brücken, keine Ziele. Sie brauchen ein Enddatum.
Kapazität ist der eigentliche Engpass.
In Gesprächen mit IT-Leitungen hören wir selten, dass Wissen fehlt. Was fehlt, ist Zeit. Die Entwicklerteams sind mit Weiterentwicklung, Betrieb und Fehlerbehebung ausgelastet. Eine Migration läuft „nebenbei“ und wird immer wieder verschoben.
Zusätzliche .NET-Entwickler:innen auf Zeit können diese Lücke schließen. Sie übernehmen klar abgegrenzte Pakete, etwa die Migration einer Gruppe von Diensten oder den Aufbau automatisierter Tests, während das interne Team den laufenden Betrieb sichert. Wichtig ist eine saubere Übergabe, damit das Wissen nach dem Projekt im Unternehmen bleibt.
Häufige Fragen
Läuft meine Anwendung nach dem 10. November weiter?
Ja. Die Anwendung funktioniert technisch weiter, erhält aber keine Sicherheitsupdates mehr. Neue Schwachstellen bleiben offen, was das Risiko mit jedem Monat erhöht.
Sollten wir auf .NET 10 oder auf eine spätere Version wechseln?
Für die meisten Unternehmensanwendungen ist .NET 10 als Long-Term-Support-Version der naheliegende Schritt, weil sie bis November 2028 unterstützt wird. Wer regelmäßig aktualisieren kann, plant den nächsten Wechsel gleich mit ein.
Fazit
Das Supportende von .NET 8 und 9 ist planbar. Wer jetzt den Bestand erfasst, Abhängigkeiten prüft, eine Reihenfolge festlegt und Zuständigkeiten klärt, macht aus einer Pflichtaufgabe ein überschaubares Projekt. Und wer Kapazität realistisch einschätzt, vermeidet, dass die Migration im Tagesgeschäft untergeht.
Bei Suppliance unterstützen wir Unternehmen mit erfahrenen .NET-Spezialist:innen für Migrations- und Modernisierungsprojekte. Sprecht mit uns über euren Bedarf.