Testmigration
Eine Testmigration ist ein Probelauf der Datenübernahme in ein neues System – die Daten aus dem Altsystem werden vollständig ins Zielsystem geladen, aber nicht produktiv gesetzt. Sie deckt Mapping-Fehler, Formatprobleme und Datenlücken auf, bevor der echte Go-Live stattfindet.
Eine Testmigration ist ein vollständiger Probelauf der Datenübernahme aus einem Altsystem in ein neues Zielsystem, bei dem die übertragenen Daten geprüft, aber noch nicht produktiv genutzt werden. Sie ist ein zentraler Baustein jeder Datenmigration im Rahmen einer ERP-Einführung: Statt die echten Daten beim ersten Versuch direkt in das produktive System zu laden, wird der komplette Extraktions-, Transformations- und Ladeprozess zunächst in einer Test- oder Sandbox-Umgebung durchgespielt. So werden Fehler und Lücken sichtbar, solange sie noch folgenlos korrigiert werden können.
Der Zweck ist einfach: Kein Migrationskonzept überlebt den ersten Kontakt mit echten Altdaten. Feld-Zuordnungen passen nicht, Pflichtfelder bleiben leer, Zahlenformate oder Umlaute kippen, Summen stimmen nicht. Eine Testmigration macht genau diese Probleme messbar und reproduzierbar, bevor sie den Echtbetrieb erreichen. In der Regel wird nicht nur einmal getestet, sondern in mehreren Durchläufen, bis die Ergebnisse stabil und vollständig sind – erst dann folgt die produktive Migration zum Stichtag.
Auf einen Blick
- Probelauf der Datenübernahme in einer Test-/Sandbox-Umgebung, nicht produktiv
- Deckt Mapping-Fehler, Formatprobleme, leere Pflichtfelder und Summenabweichungen auf
- Wird iterativ wiederholt, bis Ergebnis stabil und vollständig ist
- Grundlage für Abnahme (Validierung) durch Fachbereich und Key-User
- Voraussetzung für einen sauberen Cut-over und Go-Live
Was eine Testmigration ist und wozu sie dient
Bei einer Testmigration wird der gesamte Ablauf einer Datenmigration – Extrahieren aus dem Altsystem, Bereinigen, Transformieren, Feld-Mapping und Laden ins Zielsystem – vollständig durchlaufen, jedoch in eine nicht-produktive Umgebung. Das Ergebnis dient ausschließlich der Prüfung: Sind alle Datensätze angekommen? Stimmen Anzahl, Summen und Feldinhalte? Lassen sich die migrierten Daten im neuen System fachlich korrekt weiterverarbeiten, etwa ein übernommener Auftrag fakturieren oder ein Artikel kommissionieren?
Die Testmigration ist damit kein technischer Nebenschauplatz, sondern das wichtigste Qualitätssicherungsinstrument der Datenübernahme. Sie verwandelt ein theoretisches Migrationskonzept in belastbare Erkenntnisse und liefert die Faktenbasis dafür, ob die echte Migration überhaupt riskiert werden darf. Ohne belegten, erfolgreichen Testlauf ist ein Go-Live ein Blindflug.
Wie eine Testmigration abläuft
Eine Testmigration folgt dem Muster der eigentlichen Migration, wird aber bewusst als Iteration angelegt. Zunächst wird ein realistischer Datenextrakt aus dem Altsystem gezogen – idealerweise ein vollständiger Bestand, nicht nur eine Stichprobe, weil gerade Sonderfälle und Karteileichen die Fehler verursachen. Dieser Extrakt durchläuft die definierten Transformations- und Mapping-Regeln und wird in die Testinstanz des Zielsystems geladen.
Anschließend erfolgt die Auswertung: Ladeprotokolle und Fehlerlisten werden ausgewertet, Datensatzzahlen abgeglichen, Kontrollsummen (etwa Bestandswerte oder offene Posten) verglichen und Stichproben fachlich geprüft. Jeder gefundene Fehler führt zu einer Korrektur am Mapping, an den Bereinigungsregeln oder an den Quelldaten – danach beginnt der nächste Durchlauf. Dieser Zyklus wiederholt sich, bis die Fehlerquote gegen null geht und die Fachabteilung die Ergebnisse abnimmt.
Testmigration und Feld-Mapping
Der häufigste Befund einer Testmigration betrifft das Feld-Mapping: Ein Feld aus dem Altsystem wurde dem falschen Zielfeld zugeordnet, ein Pflichtfeld im Zielsystem hat keine Entsprechung, oder Werte müssen umgeschlüsselt werden (etwa Freitext-Länder auf ISO-Codes). Weil die Testmigration mit echten Daten arbeitet, treten diese Lücken konkret und nachvollziehbar zutage – anders als bei einer reinen Schreibtischprüfung des Mappings.
Wie viele Durchläufe sind nötig?
Es gibt keine feste Zahl, aber zwei bis vier Durchläufe sind in ERP-Projekten üblich: ein erster technischer Lauf, um überhaupt Daten durchzubekommen, gefolgt von fachlichen Läufen zur inhaltlichen Korrektur und einem abschließenden Generalprobe-Lauf möglichst nah am Cut-over. Der letzte Testlauf sollte den späteren Produktivlauf so exakt wie möglich abbilden, inklusive Zeitbedarf, damit das Cut-over-Zeitfenster realistisch geplant werden kann.
Warum die Testmigration für den Go-Live entscheidend ist
Fehlerhafte Daten sind einer der häufigsten Gründe für gescheiterte oder verzögerte ERP-Einführungen. Wird eine Migration ohne ausreichende Tests direkt produktiv gefahren, landen Dubletten, falsche Bestände oder unvollständige offene Posten im Echtsystem – und werden dort oft erst Wochen später bemerkt, wenn Prozesse bereits darauf aufgesetzt haben. Die Testmigration verlagert das Risiko nach vorn, in eine Phase, in der Korrekturen billig sind.
Zugleich liefert sie belastbare Kennzahlen für die Go-Live-Entscheidung: Fehlerquoten, Vollständigkeit, benötigte Laufzeit. Diese Werte fließen in die Freigabe (Abnahme) durch Projektleitung und Key-User ein und machen den Cut-over planbar. Ein erfolgreicher, dokumentierter Testlauf ist deshalb in vielen Projekten formales Freigabekriterium für die produktive Übernahme.
Abgrenzung: Testmigration vs. Datenmigration und Parallelbetrieb
Die Testmigration ist ein Teilschritt der Datenmigration, nicht deren Ersatz. Die Datenmigration umfasst den gesamten Prozess der Datenübernahme; die Testmigration ist deren nicht-produktiver Probelauf. Nach erfolgreichen Testläufen folgt die eigentliche, produktive Migration zum festgelegten Stichtag im Rahmen des Cut-over.
Auch vom Parallelbetrieb ist die Testmigration abzugrenzen: Beim Parallelbetrieb laufen Alt- und Neusystem nach dem Go-Live eine Zeit lang gleichzeitig produktiv, um Ergebnisse zu vergleichen. Die Testmigration dagegen findet vor dem Go-Live statt und ist reine Vorbereitung. Von einer einfachen Datenimport-Routine unterscheidet sie sich dadurch, dass sie den vollständigen Migrationsprozess mit Vollbestand abbildet und explizit auf Prüfung und Abnahme ausgelegt ist – nicht auf laufenden Betrieb.
Testmigration im ERP-System
Viele ERP-Systeme stellen für Testmigrationen eine separate Test- oder Sandbox-Instanz bereit, die technisch dem Produktivsystem gleicht, aber isoliert ist. Der Import erfolgt je nach System über strukturierte Importvorlagen (CSV/Excel), über eine API oder über spezialisierte Migrationswerkzeuge. Wichtig ist, dass die Testinstanz denselben Konfigurationsstand wie das spätere Produktivsystem hat – Nummernkreise, Pflichtfelder und Customizing müssen übereinstimmen, sonst sind die Testergebnisse wertlos.
In DACH-Projekten kommt der Prüfung finanzrelevanter Daten besondere Bedeutung zu. Übernommene offene Posten, Kontensalden und Bestandsbewertungen müssen im Testlauf auf den Cent mit dem Altsystem abgeglichen werden, weil sie später Grundlage der Buchhaltung und damit GoBD-relevanter Prozesse sind. Auch die Nachvollziehbarkeit der Migration selbst – welcher Datensatz wann wie übernommen wurde – gehört idealerweise in die Verfahrensdokumentation.
Praxisbeispiel
Testmigration bei einem Handelsunternehmen
Ein mittelständischer Onlinehändler mit rund 18.000 Artikeln und 12.000 Kunden wechselt von einer alten Warenwirtschaft auf ein neues ERP. Im ersten Testlauf werden zwar alle Kunden geladen, doch 640 Datensätze landen ohne Land, weil das Altsystem das Land als Freitext führte und das Zielsystem einen ISO-Code als Pflichtfeld erwartet. Außerdem weicht der übernommene Gesamtbestandswert um 4.200 Euro ab – Ursache sind Artikel mit negativem Lagerbestand, die das neue System anders behandelt.
Das Projektteam korrigiert die Mapping-Regel für das Land und definiert eine Bereinigung für Negativbestände. Der zweite Testlauf läuft sauber durch, Bestandswert und offene Posten stimmen auf den Cent. Erst nach diesem abgenommenen Ergebnis wird der Stichtag für die produktive Migration gesetzt – das Go-Live-Wochenende verläuft dadurch ohne böse Überraschungen.
Häufige Fragen
Passende Leistungen
Quellen
Fragen zu Testmigration in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.