Drei Testmigrationen können zu wenig sein. Vier können trotzdem eine Verschwendung sein. Die Anzahl allein sagt nämlich nicht, ob eine ERP-Testmigration dem Go-live näherkommt. Entscheidend ist, welche Unsicherheit ein Lauf beseitigt und welche Entscheidung danach getroffen werden kann.
Die sinnvolle Zahl der Testläufe steht deshalb nicht allgemein fest. Ein weiterer vollständiger Lauf ist nötig, wenn wesentliche Teile des Ablaufs von der Extraktion bis zur fachlichen Prüfung verändert wurden oder ein notwendiger Nachweis noch fehlt. Betrifft eine Korrektur dagegen nur einen klar abgegrenzten Fehler, kann zunächst ein gezielter Nachtest ausreichen.
Für die ERP-Projektleitung verändert diese Sichtweise die Planung: Sie reserviert nicht einfach drei gleichartige Termine. Sie verbindet jeden Lauf mit einem eigenen Erkenntnisziel, klaren Prüfkriterien und einer vorher vereinbarten Folgeentscheidung.
Nicht die Zahl, sondern die offene Unsicherheit bestimmt den nächsten Lauf
Eine Testmigration ist dann aussagekräftig, wenn ihr Ausgangspunkt eindeutig ist. Dazu gehören der verwendete Quelldatenstand, die Version der Mapping- und Transformationsregeln, die Zielumgebung sowie die geplanten Prüfungen. Ohne diesen Zusammenhang lassen sich zwei Läufe kaum vergleichen. Ein besseres Ergebnis kann dann aus einer echten Korrektur stammen – oder nur aus einer manuell veränderten Datei.
Wir planen Testläufe daher als aufeinander aufbauende Beweisschritte. Der erste belastbare Lauf muss nicht bereits den vollständigen Produktivumfang abbilden. Er sollte jedoch zeigen, dass ein abgegrenzter Datenbestand reproduzierbar aus der Quelle erzeugt, in das Ziel geladen und fachlich geprüft werden kann. Danach wächst die Aussagekraft gezielt: weitere Datenobjekte, schwierigere Beziehungen, realistischere Mengen und schließlich der produktionsnahe Ablauf.
Damit wird auch sichtbar, warum eine feste Sollzahl trügerisch ist. Ein kleines Projekt kann mehrere Läufe benötigen, wenn Regeln oder Verantwortlichkeiten lange offenbleiben. Ein umfangreicheres Projekt kann mit weniger vollständigen Läufen auskommen, wenn es früh mit stabilen Regeln, repräsentativen Daten und konsequenten Nachtests arbeitet.
Vier Nachweise müssen bis zum Go-live zusammenkommen
Die folgenden Nachweise sind keine vier vorgeschriebenen Testphasen. Ein Lauf kann mehrere davon gleichzeitig liefern. Für die Entscheidung über einen weiteren Lauf hilft es jedoch, sie getrennt zu betrachten.
| Nachweis | Was der Test belegen muss | Was noch keinen belastbaren Nachweis ergibt |
|---|---|---|
| Reproduzierbarkeit | Der vereinbarte Datenbestand lässt sich mit dokumentierten Regeln erneut aus der Quelle erzeugen und laden. | Eine einmalig von Hand korrigierte Importdatei. |
| Fachliche Nutzbarkeit | Mengen, Werte und Beziehungen stimmen, und die betroffenen Geschäftsprozesse funktionieren mit den migrierten Daten. | Ein technisch grünes Importprotokoll ohne fachliche Prüfung. |
| Realistische Leistung | Datenmenge, Laufzeit, Fehlerbearbeitung und Prüfaufwand passen in das vorgesehene Zeitfenster. | Ein kleiner Beispieldatensatz, aus dem die Dauer des Produktivlaufs hochgerechnet wird. |
| Ausführbarer Cut-over | Datenstopp, Extraktion, Transformation, Ladereihenfolge, Prüfung und Freigabe greifen unter realistischen Bedingungen ineinander. | Ein erfolgreicher Datenimport ohne abgestimmte Übergaben und Go-/No-go-Entscheidung. |
Diese Trennung verhindert, dass das Projekt einen Lauf als „erfolgreich“ verbucht, obwohl er nur eine von mehreren Fragen beantwortet hat. Sie zeigt zugleich, welcher nächste Test tatsächlich nötig ist.
Wann ein vollständiger Lauf nötig ist – und wann ein Nachtest genügt
Ein vollständiger Lauf wiederholt die vereinbarte Migrationskette vom definierten Quelldatenstand bis zur fachlichen Prüfung im Zielsystem. Ein gezielter Nachtest beschränkt sich dagegen auf die betroffene Regel, ein Datenobjekt oder eine kleine Gruppe von Datensätzen. Welche Variante angemessen ist, hängt von der Reichweite der Änderung ab.
| Situation nach dem letzten Test | Sinnvoller nächster Schritt | Begründung |
|---|---|---|
| Auswahlregeln, Mapping oder Transformation wurden für viele Datensätze geändert. | Vollständiger Lauf für den betroffenen Umfang. | Die Änderung kann auch bereits bestandene Prüfungen beeinflussen. |
| Ein neues Datenobjekt oder eine neue Abhängigkeit kommt in den Scope. | Vollständiger Lauf der zusammenhängenden Datenobjekte. | Schlüssel und Beziehungen müssen gemeinsam geprüft werden. |
| Ein einzelner Fehler betrifft eine klar abgegrenzte Regel. | Zuerst gezielter Nachtest, danach Einbezug in den nächsten geplanten Gesamtstand. | Die Korrektur lässt sich schnell prüfen, ohne die gesamte Migration vorzeitig neu zu starten. |
| Die Daten wurden geladen, aber die Keyuser-Prüfung ist noch nicht abgeschlossen. | Zunächst den vorhandenen Datenstand fachlich auswerten. | Eine erneute Ladung erzeugt keinen zusätzlichen Erkenntnisgewinn, solange der bisherige Stand nicht beurteilt ist. |
| Datenmenge, Laufzeit oder Ladereihenfolge waren nicht produktionsnah. | Vollständiger, repräsentativer Lauf beziehungsweise Cut-over-Probe. | Nur damit lässt sich beurteilen, ob technische und fachliche Arbeiten in das Go-live-Fenster passen. |
| Es fehlen nur Dokumentation oder eine formale Freigabe zu bereits geprüften Ergebnissen. | Offene Entscheidung nachholen, keinen automatischen Zusatzlauf ansetzen. | Ein weiterer Import ersetzt weder Dokumentation noch Verantwortungsübernahme. |
Nach Änderungen mit größerer Reichweite ist zusätzlich ein Regressionstest sinnvoll. Damit werden bereits erfolgreiche Bereiche erneut geprüft, weil eine neue Regel oder Konfiguration dort unbeabsichtigte Folgen haben kann. Der gezielte Nachtest beantwortet also: „Ist dieser Fehler behoben?“ Der Regressionstest beantwortet: „Funktioniert der übrige bestätigte Stand weiterhin?“
Ein Testlauf ist nur dann mehr als ein Termin, wenn sein Ausgang etwas entscheidet
Vor dem Start sollte die Projektleitung vier Sätze vervollständigen können:
- Dieser Lauf verwendet … – einen bezeichneten Quelldatenstand, eine konkrete Regelversion und eine bekannte Zielumgebung.
- Dieser Lauf soll nachweisen … – zum Beispiel, dass Kunden und offene Aufträge vollständig, richtig verknüpft und im Zielprozess verwendbar sind.
- Der Nachweis gilt als erbracht, wenn … – vorher festgelegte Mengen-, Inhalts-, Prozess- und Laufzeitkriterien erfüllt sind.
- Das Ergebnis entscheidet über … – eine Korrektur, die Erweiterung des Umfangs, einen vollständigen nächsten Migrationslauf oder die Freigabe für die Cut-over-Probe.
Bleibt einer dieser Sätze offen, produziert der Lauf wahrscheinlich vor allem neue Dateien und Fehlerlisten. Dann ist es wirtschaftlicher, zunächst Ziel, Datenstand oder Prüfkriterien zu klären. Die ERP-Migration-Checkliste vor dem ersten Testlauf beschreibt, welche Grundlagen dafür bereits vor der ersten Ladung vorhanden sein sollten.
Wann die Testserie beendet werden kann
Die Testserie ist nicht automatisch beendet, sobald die Fehlerliste leer aussieht. Maßgeblich ist, ob die vereinbarten Austrittskriterien erfüllt sind. Austrittskriterien beschreiben die nachweisbaren Bedingungen, unter denen ein Testzyklus abgeschlossen werden darf.
Für die Datenmigration gehören dazu mindestens ein reproduzierbarer technischer Ablauf, nachvollziehbare Mengen- und Inhaltsabgleiche, eine fachliche Prüfung mit migrierten Daten sowie eine belastbare Laufzeit. Kritische offene Fehler müssen behoben sein. Weniger kritische Restpunkte benötigen eine bewusste Bewertung, einen Verantwortlichen und einen Termin; sie dürfen nicht lediglich aus der Testübersicht verschwinden.
Auch offizielle Herstellerleitfäden folgen dieser Logik. Microsoft verbindet Testzyklen mit konkreten Zielen, Umfang, Rollen, Austrittskriterien und fachlicher Freigabe. Nach Änderungen sollen auch zuvor bestandene Bereiche erneut geprüft werden. SAP beschreibt für S/4HANA-Testübertragungen, dass Korrekturen und Verfeinerungen aus dem vorherigen Test in das nächste Migrationsprojekt übernommen werden. Die Hersteller nennen damit keine universelle Zahl, sondern einen Lern- und Nachweisprozess.
Spätestens vor dem Produktivlauf muss dieser Prozess in eine realistische Generalprobe übergehen. Welche Laufzeiten, Übergaben und Entscheidungen dabei zusammengeführt werden, vertieft unser Beitrag zum ERP-Cutover-Plan für die Datenmigration.
Was diese Logik für Terminplan und Angebot verändert
Im Terminplan sollten Testläufe nicht nur als nummerierte Meilensteine stehen. Zu jedem Lauf gehören ein Erkenntnisziel, eine Korrekturphase, die fachliche Auswertung und die Entscheidung über den nächsten Umfang. Zusätzlich braucht das Projekt ausreichend Spielraum für einen weiteren Lauf, falls ein wesentlicher Nachweis scheitert. Dieser Puffer ist keine schlechte Planung, sondern die Konsequenz eines Tests, dessen Ergebnis noch nicht feststehen kann.
Auch im Angebot sollte erkennbar sein, was mit „drei Testmigrationen“ tatsächlich gekauft wird. Enthalten sein müssen nicht nur Extraktion und Import, sondern auch die Übernahme beschlossener Korrekturen, die erneute Erzeugung der Daten, technische Auswertung und Unterstützung der fachlichen Prüfung. Ebenso sollte geregelt sein, wann ein zusätzlicher Lauf entsteht und wann ein gezielter Nachtest innerhalb des vereinbarten Arbeitspakets liegt. Unser Beitrag über ein belastbares Angebot für die ERP-Datenmigration hilft, diese Leistungsgrenze genauer zu prüfen.
Wo externe Unterstützung den Testprozess wirklich entlastet
Zusätzliche Unterstützung wird nicht allein deshalb sinnvoll, weil viele Fehler auftreten. Entscheidend ist, ob jemand die Kette von der Ursache bis zum nächsten belastbaren Nachweis zusammenhält: Quelldaten auswählen, Regeln anpassen, Transformation reproduzierbar ausführen, Importergebnisse auswerten, fachliche Prüfungen vorbereiten und die Konsequenz für den nächsten Lauf festhalten.
Wir können diese operative Verbindung übernehmen und die ERP-Projektleitung bei Planung, Moderation und technischer Umsetzung entlasten. Die fachlichen Entscheidungen und Freigaben bleiben beim Unternehmen; der ERP-Partner verantwortet weiterhin die vereinbarten Aufgaben im Zielsystem. Wie diese Rollen sauber voneinander abgegrenzt werden, zeigt der Beitrag Reicht der ERP-Anbieter für die Datenmigration?.
Vor dem nächsten Termin sollte deshalb nicht nur „Testlauf 3“ im Kalender stehen. Der entscheidende Satz lautet: Dieser Lauf ist nötig, weil er genau diesen noch offenen Nachweis liefern soll. Lässt sich der Satz nicht konkret vervollständigen, sollte das Projekt den Lauf erst präzisieren – und nicht einfach wiederholen.