Eine Migrationsstrategie für produktive Enterprise-Systeme
Das Ausgangsprojekt umfasste rund 150 Projekte, mehrere Backend-Anwendungen, gemeinsame Bibliotheken, Konsolen-Tools und ein aktiv genutztes Produkt. In so einer Situation schafft ein Big-Bang-Rewrite zu viel fachliches und technisches Risiko.
Die praktische Antwort ist eine Folge klar abgegrenzter Tickets: zuerst Build- und Projektstruktur modernisieren, gemeinsame Bibliotheken auf ein Kompatibilitätsziel bringen und erst danach Anwendungen und Hosting schrittweise migrieren.
.NET Standard 2.0 ist die Brücke, nicht das Ziel
Damit können sowohl .NET Framework 4.8 als auch .NET 6 dieselbe Bibliothek während der Übergangsphase verwenden. Genau diese Kompatibilität macht eine iterative Migration realistisch. Sobald die gesamte Lösung modernisiert ist, sollten auch diese Bibliotheken auf .NET 6 wechseln.
Projekte
Eine grosse Lösung mit mehreren Anwendungstypen und vielen Abhängigkeiten.
Big-Bang-Rewrites
Die Lieferung bleibt in Bewegung, wenn die Migration in unabhängige Schritte zerlegt wird.
Brückenziel
Gemeinsamer Code kann während des Rollouts sowohl die alte als auch die moderne Runtime bedienen.
Was .NET Framework, .NET und .NET Standard tatsächlich bedeuten
Wenn diese drei Begriffe sauber verstanden sind, wird der restliche Migrationsplan deutlich einfacher.
.NET Framework 4.8
Die klassische, nur unter Windows laufende Runtime. Sie wird noch unterstützt, ist aber nicht die zukunftsorientierte, plattformübergreifende Basis für neue Entwicklung.
.NET 6
Die moderne, plattformübergreifende Runtime, die den Weg von .NET Core fortsetzt. In diese Richtung gehen neue Workloads und die langfristige Weiterentwicklung.
.NET Standard
Keine Runtime, sondern ein API-Vertrag. Wenn beide Seiten diesen Vertrag implementieren, kann dieselbe Bibliothek sowohl unter .NET Framework 4.8 als auch unter .NET 6 verwendet werden.
interface ITask
{
void Execute();
}
class NetFramework48 : ITask
{
}
class Net6 : ITask
{
}Mit .NET Standard 2.0 die Kopplung während der Migration reduzieren
Microsoft unterstützt .NET Standard 2.0 weiterhin, und sowohl .NET Framework 4.8 als auch .NET 6 implementieren es. Deshalb eignet es sich hervorragend für gemeinsame Bibliotheken in der Übergangsphase. Die wichtige Nuance: Behandle es als temporäre Kompatibilitätsschicht, nicht als Endzustand der Architektur.
Ein pragmatischer, phasenweiser Migrationspfad
Die Reihenfolge der Arbeit sollte neue Optionen schaffen, statt alte Annahmen tiefer in die Codebasis einzubetten.
Mit den Grundlagen beginnen
Projekte auf SDK-Style-csproj umstellen, packages.config ablösen und NuGet-Kompatibilität früh prüfen. Werkzeuge wie der Upgrade Assistant nehmen viel manuelle Arbeit ab.
Isolierte Konsolenanwendungen zuerst migrieren
Eigenständige Executables mit wenigen Abhängigkeiten lassen sich oft direkt von net48 auf net6.0 umstellen. Sie schaffen frühes Vertrauen und schnelle Fortschritte.
Gemeinsame Bibliotheken auf .NET Standard 2.0 bringen
Das ist der entscheidende Brückenschritt. Gemeinsamer Code kann damit gleichzeitig von .NET Framework 4.8- und .NET 6-Anwendungen genutzt werden, während die Lösung noch gemischt ist.
Runtime-spezifische Abhängigkeiten entkoppeln
Bevor die grösseren Anwendungen migriert werden, sollten Framework-spezifische Annahmen aus gemeinsamem Code entfernt werden. Dinge wie HttpContext.Current gehören hinter Abstraktionen, die die gemischte Übergangsphase überstehen.
Tests, Web APIs und Services migrieren
Sobald der gemeinsame Code bereit ist, wechseln Unit Tests auf eine echte Runtime, Web APIs auf ASP.NET Core und ältere Windows-Service-Ansätze wie TopShelf werden ersetzt.
Zum Schluss Brückenbibliotheken auf .NET 6 heben
Wenn die Lösung vollständig auf modernen Runtimes läuft, kann netstandard2.0 entfernt, auf net6.0 umgestellt und die Architektur aus einer stabilen Ausgangslage weiter modernisiert werden.
Diese Teile verdienen explizite Planung
Das TargetFramework zu ändern ist die einfache Diff-Zeile. Der eigentliche Aufwand steckt meist in Runtime-Grenzen, Hosting-Annahmen und älterer Infrastruktur.
HttpContext.Current fällt weg
Alte gemeinsame Bibliotheken hängen oft an HttpContext.Current. In einer iterativen Migration sollte dieser Zugriff durch Abstraktionen wie IHttpContextAccessor ersetzt werden, damit beide Welten während des Übergangs unterstützt werden können.
ASP.NET Web API bewegt sich anders
Global.asax, WebApiConfig und Request-Lifecycle-Hooks lassen sich nicht eins zu eins übernehmen. Ein sauberes ASP.NET Core-Projekt mit expliziter Program.cs- und Middleware-Migration ist meist der sicherere Weg.
TopShelf braucht ein neues Hosting-Modell
Wenn Windows Services auf TopShelf basieren, sollte der Wechsel zu BackgroundService und dem modernen Hosting-Modell eingeplant werden. Das ist mehr als nur eine Änderung des TargetFrameworks.
SignalR kann Frontend-Arbeit auslösen
Die alten und neuen SignalR-Stacks sind nicht austauschbar. Eine Backend-Migration kann koordinierte Frontend-Änderungen nach sich ziehen, daher diese Abhängigkeit früh sichtbar machen.
JSON-Defaults können Verhalten ändern
ASP.NET Core verwendet standardmässig System.Text.Json, während ältere Anwendungen oft auf Newtonsoft.Json-Einstellungen aufbauen. Wenn Serialisierungsverhalten relevant ist, sollte diese Umstellung bewusst erfolgen und nicht nebenbei.
IIS, Authentifizierung und Model Binding sind strenger
Modernes .NET auf IIS braucht oft das Hosting Bundle, explizite Negotiate- oder IIS-Authentifizierung und mehr Aufmerksamkeit für Payload-Formate, weil Model Binding und Serialisierung weniger tolerant sind als im alten Framework.
Die Migration fokussiert halten
Zuerst die Plattformmigration sicher abschliessen. Danach können Dependency Injection, Serializer, Architektur oder Hosting aus einer stabilen Ausgangslage heraus modernisiert werden, ohne alles in denselben Schritt zu packen.
Lassen Sie uns über Ihr Vorhaben sprechen
Lassen Sie uns gemeinsam etwas Grossartiges aufbauen
Haben Sie eine Frage oder möchten Sie ein Projekt besprechen? Wir freuen uns, von Ihnen zu hören. Füllen Sie das untenstehende Formular aus und wir melden uns so schnell wie möglich bei Ihnen.
Sie können uns auch direkt erreichen unter [email protected]