Der Termin für den ersten Migrationstest steht. Die Importvorlagen sind vorhanden, ein Export aus dem Altsystem ist angekündigt und die Keyuser sollen Zeit für die Prüfung reservieren. Trotzdem bleibt oft unklar, was dieser Testlauf eigentlich beweisen soll.
Genau dann wird aus einem Test schnell ein teurer Probelauf ohne belastbares Ergebnis: Die geladene Datei ist nicht eindeutig versioniert, offene Mapping-Fragen werden während des Imports spontan entschieden und nach der Fehlerkorrektur kann niemand mehr nachvollziehen, welche Regel geändert wurde. Das Projekt hat zwar getestet, ist der produktiven Migration aber kaum nähergekommen.
Diese ERP-Migration-Checkliste setzt deshalb nicht bei einem perfekten Datenbestand an. Sie prüft, ob der erste Testlauf auswertbar, wiederholbar und entscheidungsfähig vorbereitet ist. Das ist der wichtigere Maßstab für einen frühen Migrationstest.
Die kurze Antwort: Testbereit bedeutet nicht fehlerfrei
Ein erster Testlauf darf Datenfehler, offene Sonderfälle und unvollständige Regeln sichtbar machen. Genau dafür ist er da. Testbereit ist das Projekt, wenn fünf Voraussetzungen erfüllt sind:
- Der getestete Umfang und das Ziel des Laufs sind eindeutig abgegrenzt.
- Quellstand, Mapping und Transformation lassen sich später erneut erzeugen.
- Zielumgebung, Importvorlagen und Objektabhängigkeiten sind bekannt.
- Für Mengen, Inhalte und Geschäftsprozesse existieren konkrete Prüfkriterien.
- Jeder Befund erhält eine Ursache, einen Verantwortlichen und eine nachvollziehbare Korrektur.
Ein nicht testbereites Projekt erkennt man daher nicht an der Anzahl offener Fehler. Kritisch ist vielmehr, wenn niemand sagen kann, welche Eingabe getestet wurde, welches Ergebnis erwartet war oder ob die nächste Datei dieselben Regeln enthält. Dann erzeugt der Lauf Aktivität, aber kein verlässliches Lernen.
Eine ERP-Migration-Checkliste ist kein zweiter Projektplan
Ein Fahrplan für die ERP-Datenmigration ordnet Phasen, Abhängigkeiten und Entscheidungstore vom Scope bis zum Go-live. Die Checkliste beantwortet eine engere operative Frage: Können wir mit dem jetzigen Stand einen aussagekräftigen Test durchführen?
| Steuerungsinstrument | Zentrale Frage | Typisches Ergebnis |
|---|---|---|
| Fahrplan | Welche Schritte und Entscheidungen folgen aufeinander? | Phasen, Meilensteine und Verantwortungen |
| Datenmigrationskonzept | Nach welchen Regeln wird die Migration geplant und gesteuert? | Festgelegter Scope, Verfahren und Governance |
| Readiness-Check | Ist der nächste Test mit dem aktuellen Arbeitsstand sinnvoll? | Go, bedingtes Go oder Stopp mit konkreten Lücken |
Das verhindert eine häufige Verwechslung: Ein erreichter Kalendereintrag ist noch kein Startkriterium. Auch ein formal fertiges Datenmigrationskonzept ersetzt nicht den Nachweis, dass Dateien, Regeln, Systemstände und Prüfer für den konkreten Lauf zusammenpassen.
ERP-Migration-Checkliste: 12 Nachweise vor dem ersten Testlauf
Die folgende Übersicht ist bewusst als Nachweischeck formuliert. Ein „ist in Arbeit“ reicht nicht aus. Zu jedem Punkt sollte das Projekt ein sichtbares Ergebnis benennen können.
| Prüfpunkt | Benötigter Nachweis | Klares Stoppsignal |
|---|---|---|
| 1. Testziel | Ein Satz beschreibt, welche technische oder fachliche Aussage der Lauf liefern soll. | Alle Beteiligten erwarten etwas anderes vom Test. |
| 2. Migrationsscope | Datenobjekte, Organisationseinheiten, Zeiträume und bewusste Ausschlüsse sind benannt. | Während des Exports wird noch grundsätzlich über den Umfang entschieden. |
| 3. Quellstand | Stichtag, Extraktionszeitpunkt und verwendete Quellsysteme sind dokumentiert. | Mehrere Dateien mit gleichem Namen und unbekanntem Stand kursieren. |
| 4. Kontrollwerte | Erwartete Datensatzmengen und, wo sinnvoll, Summen je Objekt liegen vor. | Nach dem Import kann nur geprüft werden, ob „etwas angekommen“ ist. |
| 5. Zielvorgaben | Aktuelle Vorlagen, Pflichtfelder, Codelisten und Importregeln sind verfügbar. | Vorlage und konfiguriertes Zielsystem haben unterschiedliche Stände. |
| 6. Mapping | Quellen, Zielattribute, fachliche Entscheidungen, Standardwerte und offene Punkte sind versioniert. | Wesentliche Zuordnungen existieren nur in Köpfen oder Chatnachrichten. |
| 7. Transformation | Regeln lassen sich per Skript oder eindeutig beschriebenem Ablauf erneut ausführen. | Die Testdatei wurde manuell korrigiert, ohne die zugrunde liegende Regel anzupassen. |
| 8. Ladereihenfolge | Abhängigkeiten zwischen Objekten und benötigte Schlüssel sind geklärt. | Fehlende Referenzen werden erst während des Imports entdeckt. |
| 9. Testumgebung | Systemstand, Berechtigungen, Importzugang und ein Verfahren für Wiederholung oder Bereinigung sind bestätigt. | Ein fehlgeschlagener Lauf kann nicht sauber zurückgesetzt werden. |
| 10. Fachliche Prüfung | Keyuser, Testfälle, Stichproben und erwartete Ergebnisse sind festgelegt. | Die Fachbereiche sollen ohne Aufgabenstellung „einmal durchschauen“. |
| 11. Fehlerprozess | Befunde werden nach Ursache, Priorität, Verantwortlichem und Zieltermin geführt. | Fehler landen ungeordnet in E-Mails, Screenshots und Besprechungsnotizen. |
| 12. Abschlussentscheidung | Ein Verantwortlicher entscheidet anhand vorher festgelegter Kriterien über den nächsten Zyklus. | Der Test endet mit einer offenen Aufgabenliste, aber ohne Konsequenz für den Plan. |
1. Testziel und Scope müssen enger sein als „die Migration testen“
Ein Testlauf kann unterschiedliche Fragen beantworten. Soll zunächst geprüft werden, ob das Zielsystem die Dateien technisch akzeptiert? Geht es um die fachliche Richtigkeit des Mappings? Sollen Mengen und Summen abgestimmt werden? Oder sollen Keyuser bereits vollständige Prozesse mit den migrierten Daten durchlaufen?
Diese Ziele bauen aufeinander auf, sind aber nicht identisch. Wer sie in einem einzigen frühen Lauf vermischt, erhält häufig eine lange Fehlerliste ohne klare Priorisierung. Besser ist ein begrenztes Ziel, zum Beispiel:
Der Lauf soll nachweisen, dass aktive Kunden und offene Kundenaufträge aus einem definierten Quellstand reproduzierbar erzeugt, in der richtigen Reihenfolge geladen und anhand festgelegter Mengen- und Fachprüfungen ausgewertet werden können.
Damit wird auch der Scope prüfbar. „Kundendaten“ ist dafür zu grob. Relevant sind die konkreten Datenobjekte, Gesellschaften oder Mandanten, Zeiträume, Statusfilter und Ausschlüsse. Bewusst ausgeschlossene Historien sind kein Mangel, solange die Entscheidung dokumentiert ist.
2. Der Quellstand braucht eine eindeutige Identität
Eine Testmigration ist nur wiederholbar, wenn die Eingabe bekannt ist. Dafür braucht es keinen überladenen Werkzeugpark. In vielen Projekten genügen eine klare Ordnerstruktur, festgelegte Dateinamen, ein Extraktionsprotokoll und versionierte Skripte. Entscheidend ist, dass das Team später beantworten kann:
- Aus welchem System und zu welchem Zeitpunkt stammen die Daten?
- Welche Filter und Selektionsregeln wurden verwendet?
- Wie viele Datensätze wurden je Objekt extrahiert?
- Welche Transformation hat genau diese Importdatei erzeugt?
Besonders riskant sind manuelle Korrekturen direkt in der fertigen CSV-Datei. Sie können einen einzelnen Import retten, verschwinden aber beim nächsten Export. Eine belastbare Korrektur ändert deshalb die Quelle, die Mapping-Entscheidung oder die Transformationsregel. So fließt die Erkenntnis in den nächsten Lauf ein.
3. Offene Mapping-Fragen sind erlaubt – unsichtbare nicht
Vor dem ersten Test muss ein Mapping nicht in jedem Sonderfall final sein. Es muss jedoch erkennen lassen, welche Regeln bereits entschieden sind und welche Annahmen noch geprüft werden. Für jedes relevante Zielattribut sollte mindestens sichtbar sein:
- aus welcher Quelle der Wert stammt,
- ob er direkt übernommen, umgerechnet, zusammengeführt oder neu abgeleitet wird,
- welcher Standardwert bei fehlenden Quelldaten gilt,
- wer die fachliche Entscheidung getroffen hat,
- welche offenen Punkte der Test beantworten soll.
Keyuser müssen dieses Mapping nicht zwingend bei null erstellen. Gerade bei komplexen Altsystemen ist es effizienter, wenn ein Datenmigrationsspezialist Quellstrukturen und Zielvorgaben analysiert, einen ersten Vorschlag vorbereitet und die wirklich entscheidungsbedürftigen Punkte sichtbar macht. Die Fachbereiche prüfen dann konkrete Zuordnungen anhand ihrer eigenen Daten, statt abstrakte Tabellen ohne Zielsystemkontext zu füllen.
4. Ein Testsystem allein macht das Projekt noch nicht testfähig
Die technische Umgebung kann bereitstehen, obwohl der fachliche Test noch nicht sinnvoll möglich ist. Keyuser benötigen neben dem Zugang eine klare Aufgabe, eine Einführung in die relevanten Zielprozesse und möglichst eigene Daten im neuen System. Erst dann erkennen sie, ob ein Wert nur technisch vorhanden oder im richtigen fachlichen Zusammenhang nutzbar ist.
Deshalb sollte der Readiness-Check nicht nur fragen, ob Benutzerkonten funktionieren. Er muss auch klären:
- Welche Masken, Listen und Folgeprozesse werden mit den migrierten Daten geprüft?
- Welche alten und neuen Schlüssel müssen die Prüfer miteinander vergleichen können?
- Welche Stichproben bilden Normalfälle und bekannte Sonderfälle ab?
- Welche erwarteten Ergebnisse sind vor dem Test dokumentiert?
Ein technisch erfolgreicher Import ist noch keine fachliche Freigabe. Ein Kunde kann vollständig geladen sein und trotzdem der falschen Preisgruppe, Zahlungsbedingung oder Vertriebsorganisation zugeordnet werden. Die Prüfung muss daher über die reine Fehlermeldung des Importwerkzeugs hinausgehen.
5. Prüfkriterien müssen Mengen, Inhalte und Prozesse verbinden
Eine belastbare Validierung betrachtet mehrere Ebenen. Welche davon relevant sind, hängt vom Datenobjekt und vom Ziel des Testlaufs ab:
- Mengenprüfung: Stimmen extrahierte, transformierte, geladene und abgewiesene Datensätze rechnerisch zusammen?
- Summenprüfung: Stimmen beispielsweise offene Beträge, Bestandsmengen oder Salden in den vereinbarten Abgrenzungen?
- Strukturprüfung: Sind Schlüssel eindeutig, Pflichtfelder gefüllt und Beziehungen zwischen Objekten intakt?
- Fachprüfung: Wurden Status, Klassifizierungen, Einheiten und weitere steuernde Merkmale richtig übersetzt?
- Prozessprüfung: Lassen sich die vorgesehenen Geschäftsvorgänge mit den migrierten Daten tatsächlich ausführen?
Auch Herstellerleitfäden behandeln Migrationstests als wiederholbaren Lernprozess. SAP beschreibt, dass Korrekturen und Verfeinerungen aus einem Test in die jeweils nächste Testmigration übernommen werden. Microsoft empfiehlt in seiner Teststrategie unter anderem klare Ein- und Austrittskriterien, definierte Zuständigkeiten und eine nachvollziehbare Fehlerverfolgung. Diese Prinzipien sind nicht an ein bestimmtes ERP-System gebunden.
6. Fehler müssen den nächsten Lauf verbessern
Eine lange Fehlerliste ist noch keine Testauswertung. Für eine schnelle Korrektur sollte jeder Befund zunächst einer wahrscheinlichen Ursache zugeordnet werden:
- Fehler oder fehlender Wert in der Quelle,
- unklare beziehungsweise falsche Mapping-Entscheidung,
- Fehler in Extraktion oder Transformation,
- abweichender Stand von Zielkonfiguration oder Importvorlage,
- falsche Ladereihenfolge oder fehlende Referenz,
- unzureichend beschriebener Testfall.
Diese Trennung verhindert, dass jeder Befund pauschal als „Datenfehler“ beim Fachbereich landet oder ungeprüft an den ERP-Anbieter weitergereicht wird. Sie macht außerdem sichtbar, welche Partei tatsächlich handeln muss.
Zu einem geschlossenen Fehlerkreislauf gehören neben der Ursache ein Verantwortlicher, ein Zieltermin, die betroffene Regel- oder Dateiversion und ein geplanter Nachtest. Erst wenn die Korrektur reproduzierbar in den Erzeugungsprozess übernommen wurde, ist sie für die nächste Migration belastbar.
Was der erste Testlauf als Ergebnis liefern sollte
Der eigentliche Wert des ersten Tests liegt nicht in einer möglichst grünen Statusfolie. Er liegt in belastbaren Informationen für den nächsten Zyklus. Nach Abschluss sollten mindestens folgende Ergebnisse vorliegen:
- gemessene Laufzeiten für Extraktion, Transformation und Import,
- abgestimmte Mengen sowie nachvollziehbare Abweisungen,
- priorisierte Befunde mit geklärten Ursachen und Zuständigkeiten,
- bestätigte oder geänderte Mapping- und Transformationsregeln,
- fachliche Rückmeldungen der Keyuser anhand eigener Daten,
- Entscheidungen über Scope, Zielkonfiguration und nächste Testtiefe.
Diese Ergebnisse werden später zu wichtigen Eingaben für den ERP-Cutover-Plan. Erst gemessene Laufzeiten, erprobte Reihenfolgen und bekannte Fehlerwege machen aus einem Go-live-Termin einen ausführbaren Ablauf.
Go, bedingtes Go oder Stopp: So wird die Checkliste entschieden
Eine starre Punktzahl wäre trügerisch, weil nicht jeder fehlende Nachweis gleich kritisch ist. Sinnvoller ist eine qualitative Entscheidung:
Go
Der Lauf ist auswertbar und wiederholbar. Bekannte Datenmängel sind dokumentiert, gefährden das Testziel aber nicht. Prüfer, Kriterien und Fehlerprozess stehen fest.
Bedingtes Go
Einzelne Lücken bleiben offen, doch ihr Einfluss ist bekannt. Es gibt Verantwortliche und Termine, und der Test kann trotz dieser Einschränkungen eine klar benannte Aussage liefern. Die Einschränkungen werden im Testprotokoll sichtbar festgehalten.
Stopp
Der Quell- oder Regelstand ist nicht reproduzierbar, das Ziel des Laufs ist widersprüchlich, wesentliche Objektabhängigkeiten fehlen oder niemand kann das Ergebnis fachlich prüfen. In diesen Fällen kostet ein früher Start meist mehr Zeit, als eine kurze, gezielte Vorbereitung benötigen würde.
Wann externe Unterstützung vor dem ersten Test sinnvoll wird
Die Checkliste ist zugleich ein realistischer Kapazitätscheck. Externe Unterstützung wird nicht deshalb nötig, weil noch Datenfehler existieren. Sie wird sinnvoll, wenn entscheidende Arbeitspakete intern keinen ausführenden Verantwortlichen haben – etwa die technische Quellanalyse, die Vorbereitung des Mappings, wiederholbare Transformationen, die Testkoordination oder die strukturierte Fehlerursachenanalyse.
Ob diese Aufgaben bereits beim Implementierungspartner liegen oder auf Kundenseite verbleiben, sollte vor dem Test geklärt werden. Unser Beitrag zur Frage „Reicht der ERP-Anbieter für die Datenmigration?“ zeigt, wie sich diese Leistungsgrenze anhand konkreter Ergebnisse prüfen lässt.
So wird aus der ERP-Migration-Checkliste kein weiteres Projektdokument, sondern ein klares Entscheidungstor: Das Team erkennt vor dem Upload, ob der Test belastbare Erkenntnisse erzeugen kann, welche Lücken zuerst geschlossen werden müssen und wo zusätzliche Migrationskompetenz das Projekt tatsächlich entlastet.