Migration (Informationstechnik)

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 19. September 2016 um 06:22 Uhr durch Iso 4 (Diskussion | Beiträge) (→‎Einleitung: Inhalt des unnötigen Nachsatzes in den Ersten [Satz] eingearbeitet). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen

Eine Migration (aus lateinisch migratio ‚Übersiedlung‘) oder Portierung (aus lat. 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:

Software-Migration

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.

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 wäre 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
  • 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[2] 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.[3][4]

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.[5]

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

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 (Eds.): 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:

Datenmigration-Tools:

  • Scriptella – open source Extract-Transform-Load (ETL) und Script-Ausführungs Tool.
  • ETL Integrator – open source Extract-Transform-Load (ETL) Tool mit JBI- (Java Business Integration) Unterstützung zur Datenmigration in SOA- (Service Oriented Architecture) Umgebungen.
  • 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. Porting Project migriert Gupta-Anwender nach .NET. In: Computerwoche, 30. Oktober 2006
  3. Alpha-Server sind Geschichte. ChannelPartner, 11. August 2010
  4. Server Upgrade and Evolution. HP.com, abgerufen am 6. März 2015
  5. Live Migration. Glossar bei DataCenter-Insider.de; Stand: 21. Juli 2010