„Die Daten übernehmen wir einfach" gehört zu den teuersten Sätzen einer ERP-Migration. Zwischen Alt- und Zielsystem liegt kein Export-Knopf, sondern ein Mapping: Jedes Quellfeld braucht ein Zielfeld, eine Transformationsregel oder eine begründete Entscheidung, es nicht mitzunehmen. Warum unterschätzte Datenmigration Projekte kippt, zeigt der Blick auf die fünf häufigsten Migrationsfehler.
Das Mapping baut auf dem Befund der Discovery auf. Daten-Mapping ist seit Jahren Kernaufgabe meiner Integrationsarbeit, von DATEV- bis Salesforce-Schnittstellen, dokumentiert in den Fallstudien.
Feld für Feld, mit Prüfregeln
Das Mapping-Dokument hält pro Feld fest: Quelle, Ziel, Transformationsregel, Sonderfälle, Verantwortliche. Parallel entstehen die Prüfregeln, die festlegen, was als korrekt migriert gilt: Summen und Salden, Datensatz-Zahlen, definierte Stichproben in kritischen Beständen. Ohne diese Regeln bleibt „Migration erfolgreich" eine Behauptung.
Testläufe gegen Echtdaten
Validiert wird nicht am Reißbrett, sondern in Testläufen mit echten Quelldaten in einer produktionsnahen Umgebung. Jeder Lauf produziert Findings, die das Mapping korrigieren; der nächste Lauf zeigt, ob die Korrektur trägt. Ein Akzeptanztest der Key-User ersetzt diese Systemtests nicht; beides ist nötig. Bei einer M&A-Integration gingen mehrere vollständige Testläufe dem Cut-Over an einem Wochenende voraus; bei einem Pharma-Mittelständler (250 Mitarbeiter) stand die Datenqualitätsprüfung vor dem termingerechten 2-Wellen-Go-Live, mit dem drei Altsysteme auf ein SAP konsolidiert wurden.
Abnahme-Kriterien vor dem Go-Live
Vor dem Go-Live steht die Acceptance-Liste: welche Bestände vollständig ankommen müssen, was bewusst aus dem Scope bleibt, wer die Abnahme erklärt. Diese Liste verhindert, dass die Diskussion über Vollständigkeit erst nach dem Go-Live geführt wird. Und sie ist die Voraussetzung dafür, dass ein Cut-Over kalkulierbar wird.