Überlegungen vor einem Migrationsvorhaben

Überlegungen vor der Migration

• Ziele: Bevor Sie mit der Migration beginnen, sollten Sie sich klare Ziele setzen. Möchten Sie beispielsweise die Effizienz Ihrer Systeme verbessern, einen aktuellen Tech-Stack einsetzen oder die Benutzerfreundlichkeit erhöhen? Welche Probleme mit der existierenden Legacy-Software sind es genau, die zur Entscheidung für eine Migration geführt haben? Wie können diese Probleme in Zukunft vermieden werden?  Die Definition Ihrer Ziele hilft Ihnen, den Fokus während des Migrationsprozesses zu behalten.
• Standardlösung / Eigenentwicklung: Eine wichtige Entscheidung, die Sie treffen müssen, ist, ob Sie eine Standardlösung oder eine Eigenentwicklung verwenden möchten. Standardlösungen sind oft kostengünstiger und einfacher zu implementieren, während Eigenentwicklungen besser an Ihre spezifischen Anforderungen angepasst werden können. Im Kerngeschäftsbereich Ihres Unternehmens ist oft eine Eigenentwicklung sinnvoll, da diese einen wichtigen Wettbewerbsvorteil durch die perfekte Abbildung Ihrer Geschäftsprozesse generieren kann. In Randdomänen wie Buchhaltung etc. ist jedoch in den allermeisten Fällen eine Standardsoftware, ggf. mit Anpassungen, ausreichend.
• Migration / Neuentwicklung: Eine weitere wichtige Entscheidung ist, ob Sie Ihre bestehende Software migrieren oder eine (funktionell gleiche) Software neu entwickeln möchten. Eine Migration kann über die Wiederverwendung bestimmter Teile kostengünstiger sein, erfordert jedoch möglicherweise mehr Zeit und Ressourcen, da eine präzise Analyse der existierenden Software die Voraussetzung ist (Stichwort: Reverse Engineering). Eine Neuentwicklung kann teurer sein, bietet jedoch die Möglichkeit, Ihre Software genau an Ihre Anforderungen anzupassen bzw. auch weitreichende Änderungen an Architektur und Tech-Stack vorzunehmen.
• Eigene / Auftragsentwicklung: Wenn für Sie primär eine Eigenentwicklung in Frage kommt, müssen Sie entscheiden, ob Sie die Entwicklung intern durchführen oder einen Auftragnehmer beauftragen möchten. Eine interne Entwicklung kann bei vorhandenem Know-How im Ziel Tech-Stack kostengünstiger sein, erfordert jedoch möglicherweise mehr Zeit und Ressourcen. Ein Auftragnehmer kann teurer sein, bietet jedoch auch möglicherweise mehr Fachwissen und Erfahrung.
• Erwerb / Miete: Wenn Sie sich für eine Standardlösung entscheiden, müssen Sie entscheiden, ob Sie die Software erwerben oder mieten möchten. Der Kauf kann langfristig kostengünstiger sein, erfordert jedoch möglicherweise mehr Ressourcen. Die Miete kann kurzfristig kostengünstiger sein, erfordert jedoch möglicherweise höhere monatliche Kosten.
• On Premise / Cloud: Die gleiche Überlegung ist auch für die Entscheidung On Premise / Cloud relevant. Cloud Anbieter wie Amazon AWS, Microsoft Azure etc. bieten eine hohe Flexibilität und Skalierbarkeit sowie zahlreiche vorkonfigurierte Lösungen, lassen diese sich aber auch sehr gut bezahlen.
• Personalressourcen / Berater / externe Auftragnehmer: Sie müssen auch entscheiden, welche Ressourcen Sie für die Migration benötigen. Möchten Sie Ihre eigenen Mitarbeiter einsetzen oder einen Berater oder externe Auftragnehmer beauftragen? Siehe auch "Eigene / Auftragsentwicklung".
• Infrastruktur: Sie müssen sicherstellen, dass Ihre Infrastruktur die Anforderungen der neuen Software erfüllt. Möglicherweise müssen Sie zusätzliche Hardware oder Software erwerben oder Ihre bestehende Infrastruktur aktualisieren. Des weiteren muss auch bei einer In House-Entwicklung die entsprechende Infrastruktur vorhanden sein (Stichwort: Entwicklungs- / Test- / Abnahmeumgebung, jeweils mit den erforderlichen Schnittstellen zu externen Diensten, (falls relevant) Geräten etc.).
• Projektmanagement: Eine erfolgreiche Software-Migration erfordert eine sorgfältige Planung und ein effektives Projektmanagement. Sie müssen sicherstellen, dass Sie ein Team haben, das für die Migration verantwortlich ist, und dass Sie einen klaren Zeitplan und Meilensteine haben. Das Team sollte Erfahrung mit dem gewählten Vorgehensmodell (z.B. Scrum) haben. Oft ist es auch sinnvoll das Projektmanagement outzusourcen (-> Externes Projektmanagement), da ein externer Projektmanager oft professioneller, neutraler und effizienter agieren kann als ein in die Prozesse der Firma eingebundener Mitarbeiter)
• Controlling: Sie müssen sicherstellen, dass Sie während des Migrationsprozesses sowohl in Bezug auf Entwicklungsfortschritt als auch Kosten die Kontrolle behalten. Sie sollten regelmäßig den Fortschritt überwachen und sicherstellen, dass das Projekt im Zeitplan bleibt.
• Risikoanalyse: Eine Risikoanalyse ist ein wichtiger Schritt bei der Planung einer Software-Migration. Sie müssen die potenziellen Risiken identifizieren und einen Plan haben, um diese Risiken zu minimieren oder zu vermeiden (Stichwort z.B: vorherige Proof of Concept-Lösungen für kritische Parts, Planung der eigentlichen "Umschaltung" zwischen Alt- und Neusystem). Erst nach einer Risikoanalyse kann die finale Entscheidung für den Start der Migration getroffen werden.
• Cost-/Benefit-Analyse: Schließlich müssen Sie eine Kosten-Nutzen-Analyse durchführen, um sicherzustellen, dass die Migration wirtschaftlich sinnvoll ist. Sie sollten die Kosten der Migration gegen die erwarteten Vorteile abwägen und sicherstellen, dass die Migration einen positiven ROI hat.

Voraussetzungen für eine erfolgreiche Migration

• Gute Dokumentation des Legacy-Systems: Eine gute Dokumentation des Legacy-Systems ist unerlässlich, um sicherzustellen, dass Sie alle wichtigen Informationen über das System haben. Dies kann Ihnen helfen, potenzielle Probleme zu identifizieren und sicherzustellen, dass Sie alle notwendigen Schritte unternehmen, um eine erfolgreiche Migration durchzuführen.
• Re-Engineering des Legacy-Systems: Wenn die Dokumentation des Legacy-Systems unzureichend ist, muss ein Reverse Engineering des Systems durchgeführt werden, um sicherzustellen, dass alle notwendigen Informationen über die aktuelle Implementierung der zu migrierenden Use-Cases vorhanden sind. Dies kann zeitaufwändig und teuer sein, ist jedoch unabdingbar, um eine erfolgreiche Migration durchzuführen.
• Ausreichende Ressourcen: Eine erfolgreiche Software-Migration erfordert ausreichende Ressourcen im Sinne von genügend Personal, Zeit und Budget. Weitere Aspekte wären die Entwicklungs-/Test-Infrastruktur, Einbeziehung von Fachspezialisten, ggf. Räumlichkeiten sowie notwendige Lizenzen bzw. Software-Abonnements.

Grundlegende Migrationstypen

• Architektur-Migration: Eine Architektur-Migration bezieht sich auf die Änderung der Systemstruktur. Dies kann beispielsweise bedeuten, dass Sie von einer monolithischen oder Client-/Server-Architektur zu einer Service-orientierten oder Microservices-Architektur wechseln. Eine Änderung der System-Architektur bedingt in den allermeisten Fällen auch eine Software-Migration.
• Software-Migration: Eine Software-Migration kann entweder einen Wechsel auf eine Standardsoftware oder die Erstellung einer Individuallösung umfassen. Bei einer Individuallösung können Sie entweder eine Migration mit demselben oder aktualisierten Tech-Stack durchführen oder eine Neuentwicklung mit einem neuen Tech-Stack durchführen. Eine weitere Option ist die Anpassung einer Standardsoftware an Ihre spezifischen Anforderungen.
• Daten-Migration: Eine Daten-Migration bezieht sich auf die Übertragung von Daten von einem System auf ein anderes. Es ist wichtig sicherzustellen, dass die Daten fachlich korrekt, vollständig und intakt sind und dass alle Datenschutzvorgaben erfüllt werden. Eine Datenmigration sollte außerdem reproduzierbar und wiederaufsetzbar sein, um das Risiko von Abbrüchen und Fehlern zu minimieren. Sehr wichtig ist außerdem, dass die Datenmigration detailliert dokumentiert wird, um sich im Anschluss ergebende Fragen / Probleme klären zu können.
• System-Migration (zeitlicher Ablauf): Eine System-Migration bezieht sich hier auf den zeitlichen Ablauf der Migration. Es gibt verschiedene Möglichkeiten, wie Sie die Migration durchführen können, einschließlich einer Direktablösung, einem vorübergehenden Parallelbetrieb, einer sukzessiven Umstellung und der Sicherung der Geschäftskontinuität (mehr siehe unten).

Mögliche Strategien für die Umsetzung

• Konversion:  Benutzung eines Konverters, um eine möglichst automatische Umsetzung der Migrationsaufgaben zu erreichen. Hier existieren generische Werkzeuge  für sehr große Anwendungen primär aus dem Mainframe / Cobol Umfeld, aber auch teils z.B. für Delphi oder Visual Basic. Diese benutzen oft Reguläre Ausdrücke bzw. einen Parser der den Quellcode des Quellsystems in einen abstrakten Syntaxbaum zerlegt und in der Zielsprache neu generiert. Die Hauptarbeit liegt hier in der Erstellung / Anpassung des Konverters. Hier ist davon auszugehen, dass die momentan rasante Entwicklung der generativen KI ganz neue Möglichkeiten schaffen wird.
• Kapselung: Die Quellsoftware (oder Teile davon) wird in einen Wrapper "verpackt", der z.B. das Andocken einer neuen, modernen UI erlaubt. Der Wrapper ist damit dauerhaft Bestandteil der Anwendung und erhöht die Komplexität des Gesamtsystems. Trotzdem dürfte dies - sofern technisch umsetzbar - der schnellste Weg für eine Umsetzung sein, da (große) Teile des bestehenden Systems wiederverwendet werden können.
• Neuimplementierung: Neuerstellung des Legacy-Systems unter einem neuen Tech-Stack mit Beibehaltung der Funktionalität. Diese Variante ist sicher die Aufwändigste, erlaubt aber auch ein optimales Design der "neuen" Anwendung in Bezug auf Architektur, Funktionalität und Zielumgebung, so dass hier eine langfristige, gute Basis für Weiterentwicklungen geschaffen wird. Eine Neuimplementierung schließt die Wiederverwendung bestimmter Teile des Altsystems nicht aus, die gut dokumentiert vorliegen und automatisch oder manuell konvertiert werden können.

Zeitlicher Ablauf der direkten System-Migration

• Eine Möglichkeit ist die Direktablösung (“Big Bang”), bei der das alte System vollständig durch das neue System ersetzt wird. Diese Methode ist schnell und einfach, birgt jedoch auch ein hohes Risiko, da bei Problemen das gesamte System betroffen sein kann. In [Lilienthal & Schwentner 2023] wird auf eine ganze Reihe nicht sofort offensichtlicher Probleme verwiesen, die bei einer Big Bang-Umstellung auftreten können. 
• Eine andere Strategie ist der vorübergehende Parallelbetrieb, bei der das alte und das neue System für eine bestimmte Zeit parallel betrieben werden. Diese Methode ist sicherer als die Direktablösung, da das alte System im Falle von Problemen weiterhin zur Verfügung steht.
• Die dritte Strategie ist die sukzessive (inkrementelle) Umstellung, bei der das neue System schrittweise eingeführt wird. Diese Methode ist am sichersten, da das alte System schrittweise abgelöst wird und das neue System bei Problemen leichter angepasst werden kann.

Dritter Teil der Serie: Phasen eines Software-Migrationsprojekts