Migrationsstrategie – Wikipedia

Migrationsstrategien dienen in der Informationstechnik der Migration von Systemen, um eine Ablösung von Systemen durchzuführen.

Eine Migration muss, um erfolgreich zu sein, mindestens den folgenden Anforderungen gerecht werden:

• ununterbrochenen, sicheren, zuverlässigen Betrieb garantieren: Ausfälle zentraler Systeme wie betrieblicher Informationssysteme kann eine Unternehmung nicht über längere Zeit verkraften, auch kürzeste Ausfälle führen zu (finanziellen) Verlusten.
• so viele Änderungen durchführen, wie es notwendig erscheint, um aktuelle und zukünftig erwartete Anforderung abzudecken: hierdurch wird erreicht, dass nicht bereits kurz nach Fertigstellung der Migration das neue System angepasst werden muss, und unter Umständen eine weitere Migration ansteht.
• so wenige Änderungen wie möglich durchführen, um den Umfang und das Risiko der Migration zu verringern: je komplexer eine Migration ist, desto höher ist die Fehlergefahr, die Komplexität einer Migration steigt mit der Anzahl der durchgeführten Änderungen.
• alten Code so wenig wie möglich ändern, um Risiken zu minimieren: solange der Code funktioniert und keine neue Funktionalität notwendig ist, sollte er übernommen werden, wie er ist, bzw. nur minimale Änderungen durchgeführt werden, da Änderungen zwangsweise auch Fehler in der Implementierung nach sich ziehen. Dieses Prinzip wird jedoch meist nicht angewendet, da das ganze System ohne Übernahme von Code neu entwickelt wird.
• alten Code soweit ändern, dass er die Migration unterstützt: wenn durch Änderungen mit vertretbarem Aufwand am Code die Migration vereinfacht wird, sollte dies gemacht werden.
• möglichst große Flexibilität einbauen, um zukünftige Änderungen zu erleichtern: beispielsweise durch die Kapselung der Funktionen und Bereitstellung eines APIs (Application Programming Interface) können zukünftige Entwicklungen und Anpassungen erleichtert werden.
• mögliche negative Auswirkungen der Änderungen minimieren: bei allen Änderungen am System sollte geprüft werden, ob diese Änderungen noch mit dem System verträglich sind, um hierdurch bereits frühzeitig Fehlentwicklungen vorzubeugen.
• den Nutzen moderner Technologien und Methoden maximieren: hierdurch wird zum einen eine zukünftige Anpassung leichter, zum anderen lassen sich Systemwerte, die zur Entscheidung für eine Migration, beispielsweise Performanz, Datendurchsatz, positiv beeinflussen.

Diese Migrationsstrategie besteht aus elf „kleinen Schritten“, die inkrementell durchgeführt werden, wodurch die Migration überschaubar wird, da die eigentliche Migration in kleinere Teile aufgespalten wird (Prinzip „Divide & Conquer“). „Chicken Little“ bedeutet dennoch eine vollständige Neuentwicklung des Systems.

1. Analyse des Altsystems: Für eine erfolgreiche Migration ist es unabdingbar, zuerst die Funktionsweise des Altsystems zu verstehen. Hierbei hilft eine hoffentlich vorhandene Dokumentation, andernfalls Reverse Engineering.
2. Zerlegen des Altsystems: Das Altsystem muss insoweit geändert werden, dass definierte Schnittstellen zwischen den einzelnen Modulen und den Datenbankbackends bestehen.
3. Entwickeln der Schnittstellen des Zielsystems.
4. Entwickeln der Zielanwendungen: Abwägung, ob die Funktionalität der Anwendung des Altsystems nachgebaut werden soll, oder denen der Altanwendung nur möglichst nahekommen soll.
5. Entwickeln des Datenbankbackends: Hierbei werden die Ergebnisse der vorausgegangenen Schritte mit einbezogen, empfohlen wird die Entwicklung mit einer relationalen Datenbank auf Basis von SQL.
6. Installation der Zielumgebung: Aufbau einer Testumgebung und Testen dieser Umgebung.
7. Entwicklung und Installation von Gateways: Die Gateways sind dafür zuständig, die Daten aus dem Altsystem zu extrahieren und in das Zielsystem zu überführen.
8. Migration der Datenbank des Altsystems: Installation des neuen Datenbanksystems, anschließend Migration der Daten zwischen Alt- und Zielsystem.
9. Migration der Altanwendungen: Nach und nach Austausch der einzelnen Module der Altanwendungen und deren Einbindung in das Gesamtsystem.
10. Migration der Benutzeroberfläche
11. Umschalten vom Altsystem auf das Zielsystem: Aktivieren des neuen Systems und Abschalten des alten Systems

Hierbei wird als erstes das Datenbanksystem auf ein modernes System migriert, bevor Anwendungen und Benutzeroberflächen migriert werden. Für den Zugriff der Komponenten des Altsystems auf das neue Datenbanksystem werden sog. Forward Gateways verwendet. Nach vollständiger Migration der Anwendungen und Oberflächen kann das Forward Gateway deaktiviert werden.

Der entscheidende Vorteil dieser Methode ist, dass am Ende der Migration auf jeden Fall die entwickelte Anwendung und die Datenbank zusammenpassen, da die Anwendungsentwicklung erst beginnt, wenn die Migration der Datenbank abgeschlossen ist. Somit kann für Tests der noch zu entwickelnden Anwendung bereits die neue Datenbasis verwendet werden. Ebenfalls vorteilhaft ist, dass durch die Umstellung auf die neue Datenbank sofortige Verbesserungen im Bereich Reporting durch aktuelle Programmiersprachen erzielt werden können. Auch können die einzelnen Anwendungen anschließend eine nach der anderen migriert werden, ohne die Funktion des Systems zu beeinträchtigen.

Hauptnachteil dieses Vorgehens ist, dass es nur auf Systeme anwendbar ist, die eine definierte Schnittstelle zu den Datenbanken, also eine strikte Trennung von Anwendung und Datenbanken, aufweisen. Außerdem muss vor Beginn der Migration die Datenbankstruktur entwickelt werden. Das zu entwickelnde Forward Gateway kann außerdem so kompliziert sein, dass es manchmal überhaupt nicht möglich ist, ein solches zu erstellen.

Dieser Ansatz ist der Gegensatz zu Database First und kann ebenfalls nur auf Systeme mit definierter Datenbackendschnittstelle angewandt werden.

Nach und nach werden die Anwendungen des Altsystems migriert, für den gleichzeitigen Zugriff von Komponenten des Alt- und Neusystems auf den Datenbestand müssen alle Komponenten des Neusystems den Zugriff über Reverse Gateways abwickeln. Der letzte Schritt dieser Migrationsmethode ist die Migration des Datenbanksystems auf die neue Plattform.

Bei diesem Vorgehen wird das neue Anwendungssystem schrittweise entwickelt und implementiert, während das Altsystem noch im Betrieb ist. So bilden beide Systeme ein Verbundsystem, welches solange bestehen bleibt, bis die Migration vollendet ist. Grundlage für diesen Verbund bildet eine Co-Ordinator Schicht, in der Gateways zu den einzelnen Datenbanken des Alt- und Neusystems gebildet werden. Anhand von Mappingtabellen können die einzelnen Relationen migriert werden. Es kann bei vollständig zerlegbaren, semi-zerlegbaren und nicht zerlegbaren Altsystemen angewendet werden.

Bei „Cold Turkey“ handelt es sich, wie bei „Chicken Little“ um eine komplette Neuentwicklung des Altsystems mit Hilfe moderner Entwicklungsmethoden. Hierbei wird parallel zum Altsystem das neue System entwickelt und getestet. Hat das neue System alle notwendigen Tests bestanden, wird in einem finalen Schritt, dem „Big Bang“, das Altsystem deaktiviert und das neue System übernimmt die Arbeit. Hierdurch bedingt ergeben sich aber hohe Risiken für eine funktionierende Migration:

• Eine vollständige Neuentwicklung benötigt Zeit. Mit der Zeit allerdings, die die Entwicklung benötigt, werden auch Änderungen am Altsystem durchgeführt, um die aktuellen Bedürfnisse des Unternehmens zu erfüllen. Hierdurch entsteht ein generelles Problem, da diese Änderungen am Altsystem auch in bereits fertiggestellte Teile des neuen Systems eingepflegt werden müssen. Dies ist fehleranfällig und kostenintensiv.
• Meist gibt es für die Altsysteme keine Dokumentation außer das System selbst, also beispielsweise den Quelltext. Es besteht nunmehr das Problem, dass die ursprünglichen Entwickler des Systems meist nicht mehr verfügbar sind, und somit anhand des Sourcecodes das System und dessen Funktionsweise verstanden werden muss. Zudem bereiten bestimmte Programmiertechniken, wie selbstmodifizierender Code, Probleme bei der Migration.
• Oft existieren nicht dokumentierte Abhängigkeiten zwischen dem Altsystem und anderen Systemen. Diese Abhängigkeiten können im gesamten Spektrum von unkritischen Abhängigkeiten bis zu unternehmenskritischen Abhängigkeiten reichen. Im Entwicklungszyklus des Altsystems steigt die Anzahl der Abhängigkeiten immer weiter an und die Existenz dieser Abhängigkeiten ist, durch die meist fehlende Dokumentation, oft gar nicht bekannt.
• Die schiere Menge an Daten stellt ein weiteres Problem für diesen Ansatz dar. Selbst wenn das Zielsystem vollständig verfügbar ist, würde es in manchen Fällen Wochen dauern, um die Daten aus dem Altsystem in das neue System zu überführen. Während dieser Zeit wären keine Änderungen an den Daten möglich, und somit das System nicht nutzbar. Dies ist für kaum ein Unternehmen ein gangbarer Weg. Auch wird bei einer Migration meist das Datenschema verändert, was während der Datenmigration ebenfalls berücksichtigt werden muss.
• Das Management solch großer Projekte ist extrem schwierig.
• Die oben aufgeführten Punkte führen dazu, dass der Plan für die Entwicklung kaum eingehalten werden kann, sich die Fertigstellung des Systems immer weiter verzögert.

Beim Ansatz der Butterfly-Migration handelt es sich um eine Strategie, die im Gegensatz zu „Chicken Little“ ohne den Einsatz von Gateways auskommt. Die Methode basiert auf einer initialen Migration der Daten-Backends: das Legacy-System bleibt betriebsbereit, während in einer Testumgebung bereits das neue System entwickelt und getestet werden kann, ohne den normalen Betrieb zu beeinflussen oder gar zu stören.

Wichtig für diese Technik der Migration ist die Grundannahme, dass es nur um die reine Datenmigration geht und eine Kooperation zwischen Alt- und Zielsystem nicht notwendig ist.

Zu Beginn des Migrationsprozesses werden neben der Datenbasis des Altsystems mehrere Temporärspeicher eingerichtet und die Datenbasis mit einem Schreibschutz versehen. Durch den Data Access Allocator werden die Zugriffe umgeleitet: noch nicht zugegriffene Information wird aus der Datenbasis geholt, Änderungen werden zu Beginn in den temporären Speicher TS₁ geschrieben. Falls geänderte Informationen abgerufen werden müssen, werden diese aus TS₁ geholt.

Anschließend kann gefahrlos, also ohne Datenverlust und Einbuße an Servicequalität des Systems, der Datenbestand des Altsystems über den sog. „Chrysalizer“, eine Komponente, die die Daten vom Datenschema des Altsystems in das neue Datenschema überführt und im neuen Datenbackend ablegt, in das neue System überführt werden. Während dieser Migration werden alle Datenänderungen, wie oben beschrieben, nicht mehr im Legacy-Datenbackend gespeichert, sondern im Temporärspeicher TS₁.

Ist die Migration der Altdatenbank abgeschlossen, müssen auch noch die Informationen, die in der Zwischenzeit in TS₁ gespeichert worden sind, migriert werden. Hierzu wird TS₁ für Schreibzugriffe gesperrt und der neue Speicher TS₂ geöffnet. Änderungen am Datenbestand werden nun nicht mehr in TS₁, sondern in TS₂ gespeichert. Jedes Mal, wenn nun ein Temporärspeicher TS_n vom „Chrysaliser“ migriert wurde, wird der Speicher TS_n+1 für Schreibzugriffe gesperrt, der Speicher TS_n+2 für schreibende Zugriffe des Legacy-Systems geöffnet, und der Speicher TS_n+1 an den „Chrysaliser“ übergeben. Kann der Inhalt eines Temporärspeichers schneller migriert werden, als der neue Speicher vom Altsystem angelegt wird, dass also während der Migration eines Temporärspeichers TS_n keine Schreibzugriffe des Legacysystems stattfinden, wird die Größe des Temporärspeichers TS_n+2 im nächsten Schritt verringert. Die Größe des Speichers hat für ${\displaystyle n\rightarrow \infty }$ mathematisch den Grenzwert Null.

Während der gesamten Migration arbeitet das System ganz normal weiter, bis die Größe des letzten Temporärspeichers einen bestimmten Schwellenwert unterschreitet, so dass die Zeit, die die Migration dieses letzten Speichers benötigt, extrem kurz ist. Dann kann im letzten Schritt das Altsystem gestoppt werden, der letzte Temporärspeicher in das neue System überführt werden, und das neue System in Betrieb genommen werden, da nunmehr zwischen dem Datenbestand des Alt- und Neusystemes Konsistenz erreicht wurde.

Die Vorteile des Butterfly-Verfahrens liegen auf der Hand: Zum einen ist das komplette System, bis auf den Schritt des finalen Umschaltens auf das Neusystem, dessen Dauer durch die geschickte Wahl des Schwellenwertes weiter minimiert werden kann, zu jeder Zeit verfügbar. Ebenfalls kann zu jeder beliebigen Zeit vor dem Umschalten der Systeme die Migration abgebrochen werden, da die Migration solange umkehrbar ist, solange alle Daten über den Data Access Allocator gelaufen sind. Sollte die Migration abgebrochen werden müssen, müssen nur nacheinander die Tempspeicher beginnend bei TS₁ wieder in die Datenspeicher eingebunden werden.

Nachteil dieser Strategie ist, dass je nach Aktivität im Altsystem extrem viele Temporärspeicher notwendig sein können, die alle, um einen möglichen Abbruch der Migration zu ermöglichen, nicht beispielsweise im Round-Robin-Verfahren überschrieben werden dürfen. Es kann also im Extremfall während der Migration hoher Hardwareeinsatz für Speicherbackends erforderlich sein. Ein anderes Problem stellt die Entwicklung des Data Access Allocators dar: man spart sich, im Gegensatz zu „Chicken Little“ zwar die Entwicklung von Gateways zwischen den Systemen, der Data Access Allocator ist jedoch ebenfalls eine sehr komplexe Komponente, die hohen Entwicklungsaufwand erfordern kann.

• Altsystem
• Elektronische Archivierung
• Informationslebenszyklusmanagement

• Brodie, Stonebraker: Migrating Legacy Systems; Morgan Kaufmann Publishers Inc., 1995
• Bisbal, et al.: A Survey of Research into Legacy System Migration [1]
• Harry M. Sneed et al.: Software-Migration in der Praxis: Übertragung alter Softwaresysteme in eine moderne Umgebung. dpunkt.verlag, Heidelberg 2010, ISBN 3898645649.