Manche Dienstleister machen eine Testmigration kurz vor Go-Live. Das ist zu wenig — und erklärt, warum viele Migrationen mit Überraschungen enden.
Datenmigration klingt technisch, ist aber im Kern eine einfache Aufgabe: Daten aus System A in System B übertragen, dabei kein einziges Byte verlieren und alles korrekt transformieren. Das Problem ist, dass diese "einfache Aufgabe" in der Praxis voller Überraschungen steckt — und die meisten davon erst beim Testen sichtbar werden.
Beim ersten Testlauf geht immer etwas schief. Das ist keine Aussage über schlechte Arbeit — es ist eine Aussage über die Realität von Datenbeständen, die über Jahre gewachsen sind.
Typische Befunde beim ersten Testlauf:
Keines dieser Probleme ist katastrophal. Aber jedes muss gelöst werden, bevor der nächste Testlauf stattfindet. Und dafür braucht man Zeit.
Wer kurz vor Go-Live einen einzigen Testlauf macht, stellt fest, was schiefgeht — hat aber keine Zeit mehr, es gründlich zu beheben. Der Zeitdruck ist hoch, Korrekturen werden hastig umgesetzt, und beim Cutover stellt sich heraus, dass ein Problem behoben wurde, aber zwei neue entstanden sind.
Mindestens drei Testläufe sind notwendig, bevor ein Migrationsprojekt go-live-fähig ist:
Erster Testlauf: 10–20 % der Datenmenge. Ziel ist, die grundsätzliche Funktionsfähigkeit der Migrationsskripte zu prüfen. Hier werden strukturelle Probleme sichtbar — fehlende Felder, falsche Transformationen, technische Fehler in den Scripts.
Zweiter Testlauf: Vollständige Datenmenge. Jetzt zeigt sich, was mit der vollen Last passiert. Laufzeiten, Performance-Probleme, Mengenprobleme, die beim kleinen Testlauf nicht aufgefallen sind. Außerdem: Fachliche Prüfung durch den Kunden. Stimmen die Stammdaten? Sind alle Bewegungsdaten vollständig?
Generalprobe: Vollständige Datenmenge, aktueller Datenabzug. Die Generalprobe findet kurz vor dem tatsächlichen Cutover statt — mit einem frischen Datenabzug, der den aktuellen Systemstand abbildet. Ziel ist, den Cutover-Ablauf so realitätsnah wie möglich durchzuspielen, inklusive Zeitmessung.
Bei Bewegungsdaten — Rechnungen, Aufträge, Bestände, offene Posten — reicht es nicht, nur zu prüfen, ob Datensätze vorhanden sind. Es muss geprüft werden, ob die Summen stimmen.
Das bedeutet: Kontrollsummen aus dem Altsystem und aus dem Testsystem vergleichen. Gesamtumsatz, Lagerbestand in Stück und Wert, offene Posten — all das muss auf den Cent genau übereinstimmen. Erst wenn die Summenabstimmung bestanden ist, ist ein Testlauf fachlich abgenommen.
Wenn ein Dienstleister keine Summenabstimmung anbietet, ist das ein Warnsignal.
Jede Migration braucht einen Rollback-Plan: Was passiert, wenn nach dem Cutover ernsthafte Probleme auftreten? Ab wann ist ein Rollback noch möglich? Wer entscheidet darüber?
Dieser Plan muss vor dem Cutover fertig und vom Kunden akzeptiert sein — nicht danach. Und er ist nur glaubwürdig, wenn die Testmigrationen gezeigt haben, dass die Migration unter Kontrolle ist. Wer keine Testmigrationen durchgeführt hat, hat auch keine realistische Einschätzung, wie lange ein Rollback dauern würde.
Drei Testläufe plus Summenabstimmung plus fachliche Prüfung durch den Kunden — das braucht Zeit. In einem realistischen Migrationsprojekt sind für die Testphasen mindestens vier bis sechs Wochen einzuplanen, je nach Datenmenge und Komplexität.
Wer Migrationen in zwei Wochen verspricht, plant entweder ohne Testläufe oder ohne fachliche Abnahme. Beides ist ein Risiko, das der Kunde trägt — nicht der Dienstleister.
Wir führen mindestens drei Testläufe durch — mit Summenabstimmung, Rollback-Plan und schriftlicher Abnahme.