Data Migration — Wesen, Methoden und Datenübertragungsprozess

Was ist Data Migration

Data Migration ist der Prozess der Übertragung von Daten von einer Quelle zu einer anderen unter Gewährleistung ihrer Integrität, Konsistenz und Verfügbarkeit nach Abschluss. Im Gegensatz zum einfachen Kopieren umfasst die Migration Formattransformation, Dublettenbereinigung, Prüfung der referenziellen Integrität und Ergebnisvalidierung.

Der Bedarf an Data Migration entsteht beim Upgrade eines DBMS (z. B. von MySQL 5.7 auf MySQL 8.0), beim Wechsel des Cloud-Anbieters, bei der Migration vom Monolithen zu Microservices oder beim Umstieg auf ein NoSQL-Schema. Laut Stripe (2024) sind 89 % der Unternehmen mindestens einmal alle zwei Jahre mit einer Datenmigration konfrontiert, und 43 % betrachten sie als anspruchsvollste Phase einer technischen Aktualisierung.

Hauptziele der Datenmigration

Das erste Ziel ist die Leistungssteigerung durch den Umstieg auf eine modernere Speicherlösung. Das zweite ist die Senkung der Betriebskosten beim Wechsel des Infrastrukturanbieters. Das dritte ist die Sicherstellung der Einhaltung gesetzlicher Vorschriften (DSGVO, 152-FZ), wenn Daten in einer bestimmten Rechtsordnung gespeichert werden müssen.

Wie sich Migration von Integration unterscheidet

Integration beinhaltet eine kontinuierliche Synchronisation zwischen zwei laufenden Systemen. Migration ist eine einmalige Übertragung mit anschließender Außerbetriebnahme der Quelle. Die Integration löscht keine Daten in der Quelle; die Migration endet mit der Überführung des Zielsystems in den Primärstatus. Dieser grundlegende Unterschied bestimmt die Wahl der Werkzeuge und Validierungsansätze.

ETL-Modell der Datenmigration

Die grundlegende Architektur jeder Data Migration basiert auf dem ETL-Modell (Extract, Transform, Load). Extract — Extrahieren von Daten aus der Quelle. Transform — Umwandlung in das Zielschema. Load — Laden in das Ziel. Jede Phase hat ihre eigenen Qualitätskontrollmethoden.

Extract: Datenextraktion

In der Extraktionsphase werden Daten aus der Quelldatenbank, dem Dateispeicher oder der API gelesen. Die inkrementelle Extraktion (CDC — Change Data Capture) ermöglicht die Übertragung nur geänderter Datensätze und reduziert so das Datenvolumen. Ein vollständiger Dump eignet sich für kleine Datenmengen, aber für terabytegroße Datenbanken ist die Streaming-Replikation über Debezium oder Kafka Connect vorzuziehen.

Transform: Schema-Transformation

Die Transformation umfasst das Umbenennen von Spalten, das Ändern von Datentypen, das Normalisieren von Werten und die Aggregation. Beispielsweise muss bei der Migration von MySQL zu PostgreSQL der numerische Typ DECIMAL in NUMERIC und das Datumsformat in ISO 8601 konvertiert werden. Laut Talend (2024) werden 70 % der Migrationszeit für die Transformation aufgewendet, nicht für die Übertragung.

Load: Laden in das Ziel

Das Laden erfolgt in Batches (batch insert) oder per Streaming. Zur Vermeidung von Duplikaten wird ein Idempotenzschlüssel verwendet. Nach dem Laden ist ein Validierungsschritt zwingend erforderlich: Vergleich der Datensatzanzahl, Berechnung von Prüfsummen und Überprüfung von Geschäftsregeln. Ohne Validierung gilt die Datenmigration als unvollständig.

Datenmigrationsstrategien

Die Wahl der Data-Migration-Strategie bestimmt die Systemausfallzeit, die Komplexität des Rollbacks und den Umfang der Vorbereitungsarbeiten. Die Hauptstrategien sind Big Bang, Trickle und Parallel Run. Jede ist in verschiedenen Szenarien anwendbar.

Big Bang Migration

Big Bang ist die einmalige Abschaltung des alten Systems, die Datenübertragung und die Inbetriebnahme des neuen. Geeignet für kleine Datenmengen und einfache Schemata. Risiko: Bei einem Fehler ist das System bis zur vollständigen Wiederherstellung aus dem Backup nicht verfügbar. Im Jahr 2024 verwendete GitLab Big Bang, um 5 TB Daten von AWS RDS zu GCP Cloud SQL mit einem Ausfallfenster von 14 Stunden zu migrieren.

Trickle Migration

Trickle ist eine Streaming-Synchronisation in kleinen Portionen. Das alte und das neue System laufen parallel, Änderungen werden in Echtzeit repliziert. Nach der Datenstabilisierung wird die alte Quelle abgeschaltet. Dieser Ansatz erfordert bidirektionale Synchronisation und Konfliktlösung. Er wird in Continuous Delivery beim Aktualisieren des Datenbankschemas ohne Ausfallzeit verwendet.

Parallel Run

Parallel Run — beide Systeme arbeiten gleichzeitig, die Anwendung schreibt und liest aus beiden Quellen. Nach der Datenverifizierung am Ziel wird die alte Quelle abgeschaltet. Dies ist die sicherste, aber auch die teuerste Strategie — sie erfordert die Wartung von zwei Infrastrukturen. Sie wird bei der Migration kritischer Finanzsysteme eingesetzt.

Arten der Datenmigration

In der Anwendungsentwicklung werden verschiedene Arten von Data Migration nach dem Übertragungsobjekt und Kontext unterschieden. Jede Art hat ihre eigene Methodik und Werkzeuge. Das Verständnis der Art ist der erste Schritt zur Wahl der richtigen Strategie.

Datenbankmigration (Database Migration)

Database Migration ist die Übertragung zwischen DBMS verschiedener Anbieter: von Oracle zu PostgreSQL, von SQL Server zu MySQL, von MongoDB zu DynamoDB. Die Komplexität liegt in inkompatiblen Datentypen, SQL-Dialekten und Indexierungsmechanismen. Werkzeuge: AWS DMS, Debezium, Liquibase.

Anwendungsdatenmigration (Application Data Migration)

Die Übertragung von Daten zwischen verschiedenen Versionen derselben Anwendung — zum Beispiel bei der Aktualisierung von Code mit Änderungen an der Entitätsstruktur. Oft begleitet von der Ausführung von Migrationsskripten in der Anwendungssprache: Active Record Migrations in Ruby on Rails, Flyway für Java, Entity Framework Migrations in .NET. Diese Skripte transformieren nacheinander das Schema und die Daten.

Cloud-Datenmigration (Cloud Data Migration)

Cloud Data Migration ist die Übertragung von Daten aus der lokalen Infrastruktur in die Cloud oder zwischen Clouds. AWS Snowball, Azure Data Box und Google Transfer Appliance werden für den physischen Transport von terabytegroßen Datenmengen verwendet. Für die Online-Migration werden VPN-Tunnel und Replikation eingesetzt. Laut Gartner werden bis 2027 70 % der Migrationen in einer hybriden Cloud-Umgebung durchgeführt.

Planung der Datenmigration

Data Migration ohne Plan ist ein garantierter Fehlschlag. Die Planung umfasst die Prüfung des aktuellen Schemas, die Datenprofilierung, die Auswahl der Strategie, die Vorbereitung der Umgebung, das Testen und die Genehmigung des Rollback-Plans. Laut einer McKinsey-Studie (2024) werden 54 % der fehlgeschlagenen Migrationen durch das Fehlen eines formalen Plans verursacht.

Prüfung und Profilierung

Vor der Migration muss eine Prüfung des Quellsystems durchgeführt werden: Ermittlung des Datenvolumens, der Anzahl der Tabellen, der Abhängigkeiten zwischen Entitäten, der Typen von NULL-fähigen Feldern und des Vorhandenseins von Duplikaten. Die Profilierung identifiziert Anomalien — NULL-Werte in Schlüsselfeldern, Formatabweichungen, defekte Links. Diese Daten bilden die Baseline des vollständigen Dumps.

Vorbereitung der Testumgebung

Vor dem Hauptstart wird eine Testmigration mit einer Kopie der Produktionsdaten durchgeführt. Ziel ist es, die Leistung der ETL-Pipeline, die Korrektheit der Transformation und die Ladegeschwindigkeit zu überprüfen. Vor Big Bang werden mindestens drei vollständige Testzyklen empfohlen. Jeder Zyklus umfasst eine vollständige Übertragung, Validierung und ein Rollback.

Rollback-Plan

Rollback ist die Rückkehr zum ursprünglichen System, wenn kritische Fehler festgestellt werden. Der Rollback-Plan umfasst: ein vollständiges Backup der Quelle vor dem Start, Schema-Wiederherstellungsskripte, eine Schritt-für-Schritt-Anleitung zur Wiederinbetriebnahme des alten Systems und einen Kommunikationsplan zur Benutzerbenachrichtigung. Ohne einen genehmigten Rollback-Plan sollte die Datenmigration nicht in der Produktion gestartet werden.

Codebeispiele für Datenmigration

Betrachten wir ein praktisches Beispiel für Data Migration in Kotlin in Kombination mit Flyway. Das Migrationsskript V1 erstellt eine Benutzertabelle und überträgt Daten aus einem Legacy-Format. Flyway verfolgt automatisch angewendete Migrationen und gewährleistet die Idempotenz.

// V1__Migrate_Users.kt — Datenmigration aus Legacy-Format
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

Ein Migrationsbeispiel in Python mit SQLAlchemy zur Übertragung von Daten aus CSV nach PostgreSQL. Das Skript extrahiert aus der Datei, konvertiert Typen und lädt die Zieltabellen.

# migrate_data.py — Lade CSV mit Transformation in PostgreSQL
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("Datenmigration abgeschlossen")