proetcon.de > Software-Migration > FiRe > Migrationsphasen
FiRe Migrationsaspekte Migrationsphasen Download
[FiRe]

1. ANALYSE

Ausgangspunkt einer jeden Migration ist die Analyse des Istbestandes. Im Laufe der Zeit tendieren Datenbanken dazu, ein zu Beginn ihrer Existenz sauber implementiertes Schema zu verlieren. Häufig sind Ad-hoc-Lösungen, die unter Zeitdruck kreiert wurden, Ursache derartiger Verwerfungen. Diese Inkonsistenzen werden während unserer Analyse aufgedeckt und Varianten zu deren Beseitigung entwickelt. Auch Dateninhalte unterliegen im Lauf der Zeit einer Erosion. Ursprünglich redundanzfrei abgespeicherte Datensätze werden durch individuelle Fehler dupliziert, wobei nicht selten minimale Differenzen in der Schreibweise einzelner Begriffe entstehen. Wir ermitteln verdoppelte Datensätze auch dann, wenn diese nicht in exakt identischer Notation in der Datenbank abgelegt sind. Auf der Grundlage verschiedener Algorithmen zur Ähnlichkeitsanalyse bestimmen wir Wege und Methoden zur Harmonisierung dieser Daten.
DOWNLOAD
[PDF] FiRe-Datenblatt
[PDF] Success Story ITZBund
[PDF] Success Story Amadeus Germany

2. SCHEMAMIGRATION

[Schemamigration]
Beispiel für Schemamigration
Eine Schemamigration ist oft verbunden mit einem Wechsel des Datenbankparadigmas. Legacy-Systeme basieren nicht selten auf Netzwerk- resp. hierarchischen Datenbankmodellen oder speichern Daten in sequentiellen oder indexsequentiellen Dateien. Ein relationales Redesign des Schemas ist daher notwendig.

Aber selbst eine Schemamigration zwischen zwei, auf relationalem Modell arbeitenden Datenbanken, stellt keinen simplen Kopierprozess dar. Unterschiede in Datentypen und deren Wertebereichen existieren generell, auch wenn gängige SQL-Standards unterstützt werden.

Den kreativen Prozess der Schemamigration begleiten wir mit Tools, die einen hohen Automatisierungsgrad bieten.

3. MIGRATION DER DATENBESTÄNDE

Auf der Basis einer durch uns erfolgreich realisierten Schemamigration und der im Analyseprozess gewonnenen Erkenntnisse werden Daten durch uns vollautomatisch migriert. In diesem Schritt erfolgen Anpassungen an das neue Schema ebenso toolgesteuert wie die Bereinigung der Datenbestände. Erfahrungen aus unterschiedlichen Projekten haben uns gezeigt, dass ausschließlich ein vollständig automatisierter Prozess den Anforderungen größerer Migrationsprojekte gerecht wird. Datenexport im Altsystem, Transformationen der Daten und Import im Zielsystem verlaufen nicht selten nach dem Big-Bang-Prinzip, um Stillstandszeiten der korrespondierenden Applikationen zu vermeiden. Diese Vorgehensweise erfordert aber auch ein ausgereiftes Rollback-Konzept, welches im Extremfall Daten wieder ins Altsystem überführt. Auch für diesen Schritt liefern wir vollständig automatisierte Lösungen. Die nachfolgende Grafik stellt den hier beschriebenen Ablauf beispielhaft dar:
[Datenmigration]

4. MIGRATION DER DATENBANKZUGRIFFE

[Cache-Systeme] Mit der Migration des Schemas und der Datenbestände endet dieser Prozess für uns nicht. Unser Verständnis von Datenbankmigration umfasst auch die Migration der Applikationen, die mit diesen Daten arbeiten. Programme müssen in der Regel immer modifiziert werden, sobald sich die Datenhaltungssysteme ändern. Differenzen im Locking-Verhalten oder in der Transaktionssteuerung, syntaktische Unterschiede in SQL-Interfaces beispielsweise sind ein Grund für diesen Migrationsschritt. Aber auch elementare Fragen der Applikationsperformance sind von fundamentaler Bedeutung. Vor diesem Hintergrund müssen Entscheidungen getroffen werden, ob SQL embedded in statischer oder dynamischer Form benutzt werden kann oder ob zusätzliche Cache-Systeme erforderlich sind. Unabhängig von der konkreten Beantwortung dieser Fragen sind massive Eingriffe in den Applikationscode notwendig. Wir verfügen über mächtige Werkzeuge, wie beispielsweise CoJaC, mit dem diese Anpassungen vollautomatisiert durchgeführt werden können.

5. TEST DER MIGRIERTEN DATEN

[Test] Wir verfolgen ein weitgehend vollautomatisiertes Testmanagement. Es wird eine sogenannte Reverse-Migration vollzogen, bei der die Daten des Zielsystems auf umgekehrtem Weg automatisiert in Daten des Ausgangssystems migriert werden. Diese Recovery-Daten werden dann mit den originalen Datenbeständen auf semantische Identität geprüft. Das Persistenz-API wird separat getestet (Komponententests). Dazu werden einerseits die migrierten Daten und andererseits spezielle Testdaten genutzt, mit denen möglichst viele Testfälle abgedeckt werden können.