Datenübernahme durchführen und validieren

Die Planung der Datenübernahme ist abgeschlossen: Quellen identifiziert, Mapping fertig, Strategie gewählt, Generalprobe gelaufen. Jetzt kommt der ernste Moment – die echte Migration in Produktion. Diese Lektion zeigt dir, wie ein professioneller Cutover-Plan aussieht, wie eine Migrations-Pipeline live aussieht und wie du nach der Migration mit verschiedenen Validierungstests sicherstellst, dass tatsächlich alles korrekt im Zielsystem angekommen ist. Denn: Eine Migration ohne Validierung ist keine Migration – es ist ein Sprung ins Dunkle.

1) Der Cutover-Plan – Stunde für Stunde

Eine produktive Migration läuft nach einem präzisen Zeitplan mit „T-Zeitpunkten" – relative Zeitangaben zum Cutover-Moment T0. Klick durch die typischen Phasen einer Wochenend-Migration:

2) Live-Pipeline – wie eine Migration in Echtzeit aussieht

Die eigentliche Migration läuft als Pipeline mit klaren Stages. Klick „Migration starten" und beobachte, wie sich die Pipeline durcharbeitet – inklusive Echtzeit-Log:

3) Validierungs-Tests – fünf Säulen

Nach dem Load läuft die Validierung. Sie ist nicht dasselbe wie „der Load hat funktioniert" – sondern: sind die Daten tatsächlich korrekt im Zielsystem angekommen? Fünf Test-Kategorien sind Standard:

4) Quarantäne-Datensätze – was tun mit dem Müll?

In praktisch jeder Migration gibt es Datensätze, die nicht migriert werden können: ungültige E-Mail-Formate, fehlende Pflichtfelder, korrupte Zeichensätze, logische Widersprüche. Diese landen in der Quarantäne. Optionen:

• Manuell aufbereiten und nachladen: Fachabteilung bekommt eine Liste, korrigiert die Einträge manuell, importiert sie separat. Aufwändig, aber wertvoll bei wichtigen Datensätzen.
• Verwerfen mit Dokumentation: Datensatz wird nicht migriert, aber dokumentiert (welcher Datensatz, warum nicht). Wichtig bei Audits und für die Nachvollziehbarkeit.
• Archivieren: Quellsystem-Snapshot wird aufbewahrt. Bei späteren Anfragen kann nachgeschaut werden.
• Mit Default-Werten füllen: Bei nicht-kritischen Pflichtfeldern: „Nicht angegeben" als Wert eintragen und Datensatz so migrieren. Kennzeichnung im Datensatz für späteres Nachpflegen.

Wichtig: Quarantäne-Liste muss zur Abnahme vorliegen. Der Auftraggeber muss entscheiden, was mit diesen Datensätzen passieren soll – das ist eine fachliche Entscheidung, nicht eine technische. Beim Audit später wird gefragt: „Wo sind die fehlenden 31 Kunden?" – und die Antwort muss da sein.

5) Rollback-Plan – wenn alles schief geht

Hoffentlich brauchst du ihn nie – aber er muss da sein: der Rollback-Plan. Voraussetzungen für einen funktionierenden Rollback:

• Vollständiges Backup vor T0: Datenbank-Dump, Konfigurationen, Dateien. Restore-Zeit gemessen (nicht geschätzt – getestet!).
• Klare Rollback-Trigger: Bei welchen Symptomen wird Rollback eingeleitet? „> 5 % Datenverluste", „Kritische Funktion arbeitet nicht", „Performance < 25 % der Anforderung". Schwarz auf weiß im Cutover-Dokument.
• Point-of-no-Return: Ab wann ist Rollback nicht mehr möglich? Wenn das Zielsystem bereits 4 Stunden produktiv genutzt wurde, gibt es neue Daten dort, die im Altsystem nicht existieren – Rollback würde diese löschen. Klare Stunde definieren, nach der nur noch „nach vorne korrigieren" möglich ist.
• Kommunikation vorbereitet: Anwender-Information für den Rollback-Fall liegt fertig vor („Migration wurde wegen technischer Probleme verschoben, altes System weiter nutzen, neuer Termin folgt").
• Externe Schnittstellen: Bank, Behörden, Lieferanten ggf. nochmal informieren, dass die neue Anbindung nicht aktiv ist.

Wichtige psychologische Disziplin: Den Rollback-Knopf zu drücken, fühlt sich wie ein Eingeständnis von Versagen an. Es ist aber das Gegenteil – es ist professionelles Risikomanagement. Wer mit defekten Daten weiter live geht, schadet dem Unternehmen viel mehr. Mehr in Change Management.

6) Migration-Reports und Audit-Trail

Jede Migration produziert Berichte, die später als Beweis dienen. Wichtige Inhalte:

• Migrations-Report: Zeit, Beteiligte, Mengen (Anzahl migrierter Datensätze pro Tabelle), Quarantäne-Liste, Validierungsergebnisse.
• Audit-Trail: Vollständige Protokoll-Datei aller Aktionen mit Zeitstempel. Bei vielen Branchen Pflicht (Finanzwesen, Pharma, KRITIS).
• Diff-Report: Wo gibt es Abweichungen zwischen Source und Target? Erklärung pro Abweichung (Mapping bewusst geändert, Quarantäne, Rundung).
• Lessons Learned: Was lief gut, was lief schlecht? Was würden wir nächstes Mal anders machen?

Diese Dokumente werden mehrere Jahre aufbewahrt (oft 10 Jahre, je nach Aufbewahrungsfristen). Bei vertraglichen Streitigkeiten oder Audits sind sie der Beweis: „Wir haben die Migration korrekt durchgeführt." Mehr in Welche Doku für welchen Zweck?.

7) Hypercare – die erste Woche nach Live

Mit der erfolgreichen Migration ist das Projekt nicht beendet. Es folgt die Hypercare-Phase – 1 bis 4 Wochen verstärkter Support, in denen das Migrationsteam noch eingebunden ist. Charakteristika:

• Erweiterte Reaktionszeiten: Tickets werden in Minuten beantwortet, nicht in Stunden. Hotline 24/7 oder erweitert.
• Direkter Draht zum Migrationsteam: Tickets, die auf Datenprobleme deuten, gehen direkt an die Entwickler, nicht durch den normalen Support-Prozess.
• Tägliches Standup: Migrationsteam, Betrieb, Fachabteilung treffen sich täglich kurz: Was gab es heute? Welche Probleme? Welche Eskalation?
• Datenfix-Tickets: Anwender finden Daten-Inkonsistenzen, die in der Validierung übersehen wurden. Klare Prozess-Behandlung: ticketgenehmigt, gefixt, dokumentiert.
• Kontrolliertes Auslaufen: Nach 2-4 Wochen wird die Hypercare schrittweise reduziert. Übergabe ins normale Betriebs-Support-Modell. Mehr in Incident Management.

Eine gute Hypercare-Phase ist der Unterschied zwischen einem als „erfolgreich" wahrgenommenen Projekt und einem mit lautstarken Klagen. Wer hier spart, spart am falschen Ende.

Zusammenfassung

Die produktive Datenmigration folgt einem präzisen Cutover-Plan mit T-Zeitpunkten: T-7 Tage (Code Freeze), T-2 Tage (Generalprobe), T-1 Tag (Backup + Anwender-Info), T-2 h (War-Room), T0 (Cutover-Start), T+2 h (Daten geladen), T+4 h (Validierung), T+6 h (Go/No-Go), T+8 h (Anwender-Freigabe), T+1 Tag (erster Werktag). Migrations-Pipeline: Backup → Extract → Transform → Load → Validierung → Freigabe. Validierungs-Tests in fünf Säulen: Vollständigkeit (Counts), Konsistenz (Cross-References), Korrektheit (Stichproben, KPI-Vergleich), Performance (Last-Test), Referentielle Integrität (FK-Checks). Erfolgskriterien VOR der Migration definieren. Quarantäne-Datensätze: manuell aufbereiten / verwerfen+dokumentieren / archivieren / mit Defaults füllen – Auftraggeber entscheidet fachlich. Rollback-Plan: Backup, klare Trigger, Point-of-no-Return, vorbereitete Kommunikation. Rollback ist Risikomanagement, kein Versagen. Reporting: Migrations-Report, Audit-Trail, Diff-Report, Lessons Learned – jahrelang aufbewahren. Hypercare 1-4 Wochen nach Live: verstärkter Support, direkter Draht zu Entwicklern, tägliches Standup, kontrollierter Übergang in den normalen Betrieb.

Verwandte Lektionen: Datenübernahme planen · Rollout-Szenarien · Übergabe und Abnahme · und mehrWeitere relevante Lektionen3-2-1-Backup-RegelChange ManagementIncident ManagementTeststufen V-ModellCI/CD-Pipeline-AufbauRTO / RPODSB, VVT, DSFAProjektabschluss & Lessons Learned