Daten-Mapping bei der eCommerce-Migration: So bleiben benutzerdefinierte Felder, Varianten und SKUs korrekt verknüpft

Daten-Mapping bei einer eCommerce-Migration legt fest, wo Quelldaten auf der neuen Plattform landen, wie ihre Bedeutung erhalten bleibt und welche Datensätze miteinander verknüpft bleiben müssen. Richtig umgesetzt sorgt es dafür, dass eine Variante dem richtigen Produkt zugeordnet bleibt, eine SKU mit dem richtigen verkaufbaren Artikel verbunden ist und eine Bestellung beim richtigen Kunden bleibt.

Für Shopbetreiber bedeutet das ganz praktisch mehr Sicherheit: Kunden können die gewünschte Größe auswählen, das Lager erhält den richtigen Artikelcode und der Kundenservice kann eine alte Bestellung nachvollziehen. Ein Katalog kann vollständig aussehen, obwohl eine dieser Verknüpfungen falsch ist. Deshalb sollte das Mapping vor der Full Migration sorgfältig geprüft werden.

Was verbindet Daten-Mapping eigentlich?

Jede Plattform hat ein Schema, also eine Struktur, mit der Produkte, Kunden, Bestellungen und deren Felder organisiert werden. Zwei Shops können dieselbe Produktseite anzeigen und die Informationen im Hintergrund trotzdem unterschiedlich speichern. Mapping verbindet diese Strukturen entsprechend dem gewünschten Ergebnis.

Drei Begriffe machen den Ablauf leichter verständlich:

Feld-Mapping: Festlegen, wo ein Wert im Ziel gespeichert werden soll, zum Beispiel eine Lieferantenreferenz oder eine steuerliche Kundenkennung.

Beziehungs-Mapping: Verbindungen zwischen Datensätzen erhalten, etwa zwischen einem Produkt und seinen Varianten oder zwischen einem Kunden und seinen Bestellungen.

Datentransformation: Einen Wert nach einer vereinbarten Regel verändern, zum Beispiel ein Gewicht von Gramm in Kilogramm umrechnen.

Diese Entscheidungen gehören gemeinsam in einen Migrationsplan, erfüllen aber unterschiedliche Aufgaben. Den Wert „500“ in ein Gewichtsfeld zu verschieben macht daraus nicht automatisch 0,5 Kilogramm. Ebenso erzeugt das Kopieren einer Produkt-ID in eine Bestellung keine gültige Beziehung, wenn das Ziel andere IDs vergibt.

Begleiten Sie ein Produkt durch die Migration

Stellen Sie sich einen Outdoor-Shop vor, der eine Trail Jacket in zwei Farben und drei Größen verkauft. Die marineblaue Variante in Größe M hat die SKU TJ-NV-M, einen eigenen Lagerbestand und einen Barcode. Das Produkt enthält außerdem ein Feld mit Pflegehinweisen, während jede Variante einen eigenen Lieferantencode besitzt.

Die Migration muss erhalten, welche Informationen zum gesamten Produkt gehören und welche nur zu einer bestimmten Kombination. Wird ein variantenspezifischer Lieferantencode auf das Hauptprodukt verschoben, könnten am Ende alle Größen auf denselben Lieferantenartikel verweisen.

Die folgende Mapping-Planung dient zur Veranschaulichung. Die Bezeichnungen beschreiben das gewünschte Ergebnis und garantieren nicht, dass diese Felder auf jedem Migration Path verfügbar sind.

Bei einer Migration von WooCommerce zu Shopify sollten Sie mit den unterstützten Daten für genau diese Route beginnen. WooCommerce beschreibt Variationen mit eigenen Preis-, Bestands- und Bildeinstellungen; auch Shopifys Variantenmodell verbindet eine verkaufbare Kombination mit Produkt- und Bestandsinformationen. Ein ähnliches Verhalten im Storefront bedeutet trotzdem nicht, dass Feld- und Beziehungsprüfungen entfallen können.

Wie bleiben Varianten und SKUs miteinander verknüpft?

Eine Variante steht für eine verkaufbare Kombination. Eine SKU ist eine geschäftliche Kennung eines Artikels. Eine internal ID identifiziert einen Datensatz innerhalb eines bestimmten Systems. Wer diese Begriffe gleichsetzt, riskiert vermeidbare Zuordnungsfehler.

Hauptprodukt und jede verkaufbare Kombination getrennt halten

Bei der Trail Jacket muss „Navy / Medium“ mit dem richtigen Hauptprodukt verbunden bleiben und den korrekten Preis, Bestand, das richtige Bild und den richtigen Barcode behalten. Eine gute Prüfung verfolgt die ausgewählte Kombination vom Storefront bis in die Bestellung. Allein die Tatsache, dass sechs Varianten importiert wurden, sagt noch nichts darüber aus, ob ihre Attribute stimmen.

Unterscheiden Sie Varianten außerdem von Personalisierungsfeldern. Eine Gravurnachricht oder Liefernotiz kann einen Kauf beschreiben, ohne einen separat gelagerten Artikel darzustellen. Wenn jede Option in eine Variante umgewandelt wird, kann sich die Katalogstruktur verändern und Kombinationen erzeugen, die der Shop nie verkauft hat.

Prüfen Sie, ob Ihre SKUs zuverlässige Zuordnungsschlüssel sind

SKUs können Datensätze gut zuordnen, wenn sie ausgefüllt, im vereinbarten Umfang eindeutig und stabil sind. Weniger zuverlässig sind sie, wenn ein Hauptprodukt und seine Varianten dieselbe SKU teilen, mehrere Quellshops dieselben Codes wiederverwenden oder ältere Produkte leere Werte besitzen.

• Suchen Sie auf Produkt- und Variantenebene nach fehlenden und doppelten SKUs.
• Erhalten Sie aussagekräftige Formatierungen wie führende Nullen, Satzzeichen sowie Groß- und Kleinschreibung.
• Legen Sie fest, wie Quelldatensätze mit bereits vorhandenen Artikeln im Ziel abgeglichen werden sollen.
• Dokumentieren Sie Ausnahmen, statt Codes automatisch umzubenennen, die von Lager- oder Fulfillment-Systemen verwendet werden.

Ist eine SKU kein sicherer Schlüssel, braucht die Migration eine andere unterstützte Zuordnungsmethode oder eine vereinbarte benutzerdefinierte Regel. Eine Querverweistabelle zwischen Quell- und Ziel-IDs kann die Beziehung erhalten, selbst wenn das Ziel neue internal IDs erzeugt.

Wichtig: Das Beibehalten einer SKU verbindet ein ERP, Lagersystem oder Marketplace-Feed nicht automatisch erneut. Prüfen Sie, welche Kennung jede Integration verwendet, und testen Sie die Verbindung separat.

Wohin gehören benutzerdefinierte Felder?

Beginnen Sie mit dem Zweck des Feldes und wählen Sie dann das Ziel. Eine Pflegeanweisung ist lesbarer Text. Ein Lieferantencode ist eine Kennung. Eine steuerliche Kundennummer kann einen Geschäftsprozess unterstützen. Alle drei in ein Beschreibungsfeld zu schreiben bewahrt zwar die Zeichen, macht die Daten aber schwerer nutzbar.

Prüfen Sie bei jedem benutzerdefinierten Feld vier Punkte:

• Zugehörigkeit: Gehört das Feld zu einem Produkt, einer Variante, einem Kunden, einer Bestellung oder einer Bestellposition?
• Typ: Soll das Ziel den Wert als Text, Zahl, Datum, Wahr/Falsch-Wert oder Referenz speichern?
• Bedeutung: Werden Einheiten, zulässige Werte, leere Werte und Formatierungen konsistent interpretiert?
• Verwendung: Welches Theme, welche App, welcher Filter oder welche Integration muss das Feld lesen?

Speichern Sie beispielsweise einen Lieferantencode wie 00127 als Kennung und nicht als Menge. Andernfalls können bei einer numerischen Umwandlung die führenden Nullen verloren gehen. Enthält ein Quellfeld mehrere Werte, klären Sie, ob das Ziel eine Liste akzeptiert oder eine andere unterstützte Struktur benötigt.

Ein Feld kann auch erfolgreich migriert sein, ohne im Storefront zu erscheinen. Speicherung, Anzeige, Filterung und App-Verhalten müssen separat geprüft werden. Unser Leitfaden zu Metadaten, benutzerdefinierten Feldern und Erweiterungen erklärt diese Unterschiede; der Artikel zur Strukturierung benutzerdefinierter Felder und Account-Workflows zeigt zudem ihre Bedeutung für Großhandelsshops.

Bevor Sie ein Felddesign festlegen, teilen Sie mit Next-Cart einen gewöhnlichen Datensatz und einen schwierigen Sonderfall. Den Quellwert zusammen mit dem gewünschten Ergebnis zu zeigen ist deutlich hilfreicher als die pauschale Bitte, „alle benutzerdefinierten Felder zu migrieren“.

Auch Kategorien, Kunden und Bestellungen brauchen Mapping

Kategorien: Platzierung und gewünschte Navigation erhalten

Eine Jacke kann sowohl zu Outerwear als auch zu Winter Essentials gehören. Entscheiden Sie, wie diese Zuordnungen und eine mögliche Eltern-Kind-Struktur der Kategorien im Ziel aussehen sollen. Prüfen Sie sowohl die Platzierung des Produkts als auch das Vorhandensein jeder Kategorie. Organisiert das Ziel Collections anders, ist eine explizite Regel hilfreicher als ein Abgleich nur über den Kategorienamen.

Kunden: Identität und Geschäftskontext schützen

E-Mail-Adresse, Rechnungsadresse, Steuerkennung und Kontoklassifizierung eines Kunden erfüllen unterschiedliche Zwecke. Legen Sie die Zuordnungsrichtlinie fest, bevor Sie Datensätze zusammenführen. Eine gemeinsame E-Mail-Adresse über mehrere Shops hinweg berechtigt nicht automatisch dazu, deren Geschäftskonten zusammenzuführen.

Bei Großhandelskunden müssen auch migrierte Gruppenkennzeichnungen oder Steuerfelder gegen die Konto- und Preiskonfiguration im Ziel geprüft werden. Dass der Wert gespeichert ist, bedeutet nicht automatisch, dass der damit verbundene Workflow wiederhergestellt wurde.

Bestellungen: Die Bedeutung der ursprünglichen Transaktion erhalten

Eine Bestellung verbindet einen Kunden mit gekauften Artikeln, Mengen, Preisen, Steuern, Rabatten und Versanddetails. Historische Werte sollten die ursprüngliche Transaktion widerspiegeln und nicht stillschweigend anhand des heutigen Katalogs neu berechnet werden.

Berücksichtigen Sie Gastbestellungen, gelöschte Produkte und eingestellte Varianten. Wenn eine aktive Produktbeziehung nicht wiederhergestellt werden kann, legen Sie fest, wie unterstützte historische Positionsdetails erhalten bleiben. Prüfen Sie die Bestellung aus Sicht des Kundenservice: Können Sie erkennen, was gekauft wurde, und den Gesamtbetrag nachvollziehen?

Wie lässt sich das Mapping vor dem Go-live validieren?

Nutzen Sie Demo Migration, um repräsentative Datensätze zu prüfen, und wiederholen Sie die relevanten Kontrollen nach Full Migration und jedem genehmigten Folgelauf. Enthält die Demo-Stichprobe keinen kritischen Edge Case, planen Sie zusätzliche Validierung ein, bevor Sie die Anforderung als bestätigt betrachten.

Stellen Sie bewusst einen kleinen Testsatz mit schwierigen Datensätzen zusammen:

• Ein Produkt mit mehreren Varianten, unterschiedlichen Bildern und variantenspezifischen benutzerdefinierten Feldern.
• Eine fehlende oder doppelte SKU sowie eine Kennung mit führenden Nullen.
• Ein Produkt in mehreren Kategorien und ein Kunde mit Geschäftsfeldern.
• Eine rabattierte Bestellung, eine Gastbestellung und eine Bestellung mit einem eingestellten Artikel.

Dokumentieren Sie für jedes Beispiel den Quellwert, das erwartete Zielergebnis, das tatsächliche Ergebnis und jede Abweichung. Vergleichen Sie drei Ebenen: Datensatzanzahl, Feldwerte und Beziehungen. Erklären Sie Mengenunterschiede, die durch genehmigte Filterung, Zusammenführung oder Umstrukturierung entstehen; gleiche Gesamtzahlen beweisen nicht automatisch Korrektheit.

Schließen Sie mit Verhaltenstests ab. Wählen Sie eine Variante, prüfen Sie ihre angezeigten Informationen, legen Sie sie in den Warenkorb und kontrollieren Sie den resultierenden Artikel. Prüfen Sie, wo relevant, die Bestellhistorie des Kunden und testen Sie Integrationen, die migrierte Kennungen verwenden. So verbinden Sie Datenbankgenauigkeit mit dem täglichen Shopbetrieb.

Vor der Freigabe: Beheben Sie kritische Abweichungen, testen Sie betroffene Datensätze erneut und bewahren Sie die freigegebenen Mapping-Regeln in den Projektnotizen auf. Wenn sich Regeln später ändern, prüfen Sie deren Auswirkung auf bereits migrierte Daten, bevor Sie die Migration erneut ausführen.

Wann braucht Mapping eine Custom Migration?

Benutzerdefinierte Felder bedeuten nicht automatisch, dass jedes Projekt individuelle Entwicklung benötigt. Entscheidend ist, ob das gewünschte Ergebnis zum unterstützten Verhalten des gewählten Migration Path und der anwendbaren Add-ons passt.

Next-Carts Advanced Data Mapping leitet unterstützte Quellfelder an kompatible Ziele weiter. Data Transformation verarbeitet unterstützte Wertänderungen. Verfügbare Felder und Vorgänge hängen von der aktiven Migration ab; bestätigen Sie daher die genaue Anforderung, bevor Sie ein Add-on auswählen.

Standard Migration eignet sich für unterstützte Aufgaben, die Sie selbst verwalten. Managed Migration ergänzt die von Next-Cart durchgeführte Umsetzung innerhalb des unterstützten Umfangs. Keines der beiden Angebote sollte als Zusage verstanden werden, beliebiges benutzerdefiniertes App- oder Datenbankverhalten nachzubilden.

Custom Migration sollte geprüft werden, wenn Ihr Projekt nicht unterstützte Extraktion, individuelle Zuordnung, ungewöhnliche Beziehungen oder maßgeschneiderte Logik benötigt. Beispiele sind die Zusammenführung mehrerer Quellkataloge anhand geschäftsspezifischer Regeln oder die Übertragung von App-eigenen Daten in eine andere Zielstruktur.

Bereiten Sie Beispieldatensätze, das gewünschte Zielergebnis, Zuordnungs- und Transformationsregeln, beteiligte Systeme sowie klare Abnahmekriterien vor. So erhält das Team eine konkrete Grundlage, um Machbarkeit und Arbeitsumfang zu beurteilen.

Geben Sie Ihrem neuen Shop eine klare Datengrundlage

Gutes Mapping erhält die Bedeutung Ihres Katalogs und Ihrer Kundenhistorie auch beim Plattformwechsel. Wenn Produktstruktur, Kennungen, benutzerdefinierte Felder und Transaktionsbeziehungen gemeinsam geprüft werden, kann das Team Probleme leichter erkennen und das Ergebnis fundiert freigeben.

Möchten Sie die Daten Ihres Shops prüfen? Fordern Sie eine Demo bei Next-Cart an und bringen Sie repräsentative Datensätze zur Prüfung mit. Weitere Erklärungen zu den Systemen hinter einer Migration finden Sie in unseren Artikeln zur eCommerce-Technologie.