Migration (Informationstechnik)

Dieser Artikel oder Abschnitt bedarf einer grundsätzlichen Überarbeitung. Näheres sollte auf der Diskussionsseite angegeben sein. Bitte hilf mit, ihn zu verbessern, und entferne anschließend diese Markierung.

Der Begriff Migration (aus lateinisch migratio ‚Übersiedlung‘) steht in der Informationstechnik für den Prozess einer grundlegenden Veränderung einer bestehenden Systemlandschaft oder eines wesentlichen Teils dieser Landschaft. Die Migration kann sich sowohl auf Hard- als auch auf Software beziehen.

Begriffsabgrenzung

Der Begriff der Migration ist vielschichtig. Er kann zum einen für die Umstellung eines einzelnen Systems stehen. Zum anderen können damit auch große Migrationsprojekte gemeint sein, bei denen viele Systeme oder mehrere neue Anwendungen implementiert werden. Die Migration von einem Betriebssystem auf ein anderes umfasst in der Regel zugleich die Migration von Anwendungssoftware und Daten.

Der Begriff Portierung steht in der Abgrenzung zu Migration für die Übertragung eines Programms von einer Hard- und/oder Softwareplattform auf eine andere. Dafür werden die Programme – die für ein bestimmtes Betriebssystem oder eine Plattform geschrieben wurden – so verändert, dass sie auf einem anderen Betriebssystem laufen. Zum Teil werden die Begriffe synonym verwendet.

Medienmigration

Medienmigration bezeichnet einen Vorgang, bei dem das physische Datenträgermedium eines Datenobjekts innerhalb eines Archivs geändert wird. Sie ist damit eine Verfahrensart zur Erhaltung eines Bitstreams.

In der Durchführung unterscheidet man vier Arten:

Bei Refreshment und Replication geht es ausschließlich den Erhalt von bestehenden Daten durch Wechsel der Speichermedien. Sie stellen damit Medienmigration im engeren Sinne dar.

Hingegen werden bei Repackaging und Transformation auch der Inhalt der Daten verändert. Es liegt also eine doppelte Funktion vor. Zum einen wird mit der Änderung des Datenformats ein neues Datenobjekt erstellt, das in der Regel auf einem neuen Datenträger abgespeichert wird. Allerdings erfolgt hier die Migrationsmaßnahme auch mit Blick auf die zukünftige Interpretierbarkeit, d. h. Lesbarkeit der Daten. Deswegen spricht man hier von Medienmigration im weiteren Sinn oder Formatmigration.

Softwaremigration

Softwaremigration lässt sich als Prozess der Umstellung von einer bisherigen zu einer neuen technologischen Umgebung definieren.

Die Migration geht über eine einfache Aktualisierung bzw. ein Upgrade hinaus und bezeichnet vielmehr einen grundlegenden Wechsel der Software-Infrastruktur. Basis einer Migration bilden Migrationsstrategien. Im Idealfall stehen Dienstprogramme zur weitestgehend automatisierten Umstellung zur Verfügung.

Häufigste Gründe für die Durchführung einer Softwaremigration sind die Überalterung der Software oder das bestehende Altsystem („Legacy-System“) ist nicht mehr in der Lage, neue Anforderungen an Hard- und Software zu erfüllen. Letzteres kann besonders in Organisationen gegeben sein, wenn geeignetes IT-Fachpersonal für ältere Software fehlt.

Beispiele für eine Softwaremigration:

• Der Umstieg vom Betriebssystem Windows auf Linux oder von Unix auf Windows. Aber auch der Umstieg von einer alten AS/400 auf Linux ist eine Migration. Dabei werden oft schrittweise einzelne Computerarbeitsplätze oder die für einzelne Arbeitsschritte benötigte Software migriert.
• Eine Teilmigration dagegen wäre es, eine neue AS/400 (System i) so zu partitionieren, dass OS/400 und Linux gleichzeitig darauf laufen und Software aus beiden Welten auf nur einem Server genutzt werden kann.
• Die Anpassung von plattformgebundener Software an ein anderes (Hardware-)System, wofür es Werkzeuge wie User State Migration Tool gibt.
• Auch eine Portierung ist eine Migration. Dabei wird von einem Major Release auf das nächsthöhere desselben Softwareanbieters umgestellt. Industriekunden, die noch ein altes SAP-R/2-Informationssystem in Betrieb haben und auf SAP R/3 oder mySAP wechseln wollen, stehen vor einer anspruchsvollen Aufgabe. Beide SAP-Versionen unterscheiden sich grundlegend. Derartige Migrationen sind daher mitunter extrem schwierig und können scheitern.
• Die Legacy-Migration: Dabei wird eine Altanwendung auf eine neue Anwendungssoftware (zum Beispiel mit einer moderneren Basistechnologie oder auf eine Standardsoftware) umgestellt, um die langfristige Weiterentwicklung zu gewährleisten. War ein solches Porting-Projekt früher zwingend mit einer Neuprogrammierung des Anwendungscodes verbunden, stehen für bestimmte Migrationspfade mittlerweile automatisierte Werkzeuge zur Verfügung. Ein Beispiel hierfür ist die Ablösung der veralteten 4GL-Plattform Gupta Team Developer durch das .Net-Framework.

Datenmigration

Der Begriff Datenmigration steht für die Überführung von Daten von einem Quellsystem in ein Zielsystem. Durchgeführt wird eine Datenmigration, wenn ein neues System die Aufgaben eines oder mehrerer Altsysteme übernehmen soll. Auch die Ablösung eines Altsystems durch ein bereits produktives System bedingt eine Datenmigration.

Die Gründe für eine Datenmigration sind zum Beispiel inadäquate Datenbankstrukturen, kaum noch wartbare Anwendungssysteme, die Zusammenführung mehrerer Informationssysteme zu einem einheitlichen System und der Wunsch, neue Datenbanktechnologien einzuführen.

Beispiele:

• Eine Bank ersetzt ein selbst entwickeltes System durch Standardsoftware. Es reicht nicht, nur die Standardsoftware zu installieren. Kundendaten, Konten und Kontostände müssen auch übernommen werden.
• Bei der Fusion von Unternehmen müssen die Daten beider Unternehmen zusammengeführt werden.
• Die Konvertierung in eine andere Zeichenkodierung
• Die Übertragung von Datenbanken
• Die Übertragung von Textdokumenten, die Makros enthalten, auf ein anderes Office-Format
• Die Übertragung von Tabellenkalkulationen, die eigene Formeln enthalten
• Das Zusammenlegen von mehreren unterschiedlichen Programmen in ein gesamtes Programm

Eine Datenmigration besteht aus mehreren Schritten – angefangen bei der Analyse der Quellsysteme bis zum Validieren der Ergebnisse. Die eigentliche Migration besteht aus drei Schritten.

Im Extraktionsschritt wird gefiltert, welche Daten übernommen werden sollen. Dazu werden die Daten zunächst analysiert, dann extrahiert und abgeglichen. Zudem werden Steuerungsdaten wie Mappingtabellen bereitgestellt. Als Zweites erfolgt eine Transformation. Die Daten liegen im Datenmodell des Altsystems vor. Sie müssen also transformiert werden, dass sie zum Datenmodell des Zielsystems „passen“. Relevante Daten werden selektiert, fehlerhafte Daten korrigiert und mehrfach vorliegende Daten zusammengeführt. Anschließend folgt das Mapping. Im dritten und letzten Schritt werden die transformierten Daten ins Zielsystem geladen.

Die drei Schritte entsprechen dem ETL-Prozess eines Data-Warehouse. Das Ziel ist aber ein anderes. Ein Data-Warehouse soll neue Erkenntnisse liefern, z. B. um die Entwicklung von Verkaufszahlen zu verstehen. Bei der Datenmigration hingegen bleiben die Daten semantisch unverändert. Alle (relevanten) Kunden sind weiterhin vorhanden. Die Kontostände sind ebenso unverändert. Einzig das Datenmodell kann sich ändern.

Technisch realisiert werden kann eine Datenmigration beispielsweise mittels ETL-Tools, Spezial-Migrationstools mit SQL-Skripten. Zuverlässigkeit spielt eine wichtige Rolle (es sollen keine Konten „verloren“ gehen). Ebenso sind oft sehr viele Objekttypen zu migrieren (Kunden, Konten, Aktiendepots, Börsenplätze, Bilanzdaten etc.). Eine Ablaufsteuerung koordiniert den ETL-Prozess für die verschiedenen Objekttypen. Eine Migrationsverifikation betrachtet ausgewählte Testfälle beispielsweise manuell (pars pro toto) und verwendet zusätzlich Statistiken. Statistiken erlauben, eine „Nadel im Heuhaufen“ zu finden, wenn beispielsweise ein einziges Konto von 10.000.000 zu migrierenden Konten fehlt.

Anwendungsmigration

Im Rahmen der Anwendungsmigration wird eine Anwendung durch eine neue ersetzt. Bei diesem Prozess kommen sowohl Elemente der Softwaremigration als auch der Datenmigration zusammen; oft wird auch neue Hardware benötigt. Eine sorgfältige Planung (Migrationsstrategie) und Durchführung ist entscheidend zur Wahrung der Datenkonsistenz und zum reibungslosen Wechsel der Funktionalität von der alten auf die neue Anwendung.

Hardware-Migration

Die Migration bestehender Systeme auf neue Hardware wirft in etwa dieselben Probleme auf wie rein softwareseitige Migration und ist über Schnittstellentreiber meist zwangsläufig mit einer gewissen Softwaremigration verbunden. Datenmigration wird dabei tunlichst vermieden.

Ein Beispiel aus der Praxis ist der Übergang von einem klassischen Ethernet-Netzwerk zur ATM-Technologie unter Beibehaltung der strukturierten Verkabelung.

Eine Hardware-Migration zu einer völlig neuen Mikroprozessor-Technologie führte das Unternehmen Hewlett-Packard bei Bestandskunden seiner Server-Produkte ab etwa den 2000er Jahren durch. Dabei werden nach und nach die bei Kunden befindlichen Server mit den älteren Alpha-Prozessoren und PA-RISC-Prozessoren auf die zusammen mit Intel entwickelte Itanium-Prozessortechnologie umgestellt.

Live-Migration

Als Live-Migration wird der Umzug einer virtuellen Maschine (VM) bezeichnet, bei dem eine VM im laufenden Betrieb von einem physikalischen Wirtssystem (Host) auf ein anderes übertragen oder verschoben wird. Im Idealfall findet solch ein Umzug ohne Beeinträchtigung der VM statt, sodass auch laufende Arbeiten in der VM ohne Unterbrechung fortgesetzt werden können. Das Ziel derartiger Migrationen ist eine einfachere Wartbarkeit von Hardware sowie ein möglicher Lastenausgleich derselben.

Umstellung auf neuere Schnittstellen und Techniken

Eine Funktion oder ein Parameter eines Programmes oder beispielsweise SGML-Elemente in Auszeichnungssprachen, welche in Folgeversionen möglicherweise nicht mehr verfügbar sein werden, oder aber auch überholte Programmiertechniken, werden als missbilligt/hinfällig (englisch deprecated) eingestuft.

Der Sinn, diese aber dennoch weiterzuführen, liegt in der Aufwärtskompatibilität. Denn wenn eine Schnittstelle einfach abgeschafft würde, entstehen leicht Ausnahmefehler. Daher wird die alte Verarbeitung der Eingabe auf solch einer Schnittstelle durch eine einfache Fehlerbehandlungsroutine ersetzt, etwa, indem eine Funktion einen Rückgabewert erhält. Der Aufrufer erhält dann z. B. nicht einen Fehler, sondern zumindest einen – wenn vielleicht auch unnützen – Wert des erwarteten alten Datenformats. Das vermeidet Probleme, die folgen können, wenn der Aufrufer keine Fehlerauswertung auf dieser Schnittstelle implementiert hatte. Die Wahl des neuen Dummy-Werts bedarf aber einer sorgfältigen Auswahl (Ein Parameter vom Datentyp text etwa müsste als "none" zurückgegeben werden) und Kenntnis des ursprünglichen Wertebereichs (0 etwa könnte eine Division durch null nach sich ziehen).

Zur Unterstützung der Umstellung besteht in manchen Programmiersprachen oder Entwicklungsumgebungen die Möglichkeit, missbilligte Techniken mit bestimmten Schlüsselwörtern zu kennzeichnen.

Die Behandlung komplexer Schnittstellen kann ziemlich aufwändig werden, denn andernfalls geht dann einfach die Aufwärtskompatibilität verloren. Das „Mitschleppen von Altlasten“ kann sich im Laufe von Weiterentwicklung zu eminenten Problemen auswachsen: Ein typisches Beispiel ist die 16-Bit-Kompatibilität des Betriebssystems Windows, das noch die OS/2- und DOS-Kompatibilität sicherstellen muss. In modernen Windows-Versionen führt das dazu, dass ein eigener DOS-Emulator implementiert sein muss.

Zwischen den beiden Möglichkeiten abzuwägen, ist eines der Hauptprobleme der Versionsverwaltung moderner Software. Daher wird bei neuen Versionen zwischen kleiner (minor) und großer Aktualisierung (major Upgrade) unterschieden, je nachdem, in welchem Ausmaß die Aufwärtskompatibilität gewährleistet wird. Eine Migration über mehrere Versionen (Releases) hinweg kann wesentlich leichter Probleme bereiten oder gar eine Neuinstallation erfordern.

Siehe auch

• Elektronische Archivierung
• Informationslebenszyklusmanagement
• Langzeitarchivierung

Literatur

• Knut Hildebrand: IT-Integration & Migration. Dpunkt Verlag, Heidelberg 2007, ISBN 978-3-89864-455-6.
• Michael Willinger, Johann Gradl, Frank Densborn, Michael Roth: Datenmigration in SAP. 3., aktualisierte und erweiterte Auflage. Galileo Press, Bonn 2012, ISBN 978-3-8362-1808-5.
• John Morris: Practical Data Migration. British Computer Society, Swidon 2006, ISBN 1-902505-71-9 (englisch).
• Jesús Bisbal et al.: A Survey of Research into Legacy System Migration. Technical Report. Trinity College, Dublin 1997, cs.cofc.edu (PDF; 200 kB), Abstract.
• Klaus Haller: Towards the Industrialization of Data Migration: Concepts and Patterns for Standard Software Implementation Projects. In: Pascal van Eck, Jaap Gordijn, Roel Wieringa (Hrsg.): Advanced Information Systems Engineering, 21st International Conference, 2009, Amsterdam. Proceedings. Springer, Heidelberg 2009, ISBN 978-3-642-02143-5 (PDF, englisch)
• Carlo Breves, Eberhard von Radetzky: Anwendungsmigration im Rahmen von Beratungsprojekten. In: Zeitschrift für Unternehmensberatung, 8/2008, Erich Schmidt Verlag.

Weblinks

Allgemeine Information:

• Migrationsleitfaden des Bundesinnenministeriums (PDF; 1,7 MB) – Informationen zur Migration auf Open-Source-Software in öffentlichen Einrichtungen, abgerufen am 29. September 2012
• tuxfutter.de – ein Wiki zur Migration auf freie Software und Linux mit Anleitungen und Software-Alternativen

Datenmigration-Tools:

• Scriptella – open source Extract-Transform-Load (ETL) und Script-Ausführungs Tool.
• ETL Integrator Oracle Software Delivery Cloud.
• Daten Migration Toolkit (DMT) – GUI-basiertes Java Programm zur Migration von Dateien und Datenbankdaten (kostenloses Tool, welches die Datenmigration praktisch veranschaulicht).

Einzelnachweise

1. Bundesstelle für Informationstechnik: Migrationsleitfaden, Leitfaden für die Migration von Software (Version 4.0). In: http://www.cio.bund.de. Die Beauftragte der Bundesregierung für Informationstechnik, März 2012, abgerufen am 15. August 2020. 
2. Rouse, Margaret: Migration. In: SearchCIO. TechTarget, Oktober 2016, abgerufen am 15. August 2020. 
3. o. V.: Portierung. In: http://www.it-administrator.de. Heinemann Verlag GmbH, abgerufen am 15. August 2020. 
4. portieren. In: Computerlexikon. Alexander Kirk, 26. Oktober 1998, abgerufen am 15. August 2020. 
5. Dagmar Ullrich: Bitstream Preservation. (PDF) In: nestor-Handbuch. Eine kleine Enzyklopädie zur digitalen Langzeitarchivierung. H. Neuroth, A. Oßwald, R. Scheffel, S. Strathmann, K. Huth, Juli 2010, abgerufen am 1. Februar 2018. 
6. Christian Luda: Softwaremigration. Konzepte und praktische Umsetzung am Beispiel einer Musikdatenbank, B.A.-Thesis. Offenburg 2011, S. 1. 
7. Christian Luda: Softwaremigration. Konzepte und praktische Umsetzung am Beispiel einer Musikdatenbank, B.A.-Thesis. Offenburg 2011, S. 5. 
8. In: Computerwoche, 30. Oktober 2006
9. Elvan Öztürk: Datenmigration. In: https://wwwmatthes.in.tum.de/pages/t5ma0jrv6q7k/sebis-Public-Website-Home. Fakultät für Informatik, Universität München, 18. Juli 2011, abgerufen am 15. August 2020. 
10. K. Schwinn, R. Dippold, A. Ringgenberg, W. Schnider, und S. Fedtke: Die erfolgreiche Datenmigration aus Altsystemen. Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden, 1999, abgerufen am 16. August 2020. 
11. Jochen Knösels: Ablauf einer SAP Datenmigration. Gambit Consulting GmbH, abgerufen am 15. August 2020. 
12. Bittner, Deborah: Migration in der Informationstechnik. In: Netzorange. Abgerufen am 16. August 2020. 
13. Alpha-Server sind Geschichte. ChannelPartner, 11. August 2010
14. Server Upgrade and Evolution. HP.com, abgerufen am 6. März 2015
15. Live Migration. Glossar bei DataCenter-Insider.de; Stand: 21. Juli 2010

Normdaten (Sachbegriff): GND: 4226008-5 (lobid, OGND)