Auf einen Blick
Datenmigration ist der am häufigsten unterschätzte Risikofaktor bei Systemwechseln. Die Migration kostet typisch 20–30 % des Gesamtbudgets und verursacht mehr Go-Live-Verzögerungen als technische Systemprobleme. Ein strukturiertes Vorgehen in 4 Phasen (Analyse, Mapping, Testmigration, Cutover) vermeidet den Daten-GAU.
4 Phasen einer erfolgreichen Migration
1. Analyse: Was haben Sie eigentlich an Daten?
Bevor Sie migrieren, müssen Sie wissen, was da ist – und was davon überhaupt mitgenommen werden soll. Viele Projekte scheitern, weil sie versuchen, Datenchaos 1:1 in ein neues System zu kopieren.
- Datenobjekte inventarisieren (Kunden, Artikel, Lieferanten, Preise, Belege, etc.)
- Datenqualität bewerten: Vollständigkeit, Aktualität, Duplikate, Konsistenz
- Entscheidung: Was wird migriert, was archiviert, was bereinigt?
- Leading System je Datenobjekt definieren (Golden Source)
- Alles migrieren, weil 'man ja nie weiß'
- Datenqualität erst im neuen System klären wollen
2. Mapping: Altes Modell → Neues Modell
Datenmodelle unterscheiden sich fast immer. Felder heißen anders, Strukturen sind verschachtelt, Geschäftslogik steckt in Freitextfeldern. Das Mapping ist der technisch anspruchsvollste Teil.
- Feld-für-Feld Mapping (Quelle → Ziel) inkl. Transformationsregeln
- Umgang mit Daten, die im neuen Modell keinen Platz haben
- Behandlung von Pflichtfeldern, die in der Quelle leer sind
- Lookup-Tabellen für Code-Umschlüsselung (z. B. alte Länder-Codes → ISO)
- Mapping in Excel ohne Validierung → Fehler bei der Umsetzung
- Freitextfelder mit versteckter Geschäftslogik ignorieren
3. Bereinigung: Qualität vor Quantität
Migration ist DIE Chance, Datenqualität zu verbessern. Danach wird es deutlich aufwendiger. Planen Sie bewusst eine Bereinigungsphase ein.
- Deduplizierung (Golden Record je Entität)
- Pflichtfelder befüllen oder Datensätze ausschließen
- Format-Normalisierung (Adressen, Telefonnummern, Artikelnummern)
- Validierungsregeln definieren und automatisiert prüfen
- Bereinigung dem Fachbereich ohne Tooling aufbürden
- Zu hoher Anspruch ('alles perfekt') blockiert den Zeitplan
4. Test & Cutover: Der Moment der Wahrheit
Eine Migration ohne Testlauf ist russisches Roulette. Planen Sie mindestens 2–3 Probeläufe ein – mit echten Daten, echten Validierungen und echten Anwendern.
- Testmigration mit Subset (z. B. 10 % der Daten) + Vollmigration
- Abnahmekriterien: Anzahl Datensätze, Feldvollständigkeit, Referenzintegrität
- Cutover-Plan: Wann wird umgeschaltet? Wer validiert? Was ist der Rollback?
- Delta-Migration für Daten, die sich zwischen Test und Go-Live ändern
- Nur eine Testmigration und die 'passt schon'
- Kein Rollback-Plan (was, wenn es schiefgeht?)
Migrationsstrategien im Vergleich
Big Bang
Alle Daten werden zum Stichtag migriert. Schnell, aber risikoreich.
Wann: Kleine Datenmengen, einfache Modelle, klarer Cutover möglich.
Risiko: Kein Zurück – wenn etwas fehlt, wird es im Live-Betrieb sichtbar.
Phasenweise
Migration nach Entitäten, Standorten oder Geschäftsbereichen.
Wann: Große Organisationen, unterschiedliche Datenqualität je Bereich.
Risiko: Parallelbetrieb nötig, Referenzen zwischen migrierten und nicht-migrierten Daten.
Koexistenz / Dual-Write
Beide Systeme laufen parallel, Daten werden synchronisiert.
Wann: Schrittweise Ablösung, kritische Legacy-Systeme, die nicht sofort abgeschaltet werden können.
Risiko: Hohe Komplexität, Konflikte bei bidirektionaler Synchronisation.
ETL-Tools im Vergleich (für mittelständische Migrationen)
Welches Tool ist das richtige? Stark vereinfachte Heuristik: nach Datenvolumen, Komplexität und Skill-Profil im Team.
| Tool | Lizenz | Stärke | Schwäche | Wann sinnvoll |
|---|---|---|---|---|
| Talend Open Studio | Open Source | Konnektoren-Reichtum, sauberes Mapping-GUI | Performance bei großem Volumen | ERP-Migration mit vielen Quellsystemen |
| Pentaho Data Integration | Community Free | Stark in BI-orientierter Migration | Steile Lernkurve | BI-Migration, DWH-Aufbau parallel |
| Azure Data Factory | SaaS (verbrauchsbasiert) | Cloud-native, gut mit Azure-Stack | Vendor-Lock-In | Migration nach Dynamics 365 / Azure |
| n8n | Open Source / Cloud | Niedrigschwellig, viele Connectors | Nicht für >100GB Datenvolumen | Light-Migrationen, Real-time Sync |
| Fivetran | SaaS-Abo | Zero-Maintenance, prebuilt Connectors | Teurer bei großem Volumen | Data-Pipeline-as-a-Service |
| Custom Scripts (Python) | kostenlos | Maximale Kontrolle, kein Lock-In | Erfordert Engineering-Skill | Unique Transformationen, Compliance-pflichtig |
Cutover-Wochenplan: Beispiel ERP-Migration
Klassische 10-Tage-Sequenz vom Daten-Freeze bis zum produktiven Go-Live. Realistisch für mittelständische Projekte mit standardisierten Schnittstellen.
| Tag | Aktivität | Verantwortlich |
|---|---|---|
| D-3 (Mi) | Letzte Buchungen im Alt-System, Order-Stop | Fachbereich |
| D-2 (Do) | Daten-Export (Stamm + Bewegung) aus Alt-System | ETL-Team |
| D-1 (Fr) | Initialer Load ins Neu-System, Validierung | ETL-Team + IT |
| D-1 (Sa) | Delta-Load, Schnittstellen-Aktivierung, Smoke-Tests | IT |
| D-Day (So) | Final-Delta, Cutover-Go/No-Go-Meeting (16h) | Project Board |
| D+1 (Mo) | Produktiv-Start, Hypercare-Team im War-Room | Alle |
| D+2 (Di) | End-of-Day-Check: Buchungen sauber, KPIs i.O.? | Fachbereich + Controlling |
| D+5 (Fr) | Erste Woche Abschluss, Lessons-Learned-Workshop | Project Board |
Häufige Fragen
Weiterlesen — 3 Artikel
Vorbereitung
Anforderungskatalog erstellen
Bevor Sie migrieren: Alle Anforderungen an das Zielsystem strukturiert erfassen.
Zum Artikel →Methodik
Systemauswahl Methodik
Bewährter Auswahlprozess für das richtige System – bevor die Migration beginnt.
Zum Artikel →ERP
ERP-Einführung planen
Projektplan, Phasen und Meilensteine für eine erfolgreiche ERP-Implementierung.
Zum Artikel →