Data Migration: Definition, Verfahren und Abgrenzung

Data Migration (Datenmigration) bezeichnet den einmaligen, geplanten Umzug von Datenbeständen aus einem Quellsystem (dem bisherigen System) in ein Zielsystem (dem neuen System), meist beim Wechsel der Plattform, der Anwendung oder der Datenablage (Storage). Der Begriff beschreibt ein zeitlich begrenztes Projekt mit klarem Anfang, klarem Ende und einem Cutover, dem Umschalttermin, an dem das neue System den Betrieb übernimmt.

Was ist Data Migration?

Data Migration ist ein projekthafter Datenumzug, der stattfindet, wenn ein Unternehmen die technische Grundlage wechselt. Typische Auslöser sind die Ablösung eines alten Data Warehouse (zentraler Datenspeicher für Auswertungen), der Wechsel vom eigenen Rechenzentrum (On-Premises, kurz On-Prem) in eine Cloud-Umgebung, die Einführung eines neuen ERP-Systems (Enterprise Resource Planning, also Software für Warenwirtschaft, Buchhaltung und Personal) oder ein Wechsel der reinen Datenablage (Storage). Am Anfang steht ein bestehender Datenbestand im Quellsystem und die Anforderung, diesen Bestand im Zielsystem lesbar, korrekt und nutzbar bereitzustellen. Am Ende steht der Cutover: das Zielsystem übernimmt den laufenden Betrieb, das Quellsystem wird auf Nur-Lesen (Read-Only) gestellt oder abgeschaltet.

Der Begriff bündelt vier Arten von Datenumzügen, die sich im technischen Umfang unterscheiden. Storage-Migration bewegt ausschließlich die Ablage (z. B. HDFS auf S3), Schema und Datenmodell bleiben unverändert. Datenbank-Migration überträgt Schema und Inhalte zwischen zwei Datenbank-Systemen (Oracle nach PostgreSQL, Teradata nach Databricks) und arbeitet oft mit Type-Casts und SQL-Dialekt-Anpassungen. Applikations-Migration umfasst zusätzlich Datenmodell- und Semantikanpassungen, etwa beim Wechsel auf ein neues ERP. Cloud-Migration verschiebt Ablage und Compute in eine Cloud-Umgebung, oft in Verbindung mit einem Architekturwechsel (Warehouse zu Lakehouse, Batch zu Streaming).

Historisch prägte Data Migration die frühe ETL-Toolchain: Werkzeuge wie Informatica oder DataStage entstanden ursprünglich als Migrations-Werkzeuge für Data-Warehouse-Einführungen, bevor sie zum Standard für laufende Reporting-Beladungen wurden. Die Trennung zwischen Migration (einmalig) und Integration (laufend) hat sich erst mit dem Aufkommen kontinuierlicher Ingest- und CDC-Verfahren geschärft. Ein Migrationsprojekt folgt in der Regel den Phasen Assessment, Extraktion, Transformation und Mapping, Load, Validierung und Reconciliation, Cutover und Stilllegung des Altsystems. Zwei Vorgehensmuster sind gebräuchlich: Big-Bang-Migration mit einem einmaligen Cutover-Termin und Trickle-Migration mit Parallelbetrieb und inkrementellem Umzug in Wellen.

Abgrenzung: Integration, Replication, Modernization, Ingestion

Data Migration wird häufig mit benachbarten Begriffen aus der Data-Movement-Familie verwechselt. Die folgende Tabelle sortiert die Unterschiede entlang der Frage, ob ein Vorgang einmalig oder fortlaufend ist und ob das Zielsystem selbst neu ist.

Begriff	Zeithorizont	Zielsystem	Kernunterschied
Data Migration	Einmalig, projekthaft	Neu (Systemwechsel)	Definierter Anfang, Cutover, Ende. Nach Freigabe wird das Quellsystem stillgelegt.
Data Integration	Fortlaufend	Bestehend	Oberbegriff für kontinuierliches Zusammenführen von Datenbeständen aus mehreren Quellen in eine bestehende Plattform.
Data Replication	Kontinuierlich	Bestehend (Kopie)	Laufende, kopierende Übertragung zwischen zwei aktiven Systemen (z. B. für Hochverfügbarkeit, Reporting-Offload). Kann als Werkzeug innerhalb einer Migration eingesetzt werden.
Data Modernization	Programm	Neu (übergreifend)	Übergreifendes Vorhaben aus Plattform, Architektur, Governance und Betriebsmodell. Data Migration ist ein Teilprojekt darin.
Data Ingestion	Operativ	Bestehend	Extract-und-Load-Muster in eine bestehende Plattform ohne Systemwechsel. Teil der laufenden Integration.

Die zentrale Trennlinie verläuft zwischen einmalig-projekthaft (Migration, Modernization) und kontinuierlich-operativ (Integration, Replication, Ingestion). Eine Migration endet mit dem Cutover, ein Integrations- oder Ingest-Vorgang läuft danach weiter. Replication kann als technisches Werkzeug innerhalb einer Migrations-Phase eingesetzt werden (z. B. für den Parallelbetrieb in einer Trickle-Migration), bleibt begrifflich aber ein Betriebsmuster und beschreibt kein Projekt.

Beispiel: Teradata zu Lakehouse

Ein Handelsunternehmen migriert historische Reporting-Daten aus einem On-Prem-Teradata-Warehouse in ein Databricks Lakehouse. Umfang: 40 TB Rohdaten, 120 kuratierte Tabellen, acht Jahre Historie, 60 nachgelagerte Reports.

Das Projekt läuft in fünf Phasen. Im Assessment werden Quellschema, Datenvolumen, Datenqualität und Reporting-Abhängigkeiten erfasst; das Ergebnis ist eine Migrations-Landkarte mit priorisierten Tabellen und Ziel-Layout im Medaillon-Modell. Die Extraktion erfolgt per Bulk-Export in Parquet-Files auf S3, ergänzt durch einen kurzlaufenden CDC-Feed für die letzten Tage vor dem Cutover. Im Transformationsschritt übernehmen Delta-Live-Tables die Type-Casts, die SQL-Dialekt-Anpassung und die Zusammenführung in Bronze- und Silver-Tabellen. Die Validierung vergleicht Aggregate zwischen Quell- und Zielsystem (Row-Counts, Summen, Verteilungen) und dokumentiert Abweichungen. Nach Freigabe der Reporting-Konsistenz erfolgt der Cutover in einem 48-Stunden-Fenster; die Reports werden umgehängt, der Teradata-Bestand geht in einen Read-Only-Modus und wird nach sechs Monaten stillgelegt.

Was danach folgt, gehört nicht mehr zum Migrations-Scope: der laufende Ingest neuer Daten aus operativen Systemen ist Data Integration und läuft über Lakeflow Connect und CDC-Strecken. Diese Trennung ist wichtig, weil sie Verantwortlichkeiten, Werkzeuge und Betriebsverträge klar zuordnet.