Migration von .NET Framework auf .NET 8: Was bei Legacy-Anwendungen gilt
Ihre Anwendung läuft auf .NET Framework 4.x. Sie tut ihren Dienst, seit Jahren. Doch die Plattform bekommt keine neuen Funktionen mehr. Microsoft pflegt sie nur noch als Bestandteil von Windows. Die .NET Framework Migration auf .NET 8 steht deshalb bei vielen Unternehmen auf der Liste. Meist weiter unten. Genau das wird mit der Zeit teuer.
Dieser Artikel zeigt, was beim Umstieg einer Legacy-Anwendung auf .NET 8 zu beachten ist. Welche Teile problemlos umziehen. Und wo die eigentliche Arbeit steckt.
Warum überhaupt migrieren?
.NET Framework 4.8.1 ist die letzte Version des klassischen Frameworks. Es wird als Teil von Windows weiter mit Sicherheits-Updates versorgt. Neue Funktionen und Performance-Verbesserungen fließen aber nur noch in das neue .NET. Details dazu stehen in unserem Artikel zur Lifecycle-Policy von .NET Framework.
Das klingt zunächst beruhigend. Die Praxis sieht anders aus. Bibliotheken und Werkzeuge unterstützen das alte Framework immer seltener. Neue Entwickler kennen es kaum noch. Wer heute mit C# einsteigt, lernt auf .NET 8 oder 10. Jede Investition in reine Framework-Anwendungen zahlt auf eine eingefrorene Plattform ein. Was das langfristig bedeutet, beschreibt unser Beitrag zum .NET Framework End of Life.
Ein Hinweis zu den Versionen. .NET 8 ist eine LTS-Version (Long Term Support, also mit verlängertem Support). Ihr Support endet im November 2026. Wer jetzt migriert, sollte .NET 10 gleich mitdenken. Der Sprung von .NET 8 auf .NET 10 ist klein. Der Sprung vom alten Framework auf die neue Plattform ist der eigentliche Kraftakt.
Was sich mit .NET 8 ändert
.NET 8 ist keine neue Version des .NET Framework. Es ist eine andere Plattform mit gemeinsamer Geschichte. Vieles blieb gleich: C#, die Basisklassen, das grundlegende Programmiermodell. Einiges wurde bewusst nicht übernommen.
AppDomains und .NET Remoting fehlen komplett. Wer Code isolieren will, nutzt heute eigene Prozesse oder AssemblyLoadContext. Für die Kommunikation zwischen Anwendungen sind gRPC oder REST-Schnittstellen der übliche Ersatz.
Schwerer wiegen zwei andere Lücken. ASP.NET WebForms, das seitenbasierte Web-Framework aus den 2000er Jahren, existiert in .NET 8 nicht. Eine WebForms-Oberfläche muss neu gebaut werden, etwa mit Blazor oder ASP.NET Core MVC. Windows Communication Foundation (WCF), der alte Standard für Dienste im Firmennetz, wurde serverseitig ebenfalls nicht portiert. Es gibt das Community-Projekt CoreWCF. Es deckt viele Szenarien ab, aber nicht alle. Auch die Workflow Foundation hat den Umzug nicht geschafft.
Was gut migriert
Die gute Nachricht zuerst. WinForms und WPF, die beiden Techniken für Windows-Oberflächen, werden in .NET 8 voll unterstützt. Eine typische Desktop-Anwendung lässt sich oft mit überschaubarem Aufwand umstellen. Sie bleibt dabei eine reine Windows-Anwendung. Für interne Tools ist das meist völlig in Ordnung.
Auch Klassenbibliotheken ziehen häufig sauber um. Gekapselte Geschäftslogik lässt sich auf .NET Standard 2.0 umstellen. Solche Bibliotheken laufen im alten Framework und in .NET 8 gleichzeitig. Das erlaubt einen schrittweisen Umbau, ohne dass alles auf einmal umzieht.
Konsolenanwendungen und Windows-Dienste sind ebenfalls dankbare Kandidaten. Sie haben selten exotische Abhängigkeiten und lassen sich gut testen.
Die typischen Hindernisse
In der Praxis scheitern Migrationen selten an C#. Sie geraten an anderen Stellen ins Stocken.
Alte NuGet-Pakete ohne .NET-8-Version sind das häufigste Problem. NuGet ist der Paketmanager für .NET, über den fremde Bibliotheken eingebunden werden. Manche dieser Bibliotheken werden seit Jahren nicht mehr gepflegt. Dann braucht es einen Ersatz. Und der verhält sich selten exakt gleich.
Direkte Windows-Abhängigkeiten sind der zweite Klassiker. Registry-Zugriffe, COM-Komponenten oder Aufrufe in System-DLLs. Vieles davon funktioniert unter .NET 8 auf Windows weiter. Geprüft und getestet werden muss es trotzdem.
Der dritte Punkt ist unangenehmer: fehlende Tests. Viele Legacy-Anwendungen haben keine automatisierten Tests. Ohne Tests fällt jede Verhaltensänderung erst im Betrieb auf. Ein Teil des Budgets sollte deshalb in ein Sicherheitsnetz aus Tests fließen. Und zwar bevor der Umbau beginnt.
Dazu kommt das Wissen über die Anwendung selbst. Oft ist der ursprüngliche Entwickler nicht mehr im Haus. Dann weiß niemand genau, warum eine Stelle so gebaut wurde. Solche Stellen brauchen beim Umbau besondere Vorsicht. Wer sie ohne Verständnis anfasst, tauscht ein bekanntes Verhalten gegen ein unbekanntes.
Was der Umstieg bringt
Der Aufwand lohnt sich an mehreren Stellen. Die neue Laufzeit ist deutlich schneller als das alte Framework. Das merkt man besonders bei Web-Anwendungen und Datenverarbeitung. Anwendungen lassen sich in Containern betreiben und auf Linux-Servern hosten. Das senkt Lizenzkosten und öffnet moderne Betriebsmodelle. Aktuelle C#-Versionen machen den Code kürzer und lesbarer.
Für die Personalsuche zählt ein weiterer Punkt. Entwickler arbeiten lieber auf einer lebendigen Plattform. Eine Anwendung auf .NET 8 findet leichter Betreuer als eine auf .NET Framework 4.5.
Ein realistischer Fahrplan
Die .NET Framework Migration beginnt nicht mit Code, sondern mit einer Bestandsaufnahme. Der .NET Upgrade Assistant von Microsoft analysiert Projekte und listet Inkompatibilitäten auf. Das Ergebnis zeigt, wo die Baustellen liegen und wie groß sie sind.
Danach fällt die Grundsatzentscheidung. Lohnt sich die Übernahme des bestehenden Codes? Oder ist eine Neuentwicklung einzelner Teile ehrlicher? Die Kriterien dafür haben wir im Artikel Refactoring vs. Rewrite beschrieben.
Für größere Systeme hat sich ein schrittweises Vorgehen bewährt. Neue Funktionen entstehen in .NET 8, die Altanwendung schrumpft nach und nach. Dieses Muster heißt Strangler Fig. Wie es funktioniert, zeigt unser Beitrag zum Strangler-Fig-Pattern.
Ein Zwischenschritt hilft fast immer. Stellen Sie zuerst alle Projekte auf das neue SDK-Projektformat um. Aktualisieren Sie die Abhängigkeiten, noch unter .NET Framework. Erst dann wechselt das Zielframework. So bleibt die Anwendung während des Umbaus jederzeit lauffähig.
Der Umbau im laufenden Betrieb
Eine Unternehmensanwendung kann selten monatelang stillstehen. Der Umbau muss neben dem Tagesgeschäft laufen. Dafür haben sich einige Regeln bewährt.
Frieren Sie große neue Funktionen während der heißen Phase ein. Jede parallele Änderung am alten Code macht den Umstieg schwerer. Kleine Fehlerkorrekturen bleiben natürlich möglich.
Betreiben Sie alte und neue Version eine Zeit lang parallel. Ein Teil der Nutzer arbeitet mit der migrierten Anwendung, der Rest bleibt auf dem alten Stand. Auffälligkeiten zeigen sich so früh und mit begrenztem Schaden.
Messen Sie das Verhalten beider Versionen. Antwortzeiten, Fehlerraten, Speicherverbrauch. Die neue Plattform ist meist schneller. Einzelne Stellen können sich trotzdem anders verhalten, etwa bei Kultur- und Datumsformaten. Solche Abweichungen fallen im Vergleich sofort auf, im Blindflug erst beim Kunden.
Planen Sie einen Rückweg ein. Wenn die migrierte Version ein Problem hat, muss die alte kurzfristig wieder übernehmen können. Das nimmt dem Projekt viel Druck.
Was kostet das?
Pauschale Zahlen wären unseriös. Eine WinForms-Anwendung mit sauberer Struktur migriert ein erfahrenes Team in Wochen. Eine WebForms-Anwendung mit WCF-Diensten und zehn Jahren gewachsener Logik ist ein Projekt über Monate. Was sich über die Jahre angesammelt hat, bestimmt den Aufwand. Die Bestandsaufnahme liefert die Grundlage für eine ehrliche Schätzung. Genau deshalb steht sie am Anfang.
Fazit: Der Umstieg ist Arbeit, aber planbar
Die Migration von .NET Framework auf .NET 8 macht Arbeit. Die Hindernisse sind aber bekannt und gut dokumentiert. Wer mit einer Bestandsaufnahme startet, schrittweise umbaut und Tests aufbaut, behält Aufwand und Risiko im Griff.
Ihre Anwendung läuft noch auf .NET Framework 4.x? Wir schauen uns Ihr System an. Danach wissen Sie, was eine Migration konkret bedeuten würde. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
