Der erste vollständige Migrationstest ist gelaufen. Einige Datensätze wurden abgewiesen, andere sind im Zielsystem angekommen, aber fachlich nicht verwendbar. Gleichzeitig wächst die Fehlerliste, während der nächste Testtermin bereits feststeht. Der naheliegende Auftrag lautet dann: Fehler korrigieren und den Lauf wiederholen.
Genau an dieser Stelle kann ein ERP-Projekt viel Zeit verlieren. Denn eine schnelle Korrektur hilft nur, wenn klar ist, was tatsächlich fehlgeschlagen ist und an welcher Stelle die Ursache dauerhaft behoben werden muss. Wird lediglich die fertige Importdatei repariert, sieht der nächste Lauf zunächst besser aus – beginnt mit neuen Quelldaten aber womöglich wieder von vorn.
Die Diagnose „ERP-Datenmigration fehlgeschlagen“ ist deshalb zu grob. Zuerst muss das Projekt den Teststand sichern, technische und fachliche Fehler voneinander trennen und jeden Befund der richtigen Ursache zuordnen. Erst danach lässt sich sinnvoll entscheiden, ob der gleiche Umfang wiederholt, der nächste Test verkleinert oder die Grundlage neu aufgebaut werden sollte.
Zuerst klären, was an der Testmigration gescheitert ist
Ein Migrationstest kann auf drei unterschiedliche Arten scheitern. Diese Unterscheidung ist wichtig, weil jede Variante eine andere Reaktion verlangt.
Der technische Import ist fehlgeschlagen
Das Zielsystem weist Datensätze ab oder beendet den Ladevorgang. Importprotokolle nennen beispielsweise ein ungültiges Format, einen nicht erlaubten Wert, ein fehlendes Pflichtfeld oder eine technische Abhängigkeit. Damit ist die erste Ursache noch nicht automatisch gefunden. Die Meldung beschreibt zunächst nur die Stelle, an der das Zielsystem die Verarbeitung beendet hat.
Ein fehlender Zielwert kann aus unvollständigen Quelldaten stammen, durch eine falsche Transformationsregel entstehen oder auf eine noch nicht eingerichtete Konfiguration im neuen ERP hinweisen. Wer jede Fehlermeldung ausschließlich im Importwerkzeug löst, vermischt diese Ursachen und erschwert den nächsten Lauf.
Der Import war erfolgreich, das Ergebnis ist aber fachlich unbrauchbar
Ein grüner Importstatus belegt, dass das Zielsystem die Daten nach seinen technischen Regeln angenommen hat. Er belegt noch nicht, dass der richtige Datenbestand geladen wurde, Werte fachlich korrekt zugeordnet sind oder die vorgesehenen Geschäftsprozesse funktionieren.
Fehlt beispielsweise ein benötigter Datensatz bereits im Export, kann das Zielsystem ihn nicht ablehnen. Ebenso kann ein technisch zulässiger Code fachlich falsch verwendet werden. Der Ladevorgang ist dann erfolgreich, während die Testmigration ihr eigentliches Ziel verfehlt. Diese Trennung zwischen technischem Import, fachlicher Prüfung und Freigabe haben wir auch in unserem Beitrag zur Vorbereitung des ersten ERP-Migrationstests beschrieben.
Der Test liefert keine belastbare Aussage
Die dritte Variante fällt weniger auf: Daten wurden geladen und geprüft, aber vor dem Lauf war nicht vereinbart, was der Test beweisen sollte. Ohne festgelegten Datenumfang, bekannte Eingabedaten und konkrete Prüfkriterien lässt sich hinterher nicht sauber beurteilen, ob das Ergebnis ausreichend ist.
In diesem Fall wäre es voreilig, sofort in die Fehlerkorrektur einzusteigen. Zunächst braucht der Test ein klares Ziel. Erst dann kann das Team zwischen einem echten Migrationsfehler, einer noch offenen Fachentscheidung und einer Erwartung unterscheiden, die gar nicht zum vereinbarten Testumfang gehörte.
Vor jeder Korrektur muss der genaue Teststand gesichert werden
Sobald mehrere Beteiligte parallel Fehler beheben, verändert sich der Ausgangsstand schnell. Eine Person passt die Importdatei an, eine andere ändert die Zielkonfiguration und der Fachbereich bereinigt einzelne Datensätze. Wenn anschließend niemand mehr sagen kann, welcher Stand getestet wurde, lässt sich weder die Ursache belegen noch die Wirkung einer Korrektur nachvollziehen.
Bevor die Bearbeitung beginnt, sollten deshalb fünf Bestandteile unverändert gesichert werden:
- Quelldatenstand: verwendeter Export, Zeitpunkt, Filter und einbezogene Organisationseinheiten.
- Regelstand: die tatsächlich verwendeten Mapping- und Transformationsregeln einschließlich ihrer Version.
- Technischer Lauf: Importdateien, Skripte, Laufparameter und vollständige Protokolle.
- Zielumgebung: Systemstand, relevante Konfiguration und verwendete Importstruktur.
- Prüfergebnis: vorgesehene Testfälle, beobachtete Abweichungen und bereits erteilte fachliche Rückmeldungen.
Diese Sicherung ist keine zusätzliche Dokumentationsübung. Sie schafft einen festen Vergleichspunkt. Nur wenn Eingang, Regeln und Zielumgebung bekannt sind, kann der nächste Lauf zeigen, ob eine Änderung den Fehler tatsächlich beseitigt hat.
Fünf Ursachenklassen bringen Ordnung in die Fehlerliste
Eine lange Fehlerliste wird häufig nach Personen, Datenobjekten oder Fehlermeldungen verteilt. Für eine nachhaltige Korrektur reicht das nicht. Zuerst sollte jeder Befund einer Ursachenklasse zugeordnet werden. Dadurch wird sichtbar, welche Entscheidung benötigt wird und an welcher Stelle die Änderung in den nächsten Lauf einfließen muss.
1. Umfang oder Datenauswahl
Benötigte Datensätze fehlen, weil ein Zeitraum, ein Status, eine Gesellschaft oder ein abhängiges Datenobjekt nicht einbezogen wurde. Umgekehrt können Datensätze enthalten sein, die laut vereinbartem Migrationsumfang gar nicht ins Zielsystem gehören.
Die Korrektur liegt dann nicht in einem einzelnen Zielfeld. Das Projekt muss den Datenumfang oder die Auswahlregel anpassen und festhalten, welche Bestände künftig ein- oder ausgeschlossen werden. Bleibt diese Entscheidung offen, erzeugt jeder neue Export eine andere Ausgangslage.
2. Qualität der Quelldaten
In den Ausgangsdaten fehlen Werte, Schlüssel sind nicht eindeutig oder zusammengehörige Datensätze widersprechen einander. Hier muss entschieden werden, ob der Fehler im Altsystem bereinigt, während der Transformation nachvollziehbar korrigiert oder als begründete Ausnahme behandelt wird.
Eine pauschale Datenbereinigung ist nicht immer die beste Antwort. Wenn das bisherige System weiterhin produktiv arbeitet, kann eine Korrektur an der Quelle sinnvoll sein. Ist die Änderung dort nicht mehr möglich oder wirtschaftlich, braucht die Migration eine dokumentierte Regel, die bei jedem Lauf dasselbe Ergebnis erzeugt.
3. Mapping oder Transformation
Die Quelldaten sind vorhanden, werden aber falsch in die Struktur oder Bedeutung des Zielsystems übersetzt. Das betrifft beispielsweise Wertzuordnungen, Standardwerte, Formate, Beziehungen oder die Ableitung eines Zielfelds aus mehreren Quellen.
Solche Befunde benötigen zwei Schritte: Der Fachbereich bestätigt die richtige Bedeutung, anschließend wird diese Entscheidung in der technischen Regel umgesetzt. Eine manuelle Änderung einzelner Datensätze behebt zwar das sichtbare Ergebnis, nicht aber die Regel, die es erzeugt hat.
4. Zielkonfiguration oder Importschnittstelle
Der Datenbestand kann fachlich richtig vorbereitet sein und trotzdem an einer fehlenden Zielvoraussetzung scheitern. Möglicherweise existiert ein benötigter Wert im neuen ERP noch nicht, eine Importstruktur erwartet eine andere Reihenfolge oder das Zielsystem prüft Beziehungen, die im Teststand noch nicht eingerichtet wurden.
Hier braucht es die Zielsystemkompetenz des ERP-Partners. Er muss klären, welche Konfiguration oder technische Voraussetzung fehlt. Die Migrationsseite liefert dagegen den reproduzierbaren Datenstand und zeigt, bei welchen Datensätzen die Anforderung wirksam wird.
5. Prüfung, Rollen oder Freigabe
Manche Probleme liegen weder in Quelle noch Ziel. Der Test stockt, weil Keyuser nur eine ungefilterte Fehlerliste erhalten, Prüfkriterien fehlen oder niemand über eine verbleibende Abweichung entscheiden darf. Dann erzeugt auch ein weiterer technisch verbesserter Lauf keine belastbare Freigabe.
Die Korrektur besteht in vorbereiteten Prüfungen, benannten Verantwortlichen und einer klaren Entscheidung über das Testergebnis. Microsoft empfiehlt für Testzyklen ebenfalls, Ziel, Umfang, Rollen und den Weg zur Bearbeitung gefundener Probleme vorab festzulegen und Befunde bis zur Lösung zentral zu verfolgen. Der entsprechende Leitfaden zur Testdurchführung unterscheidet zudem technische Fehler von Lücken, die erst fachlich bewertet und priorisiert werden müssen.
Eine Korrektur ist erst fertig, wenn sie den nächsten Lauf verbessert
Der entscheidende Qualitätsunterschied liegt nicht darin, wie schnell ein sichtbarer Fehler verschwindet. Entscheidend ist, ob seine Ursache beim nächsten Datenstand automatisch richtig behandelt wird. Dafür führen wir jeden relevanten Befund über eine nachvollziehbare Kette:
- Die Abweichung wird mit dem betroffenen Datenstand und Prüfergebnis festgehalten.
- Die Ursache wird einer der fünf Klassen zugeordnet.
- Eine fachliche oder technische Entscheidung erhält einen klaren Verantwortlichen.
- Die Korrektur wird in Quelldaten, Auswahl, Mapping, Transformation, Zielkonfiguration oder Testregel verankert.
- Eine passende Kontrolle prüft im nächsten Lauf genau diese Änderung.
- Erst nach erfolgreicher Wiederholung wird der Befund geschlossen.
Dadurch bleibt auch eine manuelle Korrektur möglich, wenn sie bewusst als einmalige Ausnahme entschieden wurde. Sie darf nur nicht unbemerkt zum Standardprozess werden. Für die ERP-Projektleitung muss erkennbar sein, welche Änderungen wiederholbar sind und welche Sonderfälle beim produktiven Lauf erneut bearbeitet werden müssten.
Den nächsten Lauf wiederholen, verkleinern oder neu aufsetzen
Nach der Ursachenanalyse stehen drei sinnvolle Wege offen. Die richtige Entscheidung hängt nicht von der bloßen Zahl der Fehler ab, sondern davon, wie gut der Lauf und seine Korrekturen beherrscht werden.
Den gleichen Umfang wiederholen
Eine Wiederholung ist sinnvoll, wenn der verwendete Datenstand eindeutig ist, die meisten Befunde verstanden wurden und Korrekturen reproduzierbar umgesetzt sind. Außerdem müssen Zielumgebung und Prüfkriterien stabil genug bleiben, damit der Vergleich mit dem vorherigen Lauf aussagekräftig ist.
Der nächste Test soll dann nicht nur weniger Fehlermeldungen erzeugen. Er muss belegen, dass geschlossene Ursachen nicht wiederkehren und unveränderte Bereiche weiterhin richtig funktionieren.
Den Test bewusst verkleinern
Wenn Umfang, Regeln und Zielvoraussetzungen gleichzeitig unsicher sind, erzeugt ein weiterer großer Lauf häufig nur eine größere Fehlerliste. Dann ist ein kleinerer, aber vollständiger Test wirkungsvoller. Ein repräsentatives Datenobjekt wird vom bekannten Quellstand über Mapping und Transformation bis zur fachlichen Prüfung im Zielsystem geführt.
Diese Verkleinerung ist kein Rückschritt. Sie isoliert die noch unsichere Stelle und schafft eine belastbare Referenz, bevor weitere Datenobjekte folgen.
Die Grundlage neu aufsetzen
Ein neuer Ausgangspunkt wird notwendig, wenn der ursprüngliche Teststand nicht mehr rekonstruierbar ist, zahlreiche Korrekturen nur in Dateien vorgenommen wurden oder niemand die Verantwortung für zentrale Regeln übernimmt. Dasselbe gilt, wenn sich Zielkonfiguration und Importstrukturen so stark verändert haben, dass der bisherige Lauf nicht mehr vergleichbar ist.
In diesem Fall sollte das Projekt nicht versuchen, einen unklaren Stand weiterzuschleppen. Es legt einen bestätigten Datenumfang, einen versionierten Regelstand und ein realistisches Testziel neu fest. Der Fahrplan für die ERP-Datenmigration hilft dabei, die früheste noch nicht belastbare Grundlage zu finden.
Wann der Go-live-Termin neu bewertet werden muss
Nicht jeder fehlgeschlagene Test verlangt eine Terminverschiebung. Frühe Testmigrationen sollen gerade Probleme sichtbar machen. Kritisch wird die Lage, wenn das Projekt aus den Befunden keinen nachweisbaren Fortschritt erzeugt.
Diese Signale sprechen für eine erneute Bewertung des Go-live-Risikos:
- Dieselben Fehler erscheinen in mehreren Läufen erneut.
- Der Fehlerbestand wächst, ohne dass Ursachen und Verantwortliche sichtbar werden.
- Mapping-Regeln oder Zielkonfiguration ändern sich, ohne dass der getestete Stand nachvollziehbar bleibt.
- Keyuser sollen freigeben, erhalten aber keine vorbereiteten Mengen-, Inhalts- oder Prozessprüfungen.
- Lauf- und Prüfzeiten wurden noch nicht unter realistischen Bedingungen gemessen.
- Niemand kann klar benennen, welche Abweichungen für den nächsten Schritt akzeptiert sind.
Umgekehrt kann ein Test trotz zahlreicher Befunde wertvoll sein, wenn die Fehler klassifiziert, ihre Ursachen verstanden und die nächsten Korrekturen planbar sind. Für den produktiven Termin zählt, ob die verbleibenden Schritte mit den verfügbaren Test- und Cut-over-Fenstern zusammenpassen. Wie diese Erkenntnisse in den Go-live-Ablauf einfließen, zeigt unser Beitrag zum ERP-Cut-over-Plan für die Datenmigration.
Wer die festgefahrene Datenmigration wieder zusammenführen sollte
Eine gescheiterte Testmigration ist selten allein ein Werkzeugproblem. Häufig liegt die offene Arbeit zwischen mehreren Zuständigkeiten: Der ERP-Partner erklärt Zielanforderungen und Importverhalten, die Fachbereiche entscheiden die geschäftliche Bedeutung und die interne Projektleitung steuert Termin und Risiko.
Fehlt zwischen diesen Rollen die operative Verbindung, kann ein spezialisierter Datenmigration-Dienstleister den gesicherten Teststand analysieren, Fehlerursachen trennen, Mapping-Entscheidungen vorbereiten und Korrekturen in einen wiederholbaren technischen Lauf überführen. Die fachliche Freigabe und die Leitung des ERP-Gesamtprojekts bleiben dennoch beim Unternehmen.
Ob dafür ein zusätzlicher Spezialist nötig ist, hängt vom bereits vereinbarten Leistungsumfang ab. Unser Beitrag „Reicht der ERP-Anbieter für die Datenmigration?“ hilft bei dieser Abgrenzung.
Ein sinnvoll begrenzter Einstieg besteht nicht aus einer weiteren allgemeinen Analyse. Er endet mit einem gesicherten Teststand, einer nach Ursachen geordneten Fehlerliste, klaren Verantwortlichkeiten für die Korrektur und einer begründeten Entscheidung über den nächsten Lauf. Damit wird aus einem schlechten Testergebnis wieder ein steuerbarer Schritt in Richtung Go-live.