Ein importierter Datensatz ist noch kein migrierter Datensatz.

Nach einem Migrationslauf sehen die ersten Zahlen häufig beruhigend aus: 184.231 Produkte gelesen, 184.231 Produkte geschrieben, keine technischen Fehler. Die Datenbank enthält dieselbe Anzahl an Datensätzen wie das Altsystem. Der Import gilt damit schnell als erfolgreich.

Für den Commerce-Betrieb ist diese Aussage fast wertlos. Produkte können formal vorhanden und trotzdem unverkäuflich sein. Varianten können falsch verbunden, Preise in der falschen Währung, Bilder vertauscht, Kategorien unvollständig und Kundenkonten doppelt angelegt sein. Eine Bestellung kann technisch importiert sein, aber nicht mehr zum richtigen Kunden oder Beleg gehören.

Eine Migration ist deshalb erst dann erfolgreich, wenn die Daten im neuen fachlichen Modell korrekt funktionieren.

Technische Vollständigkeit ist nur die erste Stufe

Ein belastbarer Migrationsnachweis besteht aus mehreren Ebenen.

1. Strukturelle Validierung

Sind die Datensätze technisch lesbar und entsprechen sie dem erwarteten Schema?

Beispiele:

• Pflichtfelder vorhanden,
• Datentypen korrekt,
• Datumswerte gültig,
• keine abgeschnittenen Texte,
• Dateien und Medien erreichbar,
• Zeichencodierung korrekt.

2. Referenzielle Validierung

Sind Beziehungen zwischen Datensätzen erhalten geblieben?

Beispiele:

• Variante gehört zum richtigen Hauptprodukt,
• Bestellung gehört zum richtigen Kunden,
• Position verweist auf das richtige Produkt,
• Kategoriebeziehung existiert,
• Medien sind den richtigen Varianten zugeordnet,
• Adressen sind dem richtigen Konto zugewiesen.

3. Fachliche Validierung

Erfüllen die Daten die Geschäftsregeln?

Beispiele:

• Verkaufspreis ist für Markt und Kundengruppe korrekt,
• Steuersatz passt zum Produkt und Lieferland,
• Produkt ist nur bei gültiger Freigabe sichtbar,
• Bestand und Lieferzeit widersprechen sich nicht,
• inaktive Varianten sind nicht kaufbar,
• Dokumente entsprechen Sprache und Markt.

4. Prozessvalidierung

Funktionieren die Daten in realen Abläufen?

Beispiele:

• Produkt lässt sich finden, filtern und bestellen,
• Preis bleibt vom Listing bis zum Auftrag konsistent,
• Bestellung gelangt mit richtigen IDs ins ERP,
• Statusänderungen werden zurückgespielt,
• Kunde sieht seine historischen und neuen Vorgänge,
• Storno und Erstattung funktionieren.

5. Betriebsvalidierung

Bleiben Daten nach dem Go-live aktuell und kontrollierbar?

Beispiele:

• inkrementelle Updates funktionieren,
• Fehler werden sichtbar,
• Wiederholungen erzeugen keine Dubletten,
• veraltete Datensätze werden deaktiviert,
• Quelländerungen treffen innerhalb des erwarteten Zeitfensters ein.

Erst alle Ebenen zusammen belegen, dass ein Datensatz wirklich migriert wurde.

Datensatzanzahlen können sogar täuschen

Eine identische Anzahl vor und nach der Migration klingt nach Vollständigkeit. Sie kann fachlich trotzdem falsch sein.

Beispiele:

• Zwei Altdatensätze müssten im Ziel zu einem Golden Record zusammengeführt werden.
• Ein Altdatensatz muss im neuen Variantenmodell in mehrere Datensätze aufgeteilt werden.
• Technische Hilfsprodukte dürfen im neuen Shop gar nicht erscheinen.
• Gelöschte oder inaktive Datensätze werden bewusst nicht übernommen.
• Historische Kundenkonten werden in ein Archiv statt in das operative System migriert.

Die richtige Zielzahl ergibt sich also aus dem Zielmodell, nicht aus der Quellanzahl.

Statt nur zu vergleichen, wie viele Datensätze vorhanden sind, sollte die Migration sogenannte Reconciliation Reports erzeugen:

Quelle gelesen:                    184.231
bewusst ausgeschlossen:              6.420
zusammengeführt:                     2.118
in Varianten aufgeteilt:             1.304
erfolgreich im Ziel angelegt:      176.997
mit Warnung angelegt:                  811
fachlich blockiert:                    493
ungeklärt:                               0

Eine solche Bilanz erklärt Unterschiede, statt sie zu verstecken.

Repräsentative Testsets statt zufälliger Stichproben

Zufällige Stichproben finden häufig nur gewöhnliche Standardfälle. Für die fachliche Abnahme werden jedoch genau die schwierigen Konstellationen benötigt.

Ein repräsentatives Testset sollte bewusst enthalten:

• Produkt mit einer Variante,
• Produkt mit sehr vielen Varianten,
• Produkt mit Staffelpreis,
• Produkt mit kundenspezifischem Preis,
• Produkt mit mehreren Steuerfällen,
• Produkt ohne Bestand, aber mit Beschaffungszeit,
• Produkt mit mehreren Sprachen,
• Produkt mit vielen Medien und Dokumenten,
• deaktiviertes oder auslaufendes Produkt,
• Kunde mit mehreren Adressen,
• Gastbestellung,
• Bestandskunde mit historischer Bestellung,
• Bestellung mit Gutschein, Teilstorno oder Erstattung.

Dieses Set wird vor jedem relevanten Migrationslauf automatisiert und manuell geprüft. Es dient gleichzeitig als Regressionstest für spätere Änderungen.

Golden Datasets schaffen einen belastbaren Referenzpunkt

Für besonders kritische Entitäten lohnt sich ein kleines, fachlich bestätigtes Golden Dataset. Es enthält bekannte Eingabedaten und das erwartete Ergebnis im Zielsystem.

Beispiel für ein Produkt:

Quellpreis ERP:                 100,00 EUR
Kundengruppenrabatt:             10,00 %
Metallzuschlag:                   4,25 EUR
erwarteter Nettopreis:           94,25 EUR
erwartete Steuer DE:             17,91 EUR
erwarteter Bruttopreis:         112,16 EUR

Nach jeder Migration wird geprüft, ob das Zielsystem dieselben fachlichen Ergebnisse erzeugt. So werden nicht nur Datenfelder verglichen, sondern das Verhalten des neuen Systems.

Visuelle und funktionale Prüfung gehören dazu

Produktdaten können in der Datenbank korrekt aussehen und in der Oberfläche trotzdem fehlerhaft sein.

Typische Ursachen:

• HTML aus dem Altsystem wird falsch gerendert,
• Bilder besitzen ungeeignete Formate oder Reihenfolgen,
• Variantenattribute führen zu unverständlichen Auswahlfeldern,
• technische Kategorien erzeugen eine schlechte Navigation,
• Texte laufen in Komponenten über,
• Übersetzungen fehlen in einzelnen Sales Channels,
• Downloadlinks zeigen auf interne oder abgelaufene Pfade.

Deshalb braucht die Abnahme neben Datenreports auch visuelle und funktionale Tests im tatsächlichen Shop.

Mögliche Automatisierung:

• Screenshot-Vergleiche repräsentativer Seiten,
• automatisierte Browser-Tests für Warenkorb und Checkout,
• Linkprüfung,
• Kontrolle von Bild- und Dokumentantworten,
• Suchtests mit bekannten Begriffen,
• Prüfung von Produktdetailseiten je Sprache und Kundengruppe.

Fehler brauchen Kategorien und Eigentümer

Eine Liste mit tausenden Importfehlern hilft wenig, wenn nicht erkennbar ist, welche davon kritisch sind und wer sie beheben kann.

Sinnvolle Kategorien:

• technischer Fehler: Datei nicht lesbar, API nicht erreichbar, Datentyp ungültig.
• Mappingfehler: unbekannte Kategorie, Einheit oder Statuszuordnung.
• fachlicher Konflikt: mehrere widersprüchliche Quellen, unzulässige Kombination.
• Datenmangel: Pflichtinformation fehlt in der Quelle.
• erwartete Ausnahme: Datensatz wird bewusst ausgeschlossen.
• Warnung: Datensatz ist nutzbar, benötigt aber spätere Bereinigung.

Jede Kategorie benötigt einen verantwortlichen Bearbeitungsweg. Technische Teams können fehlende Produktfreigaben nicht fachlich entscheiden; Fachabteilungen können keine fehlerhaften API-Authentifizierungen lösen.

Wiederholbarkeit ist ein Qualitätsmerkmal

Eine Migration wird selten nur einmal ausgeführt. Zwischen Testlauf und Go-live ändern sich Quellsysteme, Regeln und Mappings. Der Prozess muss deshalb wiederholbar und idempotent sein.

Das bedeutet:

• derselbe Lauf erzeugt keine Dubletten,
• Zuordnungen bleiben stabil,
• manuell bestätigte Mappings werden nicht verloren,
• Fehler können nach Korrektur gezielt neu verarbeitet werden,
• Test- und Produktivlauf verwenden dieselbe Logik,
• die Ergebnisse jedes Laufs sind vergleichbar.

Manuelle Datenkorrekturen direkt im Zielsystem sind in dieser Phase besonders gefährlich. Der nächste Lauf kann sie überschreiben oder unbemerkt abweichende Datenstände erzeugen. Korrekturen sollten möglichst an der Quelle, im Mapping oder in einer dokumentierten Transformationsregel erfolgen.

Abnahme bedeutet nachvollziehbares Restrisiko

Eine vollständige mathematische Prüfung jedes einzelnen Feldes ist bei großen Datenmengen selten realistisch. Ziel ist deshalb nicht die Behauptung „alle Daten sind garantiert fehlerfrei", sondern ein nachvollziehbares Qualitätsmodell.

Eine belastbare Abnahme beantwortet:

• Welche Daten wurden automatisiert geprüft?
• Welche repräsentativen Fälle wurden fachlich bestätigt?
• Welche bekannten Abweichungen bleiben bestehen?
• Welche Datensätze sind blockiert oder ausgeschlossen?
• Welche Fehlerquote ist für den Go-live akzeptabel?
• Wie werden verbleibende Probleme im Betrieb erkannt und korrigiert?

Damit wird das Restrisiko sichtbar und steuerbar.