Aktualisiert am 7. Oktober 2026: Microsoft hat den .NET Upgrade Assistant offiziell abgekündigt und empfiehlt stattdessen den Upgrade-Agenten von GitHub Copilot in Visual Studio. Schritt 2 der Migration ist entsprechend angepasst.
Viele KMU betreiben eine zentrale Anwendung, die seit Jahren läuft: ein Auftragssystem, ein Kundenportal, ein internes Tool. Oft auf .NET Framework, oft „läuft ja noch“. Bis es nicht mehr läuft oder niemand mehr Updates machen will. Die Frage ist dann: modernisieren, neu bauen oder so lassen?
Die drei ehrlichen Optionen
- Weiterbetreiben: legitim, wenn die Anwendung stabil, abgegrenzt und ohne Sicherheits- oder Personalrisiko ist.
- Modernisieren (migrieren): schrittweise auf aktuelles .NET, ohne die Fachlogik wegzuwerfen. Meist das beste Kosten-Nutzen-Verhältnis.
- Neu bauen: nur, wenn die Altlast die Fachlogik erdrückt. Teuer und risikoreich; selten die erste Wahl.
Meine Faustregel: Im Zweifel migrieren statt neu bauen. Ein funktionierendes System enthält jahrelang gewachsenes Fachwissen. Das wirft man nicht ohne sehr guten Grund weg.
Wie es um .NET wirklich steht (Stand Mai 2026)
Etwas Faktenlage hilft bei der Einordnung:
- .NET 10 ist die aktuelle LTS-Version (erschienen im November 2025, Support bis November 2028). Das ist das sinnvolle Migrationsziel.
- .NET 8 und .NET 9 erreichen ihr Support-Ende bereits am 10. November 2026. Wer dort steht, sollte den Sprung auf .NET 10 einplanen.
- .NET Framework 4.8 / 4.8.1 hat kein fixes Support-Ende; es bleibt an die jeweilige Windows-Version gekoppelt. Es „stirbt“ also nicht, aber es bekommt keine neuen Funktionen mehr. Der Handlungsdruck entsteht hier nicht durch ein Enddatum, sondern durch Stillstand.
Woran Sie echten Handlungsdruck erkennen
- Die eingesetzte Plattform/Runtime erhält keine Sicherheitsupdates mehr
- Niemand im Umfeld kann oder will den Code noch anfassen
- Jede kleine Änderung dauert unverhältnismäßig lange
- Anbindung an moderne Dienste (Cloud, Auth, APIs) ist nicht möglich
Trifft nichts davon zu, ist „weiterbetreiben“ eine seriöse Entscheidung, kein Versäumnis.
Migration ohne Big Bang
Der Fehler ist fast immer das „große Neuschreiben“. Risikoärmer ist ein inkrementelles Vorgehen (oft „Strangler-Fig“ genannt):
- Bestand absichern: automatisierte Tests um die kritischen Abläufe legen, damit Regressionen sofort auffallen.
- Analysieren: Microsoft empfiehlt dafür inzwischen den Upgrade-Agenten von GitHub Copilot, der in Visual Studio enthalten ist; der bisherige .NET Upgrade Assistant ist offiziell abgekündigt. Der Agent analysiert Projekte und Abhängigkeiten und erstellt einen schrittweisen Migrationsplan.
- Schrittweise heben: Modul für Modul auf aktuelles .NET, nach jedem Schritt bleibt die Anwendung lauffähig und wird ausgeliefert.
- Infrastruktur erneuern, Fachlogik bewahren: Der wertvolle Teil ist die Geschäftslogik. Sie bleibt, nur das Drumherum wird modern.
So sieht ein typischer Verlauf aus: zuerst eine abgegrenzte, risikoarme Komponente migrieren (Erfahrung sammeln, Vorgehen schärfen), dann die zentralen Module, zuletzt Randbereiche. Jeder Schritt ist eigenständig nutzbar. Es gibt nie den einen großen, gefährlichen Stichtag.
Was es kostet und was Stillstand kostet
Modernisierung ist eine Investition. Die ehrliche Gegenrechnung ist nicht „Kosten vs. 0“, sondern „Kosten vs. Risiko“: Produktionsausfall, Sicherheitslücke, Abhängigkeit von einer einzigen Person, die das System noch versteht.
Fazit
Nicht jede Altanwendung muss angefasst werden, aber jede sollte bewusst bewertet werden. „Läuft noch“ ist eine Entscheidung; sie sollte nur eine informierte sein.
Sie haben so eine Anwendung und wollen eine ehrliche Einschätzung? In einem kostenlosen Erstgespräch ordne ich Ihre Situation ein, ohne Verkaufsdruck.
Hinweis: Die Beiträge dieses Blogs werden unter Einsatz von KI erstellt und vor der Veröffentlichung redaktionell geprüft. Die redaktionelle Verantwortung trägt Emre Yurtbay (siehe Impressum).