Wann sollte die Datenmigration beim ERP-Wechsel beginnen? Die kurze Antwort lautet: früher als die technische Übernahme, aber nicht mit allen Arbeiten gleichzeitig. Die Quellsysteme, der benötigte Datenumfang und erkennbare Datenrisiken können bereits untersucht werden, während das neue ERP-System noch konfiguriert wird. Das Mapping beginnt, sobald Zielprozesse, Datenobjekte und der vorgesehene Importweg ausreichend konkret beschrieben sind. Für den ersten Testlauf braucht es anschließend einen nachvollziehbaren Mappingstand, eine nutzbare Testumgebung und eine klare Prüffrage.
Auf das vollständig fertig eingerichtete Zielsystem zu warten, wäre deshalb meistens zu spät. Ebenso wenig hilft es, schon zu Projektbeginn jede Feldzuordnung als endgültig festzuschreiben. Der richtige Zeitpunkt entsteht für jeden Arbeitsschritt dann, wenn seine Grundlage belastbar genug ist und noch offene Annahmen sichtbar bleiben.
Der richtige Zeitpunkt ist kein einzelner Termin
In vielen Projektplänen erscheint die Datenmigration als ein Arbeitspaket, das irgendwann zwischen Konfiguration und Go-live beginnt. Fachlich besteht sie jedoch aus mehreren aufeinander aufbauenden Arbeiten. Jede davon hat eine andere Startvoraussetzung:
| Arbeit | Sie kann beginnen, wenn … | Noch nicht endgültig sein muss … |
|---|---|---|
| Quellen und Datenumfang untersuchen | die relevanten Altsysteme zugänglich sind und der voraussichtlich benötigte Datenumfang eingegrenzt werden kann. | die vollständige Konfiguration des neuen ERP-Systems. |
| Mapping und Transformation vorbereiten | der fachliche Zweck des Zielobjekts, der aktuelle Importweg sowie bekannte Schlüssel und Pflichtangaben beschrieben sind. | jede Werteliste, Sonderregel und optionale Zielangabe. |
| Eine erste Testmigration durchführen | eine nutzbare Testumgebung, eine versionierte Importstruktur, ein prüfbarer Mappingstand und eine konkrete Testfrage vorliegen. | der vollständige Datenbestand oder die Freigabe für den Go-live. |
Die bessere Projektfrage lautet daher nicht: „Hat die Datenmigration schon begonnen?“ Entscheidend ist vielmehr: „Welche Migrationsarbeit kann auf dem heutigen Kenntnisstand sinnvoll beginnen – und welche Entscheidung fehlt für den nächsten Schritt?“
Die Quellanalyse sollte früh im ERP-Projekt beginnen
Sobald der ERP-Wechsel beschlossen ist, kann das Projekt die vorhandenen Datenquellen untersuchen. Dafür muss das neue System noch nicht vollständig eingerichtet sein. Benötigt werden zunächst Zugänge zu den relevanten Datenbeständen, Ansprechpartner für ihre fachliche Bedeutung und eine erste Abgrenzung der Daten, die im neuen System voraussichtlich weitergeführt werden sollen.
In dieser frühen Untersuchung wird beispielsweise sichtbar, in welchen Systemen Kunden, Lieferanten, Materialien, offene Vorgänge oder historische Informationen liegen. Ebenso zeigt sich, ob benötigte Beziehungen nur in der Datenbank, in ergänzenden Dateien oder im Wissen einzelner Mitarbeitender vorhanden sind. Solche Erkenntnisse beeinflussen Aufwand und Zeitplan unabhängig davon, wie das neue ERP später im Detail konfiguriert wird.
Der Datenumfang muss an dieser Stelle noch nicht für jedes Feld endgültig entschieden sein. Das Projekt sollte aber wissen, welche Datenobjekte geprüft werden müssen und wer über ihre spätere Übernahme entscheidet. Unser Beitrag zur Frage welche Daten beim ERP-Wechsel ins neue System gehören vertieft diese Abgrenzung.
Das Mapping beginnt mit einem verwendbaren Zielstand
Für das Mapping reicht die bloße Entscheidung für ein neues ERP-System nicht aus. Mapping bezeichnet hier die konkrete Zuordnung zwischen den Informationen des Altsystems und den dafür vorgesehenen Feldern und Strukturen im neuen System. Damit diese Zuordnung mehr als eine Vermutung ist, müssen der künftige fachliche Zweck des Datenobjekts und der aktuelle Importweg beschrieben sein.
Das Zielsystem muss dafür nicht fertig sein. Es braucht jedoch einen benannten Stand: die derzeit gültige Importstruktur, bekannte Schlüssel und Pflichtangaben, bereits bestätigte Wertelisten sowie einen Verantwortlichen für offene Zielsystemfragen. Auf dieser Grundlage können eindeutige Zuordnungen bereits ausgearbeitet und unsichere Regeln gezielt zur Entscheidung vorgelegt werden.
Eine noch nicht freigegebene Zuordnung ist dabei kein Qualitätsmangel. Sie wird problematisch, wenn sie in der Dokumentation genauso aussieht wie eine bestätigte Regel. Ein vorläufiges Mapping sollte deshalb erkennen lassen, auf welcher Zielversion es beruht, welche Quellbedeutung angenommen wurde, welche Entscheidung noch fehlt und wer sie treffen kann.
Angenommen, das neue ERP akzeptiert für ein Feld nur festgelegte Codes, während im Altsystem freie Bezeichnungen stehen. Die technische Wertübersetzung kann bereits vorbereitet werden. Solange die erlaubten Zielcodes noch nicht freigegeben sind, bleibt die konkrete Zuordnung jedoch vorläufig. So kann die Arbeit fortschreiten, ohne einen Zwischenstand zur endgültigen fachlichen Entscheidung zu erklären. Wie daraus ausführbare Regeln entstehen, beschreibt unser Artikel zum Datenmapping im ERP-Projekt.
Der erste Testlauf beginnt, sobald er eine konkrete Frage beantworten kann
Eine frühe Testmigration ist noch keine Generalprobe für den Go-live. Sie soll eine begrenzte Unsicherheit auflösen. Das Projekt kann damit zum Beispiel prüfen, ob der aktuelle Importweg technisch funktioniert, ob eine Beziehung im Altsystem richtig verstanden wurde oder ob ein transformierter Wert im neuen Prozess die erwartete Wirkung hat.
Dafür sind vier Grundlagen notwendig: eine nutzbare Testumgebung, eine eindeutig versionierte Importstruktur, ein dokumentierter Mapping- und Transformationsstand sowie eine Person, die das Ergebnis fachlich beurteilt. Der Datenbestand darf dagegen bewusst klein sein, sofern er die offene Frage sichtbar macht.
Ein früher Lauf ist deshalb nicht automatisch zu früh, nur weil sich das Zielsystem noch verändert. Zu früh wäre er, wenn weder klar ist, was geprüft werden soll, noch welche Version der Regeln verwendet wurde. Dann entsteht zwar eine Datei oder ein Importprotokoll, aber keine belastbare Erkenntnis für das Projekt. Welche Unsicherheiten weitere Läufe rechtfertigen, erläutert unser Beitrag über Testmigrationen im ERP-Projekt.
Warum das unfertige Zielsystem die Migration nicht vollständig blockiert
Konfiguration, fachliches Verständnis, Mapping und Datenprüfung entwickeln sich bei einer ERP-Einführung nicht sauber nacheinander. Eine neue Pflichtangabe kann die Datenaufbereitung verändern. Umgekehrt kann ein erster Import zeigen, dass zwei ähnlich bezeichnete Felder im alten und neuen System fachlich etwas anderes bedeuten.
Damit diese Wechselwirkungen nicht unkontrolliert bleiben, sollten drei Arbeiten parallel geführt und regelmäßig verbunden werden:
- Das Zielsystem liefert den aktuellen Prozess- und Konfigurationsstand, Importwege, Pflichtlogiken und Änderungen.
- Die Datenmigration untersucht die Quelldaten, entwickelt Zuordnungen und bereitet wiederholbare Exporte, Transformationen und Tests vor.
- Die fachlichen Entscheidungen klären offene Bedeutungen, Wertelisten, Ausnahmen und Freigaben mit benannten Verantwortlichen.
Diese drei Bereiche dürfen unterschiedlich weit sein. Sie müssen aber an konkreten Punkten zusammenkommen. Nach einer relevanten Zieländerung wird geprüft, welche Mapping-Regeln, Transformationen und bisherigen Testergebnisse betroffen sind. Nach einer Testmigration fließt die fachliche Rückmeldung wiederum in die Zielkonfiguration oder die Migrationsregel zurück.
Eine kurze Wirkungskette macht die Folgen einer Änderung sichtbar:
Zieländerung → betroffene Mapping-Regel → technische Transformation → Ausgabedatei → erneut notwendige Prüfung.
Dafür ist kein schweres Änderungsmanagement erforderlich. Eine versionierte Liste mit Änderung, betroffenem Datenobjekt, Verantwortlichem und nächstem Prüfschritt kann ausreichen. Wichtig ist, dass ein früher erfolgreiches Testergebnis nicht ungeprüft weitergilt, wenn seine Grundlage verändert wurde.
Vollständiges Warten und vorschnelles Finalisieren lösen unterschiedliche Probleme – aber nicht dieses
Bis zu einem stabileren Zielstand zu warten, kann richtig sein, wenn weder der künftige Prozess noch ein verwendbarer Importweg beschrieben sind. Daraus folgt jedoch nicht, dass auch Quellen, Datenumfang und erkennbare Qualitätsrisiken unbearbeitet bleiben müssen. Vollständiges Warten verschiebt sonst Erkenntnisse, die das Projekt längst gewinnen könnte.
Umgekehrt kann ein früher Mappingvorschlag die Abstimmung erheblich beschleunigen. Er darf nur nicht als endgültige Vorgabe behandelt werden, solange fachliche Entscheidungen oder Zielinformationen fehlen. Das Problem ist daher weder ein grundsätzlich zu früher noch ein grundsätzlich zu später Start. Es entsteht, wenn das Projekt für alle Arbeiten denselben Startpunkt annimmt und den Status seiner Grundlagen nicht sichtbar macht.
So trifft die Projektleitung die Startentscheidung
Für jede anstehende Migrationsarbeit genügen drei Fragen:
- Welche konkrete Erkenntnis oder welches Ergebnis brauchen wir als Nächstes?
- Welche Quell- und Zielinformationen müssen dafür bereits bestätigt sein?
- Welche Annahmen dürfen noch offen bleiben, wenn wir sie kennzeichnen und einer Entscheidung zuordnen?
Kann das Team diese Fragen für die Quellanalyse beantworten, sollte diese Arbeit beginnen. Sind Zielobjekt und Importweg verwendbar beschrieben, kann das Mapping folgen. Liegen zusätzlich ein prüfbarer Regelstand, eine Testumgebung und eine fachliche Prüffrage vor, ist der erste Datenlauf sinnvoll. Fehlt eine Voraussetzung, wartet das Projekt nicht pauschal auf „das fertige ERP“, sondern beschafft gezielt genau diese Grundlage.
Der ERP-Partner verantwortet dabei die Beschreibung und Funktionsfähigkeit des Zielsystems sowie den vereinbarten Importweg. Die Fachbereiche entscheiden über die Bedeutung der Daten im künftigen Prozess und geben fachliche Ergebnisse frei. Die ERP-Projektleitung steuert Termine und Abhängigkeiten. Wir können diese Beteiligten operativ verbinden, indem wir Quelldaten untersuchen, Mappingvorschläge vorbereiten, offene und bestätigte Regeln nachvollziehbar führen sowie Transformationen und frühe Datenläufe umsetzen.
Die Datenmigration beim ERP-Wechsel sollte somit nicht auf einen späten technischen Übernahmetermin reduziert werden. Sie beginnt mit der strukturierten Untersuchung der Quellen und wird schrittweise konkreter, sobald das Zielsystem belastbare Antworten liefert. Wie sich diese Startentscheidung in den vollständigen Ablauf bis zum Go-live einordnet, zeigt unser Fahrplan für die Datenmigration im ERP-Projekt.