Konzeption einer .NET Core/.NET 5 Migration

Im November 2020 veröffentlichte Microsoft die Plattformimplementierung .NET 5. Diese baut auf .NET Core 3.1 auf und bietet somit viele Vorteile wie zum Beispiel Performanceoptimierungen, oder auch Cross-Plattform-Unterstützung. Das Überspringen der Versionsnummer 4 erfolgte aufgrund der Verwechselbarkeit mit .NET Framework 4. Zusätzlich entfiel der Namensanteil “Core”. Dies begründet Microsoft darin, dass .NET 5 eine Vereinheitlich der Plattformimplementierungen .NET Framework, .NET Standard und Mono darstellt, und deren Weiterentwicklung gestoppt wurde.

Für Systeme, die unter einer der veralteten Plattformimplementierungen betrieben werden, sollten bereits heute eine Migration in Richtung .NET 5 in Betracht gezogen werden. Besonders zu beachten sind hierbei die von Microsoft angegebenen Zeiten für den jeweiligen Long-Term-Support. Wie in der nachfolgenden Grafik dargestellt ist, hat .NET Core 3.1 bereits heute einen längeren Long-Term-Support als das neue .NET 5. Es kann somit mehr Sinn machen, vorerst eine Migration auf .NET Core 3.1 durchzuführen und im Februar 2022, mit dem geplanten Release von .NET 6, ein Upgrade durchzuführen.

Abbildung 1: Microsoft Long Term Support

Im Nachfolgenden werden die wichtigsten zu klärenden Aspekten aufgezeigt, die für eine Migration berücksichtigt werden müssen. Dazu werden die folgenden Prozessschritte betrachtet:

Abbildung 2: Prozessschritte Migrationskonzeption

Kernfragen klären

Bereits zu Beginn der Konzeption sollte festgehalten werden, welche Gründe für die Migration identifiziert wurden und welche Ziele erreicht werden sollen. So könnten Hintergründe einer Migration beispielsweise Performance- oder Kompatibilitätsprobleme sein. Diese Probleme könnten etwa durch das Ausnutzen von Performanceoptimierungen oder durch die Nutzung von Cross-Plattform-Funktionalitäten gelöst werden.

Zudem sollten unbedingt die Rahmenbedingungen geklärt werden. Gibt es organisatorischen Vorgaben, wie etwa ein zeitlicher Rahmen oder die Gewährleistung des ununterbrochenen Tagesgeschäfts? Anhand dieser Informationen kann schon jetzt eine grobe Strategie abgeleitet werden. Sofern die Weiterentwicklung der Systeme pausiert und die komplette Migration in einem Zug durchgeführt werden soll, empfiehlt sich eine „Big Bang“-Migration. Oder soll der Geschäftsbetrieb sowie die kontinuierliche Weiterentwicklung der Systeme aufrechterhalten und andere Geschäftsbereich nicht beeinträchtigt werden? Dann sollte eine „Step by Step“-Migration angegangen werden und mit jedem Schritt ein abgeschlossener und vollfunktionsfähiger Zustand der Systeme gewährleisten werden.

Migrationseinheiten identifizieren

In den meisten Fällen werden keine Monolithen migriert, sondern ein Konglomerat mit zahlreichen Abhängigkeiten untereinander. Um einen Überblick zu bekommen, wie die Migration ablaufen soll und wie aufwändig sie sein wird, muss jede Einheit festgehalten werden, die eine Abhängigkeit zu den migrierenden Systemen hat. Auch wenn diese Einheiten selbst keine Migration erfordern, ist es gut zu wissen, dass Abhängigkeiten bestehen und dadurch neue Aufgaben abgeleitet werden können. Zudem ist eine Übersicht dieser Einheiten sinnvoll, damit einzelne Einheiten von der Migration explizit ausgeschlossen werden können und sichergestellt wird, dass nichts übersehen wurde.

Beispiele für einzelne Einheiten, welche im Rahmen der Vorbereitung einer Migration identifiziert werden können, sind unter anderem:

• Quellcodeprojekte
• Anwendungsserver
• Schnittstellen
• Abhängigkeiten zu Drittanbietern
• etc.

Anhand der nun identifizierten Einheiten können neue Aufgaben erkannt werden, welche zuvor unentdeckt blieben. Häufig wird etwa übersehen, dass auf dem Anwendungsserver eine passende Runtime installiert werden muss oder genutzte Authentifizierungsmechnismen nicht mehr unterstützt werden.

Migrationseinheiten analysieren

Nachdem nun alle von der Migration betroffenen Einheiten identifiziert sind, können diese genauer betrachtet werden. Anhand der Vielzahl an Einheiten und deren Umfang ist ersichtlich, dass eine Migration in den meisten Fällen nicht als Einzelperson umsetzbar ist. Da Aufgaben in den verschiedensten Bereichen anfallen werden, sollten so früh wie möglich Architekten, Entwickler, Administratoren und weitere in die Planung einbezogen werden. Diese erkennen eventuell weitere Aufgaben oder Abhängigkeiten, welche für eine Person allein nicht auf den ersten Blick sichtbar waren.

Für jede der Einheiten sollte nun nach dem gleichen Schema vorgegangen werden, um die folgenden Fragen zu beantworten:

• Was für ein Typ ist diese Einheit (Windows Server 2019, .NET Framework 4.5 Projekt, Drittanbieter Software, etc.)?
• Ist eine Migration erforderlich?
• Welche Aufgaben abgesehen von der Migration sind erforderlich?
• Sind vorgelagerte Aufgaben notwendig?
• Welche anderen Einheiten werden durch diese blockiert? Wer ist für die Aufgaben zuständig?
• Welche Risiken ergeben sich bei der Migration dieser Einheit?

Als Hilfestellung für die Durchführung dieser Analysen kann auf diverse Tools zurückgegriffen werden. Mit dem Erstellen eines “Dependency Diagram” in Visual Studio können beispielsweise Projektabhängigkeiten untereinander erkannt werden. Auch für die Portierbarkeit des Quellcodes bietet Microsoft ein hilfreiches Tool mit dem “.NET Portability Analyzer”. Mit diesem kann grob abgeleitet werden, wieviel Aufwand ein einzelnes Projekt hinsichtlich der Migration des Quellcodes benötigt und wie viel Quellcode neu geschrieben werden muss.

Reihenfolge definieren

Da bei einer .NET-Core-Migration Kompatibilitätsprobleme der Plattformimplementierungen auftreten können, sollte bei der Reihenfolgenplanung der Zwischenschritt über eine Migration zu .NET Standard in Betracht gezogen werden. Diese stellt den kleinsten gemeinsamen Nenner der Plattformimplementierungen dar. Dadurch werden die Systeme weiterhin kompilierbar sein und können untereinander referenziert werden.

In der nachfolgenden Grafik ist dargestellt, wie die Systeme „Bottom up“ zu .NET Standard migriert werden. Lediglich die Web-Anwendung wird in diesem Beispiel nicht migriert, da sie nicht von .NET Standard unterstützt wird.

Abbildung 3: Migration zu .NET Standard

Nachdem die Anwendungen auf .NET Standard migriert wurden, ändert sich die Sichtweise zu „Top down“. Die Web-Anwendung auf oberster Ebene kann nun zu .NET Core migriert werden, da alle untergeordneten Projekte bereits auf das kompatible .NET Standard migriert sind. Schritt für Schritt kann nun von oben ausgehend die Migration zu .NET Core erfolgen.

Abbildung 4: Migration zu .NET Core

Migrationsplan aufstellen

Als Abschluss der Konzeption sollte ein zusammenfassender Migrationsplan erstellt werden. Dieser dient den Projektbeteiligten als Überblick über das Vorhaben und die dahinterstehende Strategie. Die Zusammenfassung der wichtigsten Erkenntnisse des Konzepts dienen somit für ein gemeinsames Verständnis und Einverständnis aller Projektbeteiligten. Die wichtigsten Punkte für eine Übersicht sind nachfolgend aufgelistet:

• Beginn der Migration
• Ende der Migration
• Ziele der Migration
• Migrationsstrategie
• Migrationsablauf
• Abhängigkeiten zu Fremdsystemen
• Risiken bei der Migration
• Point of no return
• Rollbackszenarien und -maßnahmen

Nun kann die Konzeption Ihrer eigenen Migration beginnen. Als Hilfestellung habe ich Ihnen hier eine Dokumentenvorlage vorbereitet. Sehr gerne können Sie dieses Dokument für Ihre Migration nutzen und anpassen. Bei Fragen, oder wenn Sie Unterstützung bei Ihrer Migration benötigen, können Sie sehr gerne mich oder einen der anderen Experten der Objektkultur kontaktieren.