Datenmigration im ERP-Projekt: Fahrplan in 7 Phasen bis zum Go-live

Ein Balken mit der Bezeichnung „Datenmigration“ steht in fast jedem ERP-Projektplan. Trotzdem bleibt oft offen, was bis zu diesem Termin tatsächlich fertig sein muss. In einem Plan meint der Eintrag nur die Zuordnung der Datenfelder, in einem anderen bereits einen vollständigen Lauf. Ob die Fachbereiche den geladenen Bestand im neuen System geprüft haben, ist daraus meist nicht erkennbar.

Diese Unschärfe wird spätestens vor dem Go-live teuer. Dann soll ein enger Zeitplan eingehalten werden, obwohl Datenumfang, Regeln oder Verantwortlichkeiten noch nicht stabil sind. Der produktive Lauf muss Probleme auffangen, die eigentlich in früheren Testmigrationen hätten sichtbar werden sollen.

Ein belastbares Datenmigration-Vorgehen verbindet deshalb Termine mit überprüfbaren Ergebnissen. Die folgenden sieben Phasen führen vom Migrationsauftrag bis zur Stabilisierung nach dem Go-live. Sie zeigen nicht nur, was zu tun ist, sondern auch, welches Ergebnis jeweils vorliegen muss, bevor der nächste Schritt sinnvoll beginnen kann.

Was ein Fahrplan zusätzlich zu einer Checkliste leistet

Eine Checkliste erinnert an einzelne Aufgaben. Ein Fahrplan ordnet diese Aufgaben so, dass daraus eine verlässliche Folge von Entscheidungen entsteht. Dafür braucht jede Phase vier Bestandteile:

• ein konkretes Ergebnis, beispielsweise einen bestätigten Datenumfang oder einen wiederholbaren Testlauf,
• benannte Personen, die Regeln entscheiden, technisch umsetzen und fachlich freigeben,
• sichtbare offene Punkte mit Verantwortlichem und Termin sowie
• eine klare Bedingung dafür, wann das Projekt mit der nächsten Phase weiterarbeiten kann.

Das bedeutet nicht, dass alle Phasen streng nacheinander abgeschlossen werden. Ein Testlauf kann eine fehlende Regel aufdecken und damit eine erneute fachliche Entscheidung auslösen. Der Fahrplan sorgt jedoch dafür, dass solche Schleifen gezielt zum richtigen Schritt zurückführen, statt als ungeplante Nacharbeit im Projekt zu verschwinden.

Das Datenmigration-Vorgehen in sieben Phasen

Phase 1: Auftrag, Ziel und Verantwortlichkeiten klären

Zu Beginn wird die Datenmigration als eigener Verantwortungsbereich innerhalb des ERP-Projekts abgegrenzt. Das Gesamtprojekt kümmert sich zusätzlich um Prozesse, Konfiguration, Schnittstellen, Schulungen und die organisatorische Umstellung. Der Migrationsfahrplan konzentriert sich darauf, die vereinbarten Datenbestände kontrolliert in das neue System zu überführen.

Dafür muss noch kein vollständiges Feldmapping vorliegen. Zunächst genügt ein kompakter Migrationsauftrag, der die beteiligten Quell- und Zielsysteme, die betroffenen Gesellschaften oder Standorte und die wichtigsten Leistungsgrenzen festhält. Ebenso wichtig ist die Rollenverteilung: Der Auftrag benennt die operative Leitung der Datenmigration, die fachlichen Entscheider, die Verantwortlichen für die Anforderungen des Zielsystems und die Personen, die einen Test oder den produktiven Datenbestand freigeben dürfen.

Gerade die Abgrenzung zwischen internem Team, ERP-Partner und einem möglichen Datenmigration-Dienstleister sollte jetzt schriftlich feststehen. Sonst kann jede Partei ihre eigenen Aufgaben erfüllen, während verbindende Arbeiten wie Fehlerklärung, Teststeuerung oder Freigabevorbereitung ohne Eigentümer bleiben.

Die erste Phase ist abgeschlossen, sobald Projektleitung und fachlich Verantwortliche denselben Auftrag bestätigen: Ziel, grober Datenrahmen, Rollen, ausgeschlossene Leistungen und erste Erfolgskriterien sind verständlich dokumentiert. Welche weiteren Entscheidungen daraus folgen, lässt sich in einem Datenmigrationskonzept für das ERP-Projekt vertiefen.

Phase 2: Datenbestände erfassen und den Umfang festlegen

Nun wird aus dem groben Rahmen ein belastbarer Scope – also der vereinbarte Umfang der Datenmigration. Dieser Umfang sollte nicht nur aus Tabellen oder Dateinamen bestehen. Entscheidend ist die fachliche Sicht auf Datenobjekte. Ein Datenobjekt bündelt zusammengehörige Informationen, zum Beispiel einen Kunden mit Adressen und Ansprechpartnern oder ein Material mit seinen Einheiten und Merkmalen.

Für jedes relevante Datenobjekt wird festgelegt, aus welcher Quelle es stammt, wofür es im neuen System benötigt wird und wer fachlich dafür verantwortlich ist. Anschließend entscheidet das Projekt bewusst, welche Bestände vollständig übernommen, auf aktive Datensätze begrenzt, vorab bereinigt, nur als Historie bereitgehalten oder begründet ausgeschlossen werden.

Die Ausschlüsse sind ebenso wichtig wie die gewünschten Daten. Werden etwa alte Bewegungsdaten, zusätzliche Vorsysteme oder weitere Organisationseinheiten nur stillschweigend offengelassen, wächst der Umfang häufig erst während der Umsetzung. Dadurch verändern sich Aufwand und Termin, ohne dass das Projekt eine bewusste Entscheidung getroffen hat.

Das Ergebnis ist ein priorisiertes Datenobjektregister mit Quellen, einbezogenen und ausgeschlossenen Beständen, Verantwortlichen und Abhängigkeiten. Erst wenn jedes priorisierte Objekt einen nachvollziehbaren Zweck und einen fachlichen Eigentümer hat, ist die Grundlage für Mapping und Umsetzung tragfähig. Eine ausführlichere Entscheidungshilfe bietet unser Beitrag dazu, welche Daten beim ERP-Wechsel ins neue System gehören.

Phase 3: Zielanforderungen, Mapping und Regeln festlegen

In der dritten Phase wird geklärt, wie die Bedeutung aus dem Altsystem in die Struktur des neuen ERP übersetzt wird. Das Mapping ordnet Quell- und Zielfelder einander zu. Zusätzlich braucht die Migration Regeln für Formate, Schlüssel, Pflichtfelder, Wertelisten, Beziehungen, Bereinigungen und Standardwerte.

Bei einem Kundenstamm reicht es beispielsweise nicht, die Felder „Kundengruppe alt“ und „Kundengruppe neu“ nebeneinanderzustellen. Das Projekt muss entscheiden, welcher alte Wert künftig welchem neuen Wert entspricht, was mit ungültigen Kombinationen geschieht und welche Zielkonfiguration vorhanden sein muss. Fehlt eine benötigte Information, braucht es ebenfalls eine fachliche Entscheidung: ergänzen, aus einer anderen Quelle ableiten, durch einen vereinbarten Wert ersetzen oder den Datensatz ausschließen.

Ein Migrationsspezialist kann diese Fragen anhand der Daten vorbereiten, Auswirkungen sichtbar machen und die beschlossenen Regeln technisch umsetzen. Die fachliche Bedeutung darf er jedoch nicht stellvertretend erfinden. Deshalb erhält jede offene Regel einen benannten Entscheider und einen dokumentierten Status.

Für den ersten Test müssen nicht sämtliche Datenobjekte vollständig bearbeitet sein. Sinnvoller ist ein freigegebener Regelstand für ein repräsentatives Objekt, an dem sich die gesamte Kette prüfen lässt. Weiter geht es, sobald Quelllogik, Zielanforderungen und fachliche Regeln für diesen Testumfang ausreichend geklärt und versioniert sind.

Phase 4: Einen wiederholbaren Migrationslauf aufbauen

Aus den vereinbarten Regeln entsteht nun ein ausführbarer Ablauf: Daten auslesen, nach den beschlossenen Regeln verändern, für das Zielsystem bereitstellen, laden und das Ergebnis protokollieren. Welches Werkzeug dabei eingesetzt wird, hängt von der Systemlandschaft ab. Entscheidend ist, dass der Lauf nachvollziehbar wiederholt werden kann.

Eine manuell korrigierte Importdatei, die einmal erfolgreich geladen wurde, ist noch kein stabiler Prozess. Wenn etwa ein ungültiger Wert auffällt, muss die Ursache an der richtigen Stelle behoben werden: in den Quelldaten, in einer fachlichen Regel, in der Transformation oder in der Zielkonfiguration. Nur dann erzeugt der nächste Lauf denselben korrigierten Stand ohne erneute Handarbeit.

Das erste Datenobjekt sollte überschaubar sein, aber echte Unsicherheiten enthalten. Ein technisch einfacher Export ohne Beziehungen oder Pflichtfelder liefert zwar schnell ein Erfolgserlebnis, prüft aber kaum, ob die gewählte Methode das Gesamtprojekt trägt. Besser ist ein Objekt, an dem Datenzugriff, Mapping, Transformation, Import und fachliche Kontrolle gemeinsam erprobt werden.

Am Ende steht ein dokumentierter Pilotlauf mit eindeutigem Regelstand, Eingabedaten, Laufprotokoll und einer nach Ursachen gegliederten Fehlerliste. Bevor dieser Test beginnt, hilft die Checkliste für den ersten ERP-Migrationstest, fehlende Voraussetzungen früh zu erkennen.

Phase 5: Testmigrationen fachlich prüfen und gezielt verbessern

„Import erfolgreich“ bedeutet zunächst nur, dass das Zielsystem die gelieferten Daten technisch angenommen hat. Für eine belastbare Freigabe muss das Projekt zusätzlich prüfen, ob die Daten vollständig, richtig umgewandelt und im neuen System fachlich nutzbar sind.

Dafür werden vier Prüfebenen voneinander getrennt:

• Technische Vollständigkeit: Abgleich von Mengen, Schlüsseln, Pflichtfeldern und Beziehungen.
• Umsetzung der Regeln: Nachweis, dass die vereinbarten Zuordnungen und Veränderungen korrekt angewendet wurden.
• Fachliche Richtigkeit: Bewertung der erwarteten Werte und Zusammenhänge durch die Keyuser im Zielsystem.
• Nutzbarkeit im Prozess: Erprobung ausgewählter kritischer Geschäftsvorgänge mit den migrierten Daten.

Die Kriterien werden vor dem jeweiligen Lauf festgelegt. Je nach Datenobjekt können Mengen- und Summenabgleiche, Pflichtfeldkontrollen, Stichproben oder konkrete Geschäftsszenarien sinnvoll sein. Dadurch müssen Keyuser nicht in ungefilterten Fehlerlisten nach Problemen suchen, sondern können vorbereitete Ergebnisse gezielt fachlich bewerten.

Jeder Befund führt anschließend zur richtigen Ursache zurück. Ein Quelldatenproblem wird anders behoben als eine ungeklärte Fachregel, ein Transformationsfehler, eine Schnittstellenanforderung oder eine Einstellung im Zielsystem. Danach folgt ein neuer Lauf mit aktualisiertem Regelstand. Die Phase ist nicht beendet, weil eine Fehlerliste kürzer geworden ist, sondern weil die vereinbarten Kriterien erfüllt oder verbleibende Abweichungen ausdrücklich bewertet und akzeptiert wurden.

Phase 6: Den Cut-over aus erprobten Läufen entwickeln

Der Cut-over rund um den Go-live wird nicht erst kurz vor der Produktivsetzung geplant. Seine belastbaren Angaben entstehen bereits in den Testmigrationen. Dort werden die Zeiten für Auslesen, Transformation, Laden und Prüfung gemessen. Zugleich werden Abhängigkeiten zwischen den Datenobjekten, benötigte Personen und der verfügbare Spielraum für Korrektur oder Wiederanlauf sichtbar.

Aus diesen Messwerten entsteht ein detaillierter Ablauf mit:

• Reihenfolge und Zeitfenster der Aufgaben,
• verantwortlicher Person und Vertretung,
• benötigten Zugängen, Werkzeugen und Eingabedaten,
• Datenstopp sowie Voll- und gegebenenfalls Deltaläufen,
• Prüfung und Freigabe nach kritischen Schritten,
• Go-/No-go-Kriterien, Kommunikation und Eskalation sowie
• einem Vorgehen für Rückfall oder Wiederanlauf.

Dieser Ablauf wird anschließend unter möglichst realistischen Bedingungen geprobt. Der offizielle Cut-over-Leitfaden von Microsoft empfiehlt ebenfalls, Aufgaben, Verantwortliche, Prüf- und Freigabeschritte sowie einen Rückfallplan festzuhalten und den Ablauf vor dem produktiven Start im Testsystem einzuüben.

Die Generalprobe ist deshalb kein symbolischer Termin. Sie zeigt, ob das verfügbare Zeitfenster ausreicht, ob Verantwortlichkeiten kollidieren und ob die vorgesehenen Prüfungen in der Praxis durchführbar sind. Wie daraus ein vollständiger Ablauf entsteht, erläutert unser Beitrag zum ERP-Cut-over-Plan für die Datenmigration.

Phase 7: Produktiv migrieren, freigeben und stabilisieren

Im produktiven Lauf wird der geprobte Ablauf ausgeführt und protokolliert. Treten Abweichungen auf, werden sie sofort gegen die vereinbarten Kriterien bewertet. Nach dem Laden folgen dieselben technischen und fachlichen Kontrollen wie in den Tests – diesmal mit dem produktiven Datenbestand.

Mit dem Go-live ist die Datenmigration noch nicht vollständig abgeschlossen. Manche Befunde zeigen sich erst im Tagesgeschäft. Deshalb benötigt die Stabilisierungsphase einen klaren Bearbeitungsweg: Auswirkung und Priorität des Problems, verantwortliche Person, vorgesehene Korrektur und anschließende Prüfung.

Gleichzeitig werden Regeln, Skripte, Laufprotokolle, Freigaben und bekannte Ausnahmen so übergeben, dass sie auch nach dem Projekt verständlich bleiben. Abgeschlossen ist die Phase, wenn geschäftskritische Daten und Prozesse aus Datensicht freigegeben sind und jeder verbleibende Punkt einen verbindlichen Bearbeitungsweg besitzt.

Warum einzelne Phasen mehrmals durchlaufen werden

Die sieben Phasen beschreiben eine logische Reihenfolge, aber keinen starren Wasserfall. Der erste reale Test zeigt häufig neue Pflichtfelder, fehlende Zielwerte oder unklare Beziehungen. Dann führt der Befund gezielt zu der Stelle zurück, an der seine Ursache liegt:

• Ein zusätzlich benötigtes Datenobjekt verändert den vereinbarten Umfang aus Phase 2.
• Eine neue fachliche Entscheidung erhält einen aktualisierten Regelstand in Phase 3.
• Eine technische Korrektur fließt reproduzierbar in den Ablauf aus Phase 4 ein.
• Die Wirkung wird anhand der Kriterien aus Phase 5 erneut geprüft.
• Veränderte Laufzeiten oder Abhängigkeiten aktualisieren den Cut-over aus Phase 6.

Damit bleiben Wiederholungen erwünscht, ohne unkontrolliert zu werden. Fortschritt zeigt sich nicht daran, dass keine Fehler mehr auftreten. Er zeigt sich daran, dass Ursachen schneller eingeordnet werden, behobene Fehler nicht wiederkehren und Freigaben auf immer belastbareren Nachweisen beruhen.

Welche Unterlagen den Fahrplan zusammenhalten

Für die Steuerung braucht ein mittelständisches ERP-Projekt kein unübersichtliches Dokumentenarchiv. In vielen Vorhaben lassen sich die entscheidenden Informationen in sieben miteinander verknüpften Arbeitsständen führen:

1. Migrationsauftrag: Ziel, Rahmen, Rollen und Leistungsgrenzen.
2. Datenobjektregister: Quellen, Umfang, Ausschlüsse, Priorität, Verantwortliche und Abhängigkeiten.
3. Mapping- und Regelstand: Zuordnungen, Veränderungen und offene Fachentscheidungen.
4. Laufprotokoll: verwendete Daten, Regelversion, Verarbeitung, Ladeergebnis und Fehler.
5. Test- und Freigabestatus: Prüfkriterien, Befunde, Korrekturen und fachliche Bestätigungen.
6. Cut-over-Plan: Reihenfolge, Zeiten, Verantwortliche, Kontrollen, Go-/No-go und Rückfall.
7. Übergabe- und Befundregister: produktiver Status, bekannte Ausnahmen und offene Maßnahmen.

Wichtiger als das Dateiformat ist die Verbindung zwischen diesen Informationen. Ein Testfehler muss bis zum betroffenen Datenobjekt und zur angewendeten Regel zurückverfolgbar sein. Eine geänderte Regel muss im nächsten Lauf eine neue Version erzeugen. Und eine Freigabe muss erkennen lassen, auf welchem Teststand sie beruht.

Woran die Projektleitung echten Fortschritt erkennt

Eine Angabe wie „Datenmigration zu 80 Prozent fertig“ hilft wenig, wenn unklar bleibt, was in den restlichen 20 Prozent steckt. Aussagekräftiger sind konkrete Nachweise:

• Für die priorisierten Datenobjekte sind Umfang, Ausschlüsse und Verantwortliche entschieden.
• Mindestens ein relevantes Datenobjekt wurde ohne verdeckte Handarbeit wiederholt ins Zielsystem geladen.
• Offene Fachregeln werden sichtbar weniger oder gezielt an benannte Entscheider eskaliert.
• Bereits behobene Fehler kehren im nächsten Lauf nicht wieder.
• Technische Prüfung und fachliche Freigabe sind getrennt dokumentiert.
• Die Zeiten für Auslesen, Verarbeitung, Laden und Prüfung wurden gemessen.
• Der Cut-over übernimmt diese Erfahrungen, statt nur auf Schätzungen zu beruhen.

Diese Signale zeigen nicht bloß Aktivität. Sie zeigen, dass der Ablauf zunehmend beherrscht wird und Terminrisiken begründet bewertet werden können.

Wo ein laufendes Projekt in den Fahrplan einsteigen sollte

Ein bereits gestartetes Projekt muss den Fahrplan nicht künstlich von vorn durchlaufen. Sinnvoll ist der Einstieg bei der frühesten Phase, deren Ergebnis noch nicht belastbar vorliegt.

Fehlt ein bestätigter Datenumfang, wird ein weiterer Testlauf wahrscheinlich neue Grundsatzfragen erzeugen. Sind Umfang und Regeln entschieden, aber jede Importdatei entsteht durch manuelle Korrekturen, liegt der Engpass im technischen Ablauf. Ist die Migration wiederholbar, aber niemand kann die Daten fachlich freigeben, fehlen dagegen Prüfkriterien, vorbereitete Nachweise oder klare Verantwortlichkeiten.

So wird aus der pauschalen Aufgabe „Datenmigration weitermachen“ ein konkreter nächster Schritt: einen Datenbestand abgrenzen, eine Regel entscheiden, einen Lauf reproduzierbar machen oder einen geprobten Cut-over-Abschnitt absichern.

Externe Unterstützung ist besonders dann sinnvoll, wenn diese Verbindung zwischen internem Team und ERP-Partner offenbleibt. Ein Datenmigration-Dienstleister kann Scope, fachliche Entscheidungen, technische Umsetzung, Tests und Cut-over-Vorbereitung zusammenführen, ohne die Verantwortung der ERP-Projektleitung zu ersetzen. Für die Auswahl helfen unsere zwölf Fragen zum Vergleich von Datenmigration-Dienstleistern.