Legacy .NET Migration: Von .NET Framework zu .NET 8 – Schritt für Schritt

Irgendwo in den meisten mittelständischen und großen Unternehmen läuft noch eine .NET Framework-Anwendung. Manchmal sind es drei. Manchmal zwanzig. Und irgendwann steht die Frage im Raum: Müssen wir das anfassen?

Die kurze Antwort: Ja. Die etwas längere Antwort steht in diesem Artikel.

Warum jetzt migrieren?

Support-Ende und Sicherheitsrisiken

Microsoft hat .NET Framework nicht abgekündigt – es wird weiterhin als Teil von Windows ausgeliefert und bekommt Security-Patches. Das klingt beruhigend, ist es aber nur auf den ersten Blick. Neue Features, Performance-Verbesserungen und moderne APIs gibt es ausschließlich im modernen .NET. Wer auf Framework bleibt, arbeitet mit einer Plattform, die funktional eingefroren ist.

Das bedeutet konkret: Abhängige Bibliotheken von Drittanbietern migrieren zu .NET 8+. Wer hinterherhinkt, fängt irgendwann an, Library-Versionen einzufrieren, um Kompatibilität zu erhalten – und häuft damit technische Schulden an, die exponentiell wachsen.

Performance-Vorteile, die sich rechnen lassen

.NET 8 ist dramatisch schneller als .NET Framework 4.x. Konkrete Zahlen aus Benchmarks:

• ASP.NET Core: bis zu 800 % mehr Requests pro Sekunde gegenüber ASP.NET auf Framework
• JSON-Serialisierung mit System.Text.Json: deutlich schneller als Newtonsoft.Json auf Framework
• Garbage Collector: erheblich verbesserter Durchsatz, reduzierte Pausenzeiten

Was das in der Praxis bedeutet: weniger Server, niedrigere Cloud-Kosten, bessere Antwortzeiten. Bei einer mittelgroßen Web-Applikation mit vier App-Servern lassen sich nach der Migration regelmäßig zwei davon abschalten.

Containerisierung und Cloud-Native

.NET Framework läuft nur auf Windows. Das schließt Linux-Container, Kubernetes und viele moderne Cloud-Dienste faktisch aus – oder macht sie teuer. .NET 8 läuft auf Linux, ist containerisierbar und öffnet damit das gesamte Cloud-Native-Ökosystem.

Assessment-Phase: Was haben wir überhaupt?

Vor jeder Migrationsentscheidung steht eine ehrliche Bestandsaufnahme. Ich empfehle hier zwei bis vier Wochen Zeit zu investieren, bevor irgendein Code angefasst wird.

Dependency-Analyse

Das .NET Upgrade Assistant-Tool von Microsoft liefert einen ersten guten Überblick. Es scannt die Solution und listet auf, welche Pakete und APIs nicht direkt kompatibel mit .NET 8 sind.

Wichtiger als das Tool ist jedoch die manuelle Bewertung:

• Welche NuGet-Pakete werden verwendet? Haben alle eine .NET 8-kompatible Version? Einige ältere Pakete wurden schlicht aufgegeben.
• Gibt es COM-Interop? Das ist auf Linux nicht verfügbar – ein potenzieller Showstopper.
• Werden Windows-Registry-Zugriffe gemacht? Diese sind plattformspezifisch.
• Gibt es native DLLs oder P/Invoke-Aufrufe? Müssen separat bewertet werden.

Kritische Technologien identifizieren

Einige Technologien aus dem .NET-Framework-Ökosystem haben keine direkte Entsprechung in .NET 8:

| Technologie | Status in .NET 8 | Alternative | |---|---|---| | WCF (Server) | Nicht verfügbar | CoreWCF, gRPC, REST | | Web Forms | Nicht verfügbar | Blazor, Razor Pages | | Remoting | Nicht verfügbar | gRPC, SignalR | | System.Web | Nicht verfügbar | ASP.NET Core Middleware | | System.Drawing (GDI+) | Nur Windows | SkiaSharp, ImageSharp |

Jede dieser Technologien im Einsatz bedeutet signifikanten Migrationsaufwand. Frühzeitig identifizieren heißt realistisch planen.

Zeitrahmen und Aufwände: Was die Praxis zeigt

Aus Projekten, die ich begleitet habe, ergeben sich grobe Richtwerte:

• Kleine Web-Applikation (< 50k LOC, keine WCF, keine Web Forms): 2–4 Monate
• Mittelgroße Anwendung (50–200k LOC, einige problematische Dependencies): 6–12 Monate
• Große Enterprise-Anwendung (> 200k LOC, WCF, komplexe Deployment-Topologie): 12–24 Monate, oft als mehrstufiges Programm

Diese Zahlen gelten für professionell geführte Projekte mit vollständiger Test-Coverage. Ohne Tests: Faktoren von 1,5 bis 2 einkalkulieren.

Migrationsstrategie wählen

Es gibt drei grundsätzliche Ansätze. Die Wahl hängt von Codebasis-Größe, Business-Kritikalität und verfügbarer Kapazität ab.

Strategie 1: Big Bang Rewrite

Die gesamte Anwendung wird auf einmal neu geschrieben. Risikoreich, selten empfehlenswert – aber manchmal die richtige Entscheidung.

Geeignet wenn:

• Die Codebasis ist klein (< 30k LOC)
• Die fachliche Logik ist gut verstanden und gut dokumentiert
• Die Anwendung läuft in einem isolierten Kontext ohne viele externe Abhängigkeiten
• Das Team hat freie Kapazität für eine dedizierte Neuentwicklung

Risiken: Risiko des zweiten Systems, Scope Creep, lange Phase ohne Feedback.

Strategie 2: Strangler Fig Pattern

Neue Features werden in .NET 8 entwickelt. Bestehende Komponenten werden schrittweise migriert, bis die alte Plattform überflüssig ist. Ein Reverse Proxy (YARP oder Nginx) leitet Traffic an die jeweils zuständige Komponente weiter.

Das ist meine bevorzugte Strategie für die meisten mittelgroßen Anwendungen. Sie erlaubt kontinuierlichen Betrieb, liefert früh messbare Ergebnisse und macht den Fortschritt sichtbar.

Geeignet wenn:

• Die Anwendung hat eine klare Service- oder Domain-Struktur
• Echter Produktionsbetrieb muss aufrechterhalten werden
• Das Team kann parallel Feature-Entwicklung und Migration leisten

Strategie 3: Side-by-Side Migration

Beide Versionen laufen parallel auf derselben Datenbasis. Traffic wird schrittweise von Framework auf .NET 8 umgeleitet, mit Rollback-Möglichkeit.

Geeignet wenn:

• Sehr hohe Anforderungen an Verfügbarkeit
• Das Risiko eines Rollbacks eingeplant werden muss
• Die Anwendung stateless oder gut horizontal skalierbar ist

Schritt-für-Schritt: Die Migrationsphasen

Phase 1: Vorbereitung (4–8 Wochen)

1. Test-Coverage herstellen: Keine Migration ohne Regressionstests. Mindestens die kritischen Pfade müssen abgesichert sein.
2. Shared Libraries zuerst: Class Libraries ohne Framework-Abhängigkeiten auf netstandard2.0 oder direkt auf net8.0 migrieren.
3. NuGet-Pakete aktualisieren: Auf aktuelle Versionen aktualisieren, die .NET 8 unterstützen.
4. Toolchain aufsetzen: CI/CD-Pipeline für .NET 8 vorbereiten, Build-Skripte anpassen.

Phase 2: Kernmigration

5. ASP.NET Core einführen: Neues Projekt anlegen, Middleware-Pipeline aufbauen, Authentication neu aufsetzen.
6. Datenzugriffsschicht migrieren: Hier lauern die meisten Überraschungen – dazu mehr im nächsten Abschnitt.
7. Business-Logik übertragen: In der Regel am unkompliziertesten, wenn sie sauber von UI und Datenzugriff getrennt ist.
8. WCF-Services ablösen: CoreWCF für kurzfristige Kompatibilität, mittelfristig auf REST oder gRPC migrieren.

Phase 3: Qualitätssicherung und Deployment

9. Performance-Benchmarks: Vorher/Nachher-Vergleich für kritische Endpunkte.
10. Containerisierung: Docker-Image bauen, Kubernetes-Deployment testen.
11. Produktions-Rollout: Canary-Deployment oder Blue-Green-Switchover.
12. Framework-Code abschalten: Erst wenn die neue Version stabil läuft.

Entity Framework Core: Der häufigste Stolperstein

Wer von Entity Framework 6 auf Entity Framework Core migriert, erlebt oft seine erste große Überraschung. EF Core ist kein direkter Nachfolger von EF6 – es ist eine komplette Neuentwicklung mit anderen Konventionen.

Was sich ändert:

• Lazy Loading ist in EF Core nicht standardmäßig aktiv. Eager Loading mit .Include() muss explizit gemacht werden.
• Komplexe Typen und Table Splitting funktionieren anders.
• ObjectContext existiert nicht mehr – es gibt nur noch DbContext.
• Stored Procedure-Mapping hat eine neue Syntax.
• Migrations müssen neu erstellt werden; alte EF6-Migrations sind nicht kompatibel.

Empfehlung: Den Datenzugriffsschicht-Teil der Migration als eigenständiges Teilprojekt behandeln, mit eigener Testphase und eigenen Abnahmekriterien.

Containerisierung nach der Migration

Sobald die Anwendung auf .NET 8 läuft, ist der nächste logische Schritt die Containerisierung. Ein typisches Dockerfile für eine ASP.NET Core-Anwendung:

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApp/MyApp.csproj", "MyApp/"]
RUN dotnet restore "MyApp/MyApp.csproj"
COPY . .
WORKDIR "/src/MyApp"
RUN dotnet build -c Release -o /app/build

FROM build AS publish
RUN dotnet publish -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Wichtige Hinweise für Containerisierung:

• Konfiguration über Umgebungsvariablen, nicht über web.config
• Health Checks implementieren (ASP.NET Core Health Checks sind eingebaut)
• Secrets über Kubernetes Secrets oder Azure Key Vault – nie im Image
• Non-root-User im Container aus Sicherheitsgründen

Performance-Verbesserungen messen

Nach der Migration sollten konkrete Verbesserungen messbar sein. Was ich in Projekten routinemäßig messe:

• Startup-Zeit: .NET 8 startet signifikant schneller, relevant für Container-Restarts
• Throughput: Requests pro Sekunde unter Last (k6, Apache JMeter)
• P95/P99 Latenz: Nicht nur Durchschnittswerte betrachten
• Memory-Footprint: .NET 8 ist in der Regel deutlich sparsamer
• CPU-Auslastung: Oft 20–40 % geringer nach Migration

Diese Zahlen gehören in einen Migrations-Abschlussbericht und dienen als Business Case für zukünftige Modernisierungsinvestitionen.

Fazit: Migration ist eine Investition, kein Projekt

Die Migration von .NET Framework zu .NET 8 ist aufwendig. Es gibt keine Abkürzung, die den Assessment- und Planungsaufwand ersetzt. Aber die Alternative – auf einer eingefrorenen Plattform zu bleiben, während Abhängigkeiten veralten und Betriebskosten steigen – ist mittel- bis langfristig teurer.

Der wichtigste Rat aus der Praxis: Fang klein an. Wähle eine nicht-kritische Komponente, migriere sie vollständig, messe das Ergebnis – und baue von dort aus Zuversicht und Expertise auf, bevor du die kritischen Systeme anfasst.

Ich begleite Unternehmen durch genau diesen Prozess: von der ehrlichen Bestandsaufnahme bis zum laufenden Container in Kubernetes. Wenn du vor einer ähnlichen Herausforderung stehst, lass uns das strukturiert angehen.