Vryjdfkk

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

Eine Migration (aus lateinisch migratio ‚Übersiedlung‘) oder Portierung (aus lateinisch portatio für ‚herbeischaffen‘) ist in der Informationstechnik ein Umstellungsprozess in Datenverarbeitungssystemen.

Begriffsabgrenzung |

Der Begriff der Migration ist vielschichtig. Er kann sowohl die Umstellung insgesamt als auch jeden darin eingeordneten Anpassungsprozess einzelner Bestandteile des Systems bezeichnen. Beispielsweise bedeutet bzw. beinhaltet Migration von einem Betriebssystem auf ein anderes in der Regel zugleich die Migration von Anwendungssoftware und Daten.

Bei Abgrenzung der Ausdrücke Migration und Portierung wird ersterer als allmähliche Veränderung in vielen bzw. kleinen Schritten gedeutet, letzterer als gröberer Umbruch.^[1]

Daneben ist der Begriff der Portierung spezifisch im Bereich der Softwaretechnik etabliert und bedeutet dort:

• Umarbeiten einer bereits vorhandenen Software zur Verwendung in einer anderen Laufzeitumgebung oder Plattform
  


• Umstellen des Entwicklungsprozesses einer bestimmten Software auf eine andere Programmiersprache oder Entwicklungsumgebung
  

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.^[2]

In der Durchführung unterscheidet man vier Arten:

1. Refreshment: hier werden Daten lediglich auf einen Datenträger gleichen Typs kopiert. Es finden keine Änderungen an Daten oder der Speicherinfrastruktur statt.


2. Replication: hier werden ebenfalls, wie beim Refreshment, Daten von einem Träger auf einen neuen kopiert. Hierbei kann es sich aber auch um einen anderen, neueren Datenträger handeln. Der Unterschied zum Refreshment besteht damit in der Änderung der Speicherinfrastruktur. Bsp: Daten von einer Diskette auf einen USB-Stick.


3. Repackaging: hier wird ein Archivpaket verändert, d. h. es werden Datenobjekte selbst umgeschrieben. Beispiel: Ein komprimierte Datei im .zip-Format wird in eine Datei im .rar-Format komprimiert. Die Änderung in dem Beispiel liegt damit im Packformat.


4. Transformation: hier werden, ähnlich dem Repackaging, ebenfalls Datenobjekte selbst umgeschrieben. Allerdings werden hier die Inhalte des Archivpakets verändert. Beispiel: eine Text-Datei im .docx-Format wird in eine Textdatei im .odt-Format geändert.

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 Repackagung 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.

Software-Migration |

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

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.^[4]

Beispiele für eine Software-Migration:

• der Umstieg vom Betriebssystem Microsoft 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.


• Eine Migration ist es auch, wenn von einem Major Release auf das nächsthöhere desselben Softwareanbieters umgestellt wird. 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; es sollte hier besser von einer Portierung gesprochen werden.


• 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^[5] 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 die .NET-Plattform.

Datenmigration |

Unter einer Datenmigration wird das Ersetzen einer Plattform verstanden, mit welcher Daten verwaltet und vom Altsystem übernommen werden. Bei der Plattform kann es sich dabei z. B. um physische Datenspeicher oder eine Datenbanksoftware handeln.

Beispiele:

• Eine Bank ersetzt ein selbstentwickeltes 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

Eine Datenmigration besteht aus drei Schritten. Im Extraktionsschritt wird gefiltert, welche Daten übernommen werden sollen. Kunden, die vor fünfzig Jahren gestorben sind, werden beispielsweise nicht übernommen. 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“. 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ählten Testfällen beispielsweise manuell (pars pro toto) und verwendet zusätzlich Statistiken. Statistiken erlauben, eine „Nadel im Heuhaufen“ zu finden, also 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 Software-Migration als auch der Datenmigration zusammen; oft wird auch neue Hardware benötigt. Eine sorgfältige Planung (siehe auch Migrationsstrategien) 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 Software-Migration 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.^[6][7]

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.^[8]

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 weiter zu fü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 Microsoft Windows, das noch die OS/2- und DOS-Kompatibilität sicherstellen muss. In modernen Windows-Versionen führt das dazu, dass ein eigener DOS-Betriebssystem-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) – 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. 
   ↑ Fallstricke beim Wechsel der Anwendungsplattform vermeiden. In: Entwickler-Magazin, Februar 2010
   


2. 
   ↑ Dagmar Ullrich: Bitstream Preservation. 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 (PDF). 
   


3. 
   ↑ Luda, Christian:: Softwaremigration. Konzepte und praktische Umsetzung am Beispiel einer Musikdatenbank, B.A.-Thesis. Offenburg 2011, S. 1. 
   


4. 
   ↑ Luda, Christian: Softwaremigration. Konzepte und praktische Umsetzung am Beispiel einer Musikdatenbank, B.A.-Thesis. Offenburg 2011, S. 5. 
   


5. 
   ↑ Porting Project migriert Gupta-Anwender nach .NET. In: Computerwoche, 30. Oktober 2006
   


6. 
   ↑ Alpha-Server sind Geschichte. ChannelPartner, 11. August 2010
   


7. 
   ↑ Server Upgrade and Evolution. HP.com, abgerufen am 6. März 2015
   


8. 
   ↑ Live Migration. Glossar bei DataCenter-Insider.de; Stand: 21. Juli 2010