E-Commerce-Daten sind nicht nur eine Sammlung von Datensätzen. Sie bilden das operative Gedächtnis des Shops: was das Unternehmen verkauft, wen es bedient, was Customers gekauft haben, welche Inhalte die Auffindbarkeit unterstützen und welche Strukturen Products, Konten, Orders und Seiten miteinander funktionsfähig verbinden.
Bevor Migrationsplanung technisch wird, brauchen Händler ein praktisches Datenmodell. Der sinnvollste Ausgangspunkt ist nicht jedes denkbare Feld im Shop. Es sind die Datengruppen mit dem größten kommerziellen, operativen, kundenbezogenen und kontinuierlichen Wert.
Für die meisten Shops gehören dazu zunächst Products, Customers, Orders, CMS Pages und Blog Posts sowie die unterstützenden Strukturen, die sie verbinden. Diese Gruppen erklären den vollständigen Migrationsscope nicht allein, bilden aber eine klare Grundlage dafür, was nach dem Wechsel von der Quellplattform auf die Zielplattform nutzbar bleiben muss.
Grundlegende Shop-Daten sind geschäftlicher Kontext
Grundlegende E-Commerce-Datengruppen sind wichtig, weil sie die tägliche Arbeit des Shops unterstützen. Products ermöglichen Verkauf. Customers unterstützen Konten und Servicekontinuität. Orders bewahren kommerzielle und operative Historie. CMS Pages und Blog Posts unterstützen Information, Vertrauen, Navigation und Traffic-Kontinuität.
Eine Migration, die nur prüft, ob diese Datensätze auf der Zielplattform vorhanden sind, kann das eigentliche Problem übersehen. Der praktische Test lautet, ob jede Datengruppe weiterhin dieselbe geschäftliche Aufgabe erfüllt wie vor der Migration.
| Datengruppe | Grundlegende Rolle im Shop | Was die Migration erhalten sollte |
|---|---|---|
| Products | Definiert, was das Unternehmen verkauft | Kaufbare Produktstruktur, Preiskontext, Bilder, Kategorisierung, Varianten, Optionen und Auffindbarkeit |
| Customers | Definiert, wen das Unternehmen bedient | Kontoidentität, Adressen, Customer-Kontext, Servicekontinuität und gegebenenfalls Zugriff auf Bestellhistorie |
| Orders | Bewahrt kommerzielle Historie | Bestelldetails, Customer-Beziehung, gekaufte Artikel, Summen, Status und operativen Referenzwert |
| CMS Pages | Enthält dauerhaft relevante Shop-Inhalte | Wichtige Informationsseiten, interne Links, Metadaten und kundenorientierte Content-Struktur |
| Blog Posts | Unterstützt Content und Traffic | Artikel, URLs, Metadaten, Bilder, interne Links sowie Such- und Auffindbarkeitswert |
| Unterstützende Struktur | Macht Kerndatensätze nutzbar | Categories, Attribute, Bilder, Beziehungen, SEO-Felder, Custom Fields und Drittanbieterkontext |
Diese Gruppen sind früh leicht verständlich und zugleich wichtig genug, um die Launch-Qualität zu beeinflussen.
Products definieren, was der Shop verkaufen kann
Products sind meist die sichtbarste Migrationsdatengruppe, weil Customers, Merchandising-Teams und Shop-Manager ständig mit ihnen arbeiten. Ein Product-Datensatz kann Titel, Beschreibungen, Preise, SKUs, Bestandsstatus, Product-Bilder, Categories, Tags, Attribute, Optionen, Varianten, Reviews, Related Products, Cross-Sells, Upsells und weitere Strukturen enthalten, die Kaufentscheidungen beeinflussen.
Der grundlegende Fehler besteht darin, Products als flache Katalogeinträge zu behandeln. In einem funktionierenden Shop hängt ein Product häufig von Beziehungen und Regeln ab:
- ein Parent Product kann von Varianten, Optionen oder konfigurierbarer Logik abhängen;
- Preise können von Steuereinstellungen, Customer Groups, Sale-Regeln oder Custom Fields abhängen;
- Product-Auffindbarkeit kann durch Categories, Attribute, Filter, Tags, Collections oder Suchwerte bestimmt werden;
- Product Pages können von Bildern, Medien, Reviews, Metadaten, internen Links und Related-Product-Logik abhängen;
- Product-Verfügbarkeit kann von Bestandsfeldern, Stock-Regeln, Lagerlogik oder verbundenen Apps abhängen.
Ein Product kann migriert sein und dennoch an Wert verlieren, wenn Customers nicht die richtige Option wählen, den Artikel nicht über den erwarteten Pfad finden, die Product Page nicht verstehen oder den angezeigten Informationen nicht vertrauen können. Die Product-Prüfung sollte deshalb repräsentative Beispiele und nicht nur Datensatzanzahlen umfassen.
Customers bewahren Konto- und Beziehungskontinuität
Customer-Daten beginnen gewöhnlich mit Namen, E-Mail-Adressen, Kontodetails und Adressen. In vielen Shops umfassen sie außerdem Customer Groups, Segmentierungsregeln, Review-Zuordnung, Verknüpfungen zur Bestellhistorie, Loyalty-Kontext, Steuerstatus, Subscription-Kennungen, CRM-Kennungen oder Supportreferenzen.
Customer-Migration ist sensibel, weil das Unternehmen nicht nur Datensätze erhält. Es erhält Kontinuität. Der Shop kann darauf angewiesen sein, dass Customers ihr Konto wiedererkennen, auf relevante Historie zugreifen, korrekte Kommunikation erhalten oder mit Service- und Marketingworkflows verbunden bleiben.
Wichtige Customer-Fragen sind:
- bleibt die Customer-Identität auf der Zielplattform verständlich;
- bleiben Adressen für Service und Bestellreferenz nutzbar;
- unterstützen Customer Groups oder Segmentierung weiterhin die Geschäftsregeln;
- bleiben Customer-Order-Beziehungen nützlich;
- müssen Review-Zuordnung, Loyalty-Kontext oder Subscription-Referenzen separat geprüft werden;
- müssen Login-Erwartungen kommuniziert oder Passwort-Reset-Prozesse geplant werden.
Passwortverhalten verdient frühe Aufmerksamkeit. Manche Migrationen können das Customer-Passwortverhalten wegen Sicherheitsmodellen oder Unterschieden in der Passwortspeicherung nicht exakt erhalten. Dann besteht das praktische Ziel nicht darin, identisches Login-Verhalten zu erzwingen. Der erste Login sollte durch Planung, Kommunikation und einen geeigneten Ansatz zur Kontokontinuität geschützt werden.
Orders bewahren Historie, Service und operative Referenz
Orders sind historische Datensätze, aber nicht nur Historie. Sie unterstützen Customer Service, Prüfung von Rückerstattungen, Referenz zur Auftragsabwicklung, Buchhaltungsunterstützung, Reporting, Steuerprüfung, Fraud Review, Garantiefragen, Subscription-Prüfung und weitere operative Workflows.
Eine nutzbare Order-Migration sollte die Informationen erhalten, die zum Verständnis des Vorgangs erforderlich sind. Dazu können Customer-Details, gekaufte Products, Mengen, Preise, Rabatte, Steuern, Versanddetails, Rechnungsdetails, Zahlungsreferenzen, Statushistorie, Notizen und Metadaten gehören.
Order-Daten können an Nutzen verlieren, obwohl die Order-Anzahl stimmt. Häufige Probleme sind:
- gekaufte Artikel werden schwerer verständlich, weil sich Product-Referenzen geändert haben;
- Customer-Verknüpfungen sind unvollständig oder weniger nützlich;
- Rabatte, Steuern, Versandfelder oder Summen tragen nicht mehr dieselbe Bedeutung;
- Statushistorie entspricht nicht den operativen Erwartungen;
- benutzerdefinierte Order-Felder oder Drittanbieter-Metadaten fehlen oder sind nicht mehr handlungsrelevant;
- Legacy-Historie ist vorhanden, aber für Mitarbeitende schwer nutzbar.
Für viele Unternehmen wird die Qualität der Order-Migration erst nach dem Launch sichtbar, wenn Supportteams reale Customer-Fragen beantworten müssen. Deshalb sollten repräsentative historische Orders früh geprüft werden, insbesondere Orders mit Rückerstattungen, Rabatten, mehreren Sendungen, komplexen Steuern, Custom Fields oder hohem Supportwert.
CMS Pages und Blog Posts unterstützen Content-Kontinuität
Content-Daten erhalten häufig weniger Aufmerksamkeit als Products oder Orders, können aber erheblichen Geschäftswert besitzen. CMS Pages können About-Seiten, Richtlinien, Versandinformationen, Landing Pages, Einkaufsleitfäden, Größeninformationen, Garantieinformationen oder andere dauerhaft relevante Inhalte umfassen. Blog Posts können Suchtraffic, Information, interne Verlinkung, Kaufvertrauen und Long-Tail-Auffindbarkeit unterstützen.
Content-Migration sollte mehr als Text erhalten. Sie kann erforderlich machen:
- Seitentitel, Body Content, Bilder und Medienreferenzen zu erhalten;
- URL-Werte und Redirect-Anforderungen zu berücksichtigen;
- Metadaten und suchbezogene Felder zu bewahren;
- interne Links zu Products, Categories, CMS Pages und Blog Posts zu erhalten;
- Veröffentlichungsstatus, Datumsangaben, Autorenschaft oder Content-Gruppierung zu berücksichtigen;
- layoutabhängige Inhalte auf der Zielplattform zu prüfen.
Eine Content-Seite kann migriert sein und trotzdem an Wert verlieren, wenn Bilder fehlen, URLs ohne geeignete Redirects wechseln, interne Links auf alte Pfade zeigen, Formatierung unlesbar wird oder Metadaten verloren gehen. Content sollte deshalb nach Nutzbarkeit für Customers und Traffic-Kontinuität beurteilt werden, nicht nach Seitenanzahl allein.
Categories, Attribute, Bilder und Beziehungen machen Daten nutzbar
Kerndatensätze funktionieren selten allein. Products brauchen Categories, Attribute, Optionen, Varianten, Bilder und Metadaten. Customers brauchen Adressen, Customer Groups und Order-Verknüpfungen. Orders brauchen Customer-, Product-, Steuer-, Rabatt-, Versand- und Zahlungskontext. CMS Pages und Blog Posts brauchen URLs, interne Links, Bilder und Metadaten.
Diese unterstützenden Strukturen werden leicht unterschätzt, weil sie beim frühen Scoping zweitrangig wirken können. In der Praxis bestimmen sie häufig, ob die migrierten Daten weiterhin funktionieren.
| Unterstützende Struktur | Warum sie wichtig ist |
|---|---|
| Categories und Collections | Erhalten Browse-Pfade, Merchandising-Logik, Landing-Page-Wert und interne Auffindbarkeit. |
| Attribute und Filter | Helfen Customers, Products zu vergleichen, einzugrenzen und zu verstehen. |
| Varianten und Optionen | Erhalten Product-Auswahl und Kaufbarkeit. |
| Bilder und Medien | Unterstützen Vertrauen, Produktbewertung, Content-Kontinuität und vollständige Seiten. |
| SEO-Felder und URLs | Helfen, Suchsichtbarkeit, Klickkontext und Seitenzweck zu erhalten. |
| Beziehungen | Verbinden Products, Customers, Orders, Content, Categories und unterstützende Datensätze. |
| Custom Fields und Metadaten | Tragen geschäftsspezifische Bedeutung, die möglicherweise nicht in das Standardmodell der Zielplattform passt. |
Verändern sich diese Strukturen, kann der Shop gefüllt wirken und sich trotzdem anders verhalten. Deshalb sollte die grundlegende Datenprüfung auch berücksichtigen, wie Datensätze verbunden sind und nicht nur, ob sie existieren.
Kerndatensatzanzahlen helfen beim Sizing, nicht bei der vollständigen Bedeutung
Die Anzahl zentraler Datensätze bietet einen konsistenten Ausgangspunkt für das Sizing des Migrationsscope über wichtige Datengruppen wie Products, Customers, Orders und Blog Posts hinweg. Sie übersetzt Rohvolumen in eine erste Schätzung der benötigten Kapazität für den Migrationspfad.
Datensatzanzahlen ersetzen jedoch keine geschäftliche Prüfung. Shops mit ähnlichen Kerndatenmengen können sehr unterschiedliche Migrationskomplexität haben, abhängig von Product-Struktur, Customer Groups, Anforderungen an historische Orders, Content-Wert, SEO-Sensitivität, Custom Fields, Extension-Daten oder Kennungen externer Systeme.
Core Sizing sollte deshalb zwei Fragen trennen:
| Frage | Was sie beantwortet |
|---|---|
| Wie viele Kerndaten sind beteiligt? | Hilft, die für den Migrationsscope benötigte Kapazität zu schätzen. |
| Wie viel geschäftliche Bedeutung muss erhalten werden? | Hilft, Strukturen, Beziehungen, benutzerdefinierte Daten und Validierungsbedarf zu identifizieren. |
Eine Migration kann korrekt dimensioniert sein und dennoch zusätzliche Planung erfordern, wenn der Shop von komplexen unterstützenden Strukturen abhängt. Das macht das Sizing-Modell nicht falsch. Sizing und Prüfung der Geschäftskontinuität beantworten unterschiedliche Fragen.
Drittanbieter- und benutzerdefinierte Daten können die Grundlagen neu definieren
Viele Shops hängen von Apps, Plugins, Modulen, Extensions, Custom Fields oder externen Systemen ab, die ansonsten grundlegenden Daten zusätzliche Bedeutung geben. Ein Product-Feld kann Suche, Merchandising, Bundles, Subscriptions, Personalisierung oder ERP-Abgleich steuern. Ein Customer-Feld kann Segmentierung, Steuerbehandlung oder Loyalty-Logik beeinflussen. Ein Order-Feld kann Auftragsabwicklung, Reporting, Versandautomatisierung, Fraud Review oder Customer Support unterstützen.
Wenn solche Felder reales Geschäftsverhalten beeinflussen, sollten sie nicht als Kleinigkeiten abgetan werden. Sie können Mapping, Konfiguration, Filterung, Transformation oder benutzerdefinierte Migrationslogik erfordern.
Einige Fälle lassen sich durch Feldmapping, Wertnormalisierung, Konfigurationsänderungen oder selektive Filterung lösen. Breitere Anpassungen, nicht unterstützte Extension-Daten, externe Kennungen, Custom-Platform-Bedingungen und individuelle Logik erfordern eine individuelle Analyse.
Der Kernpunkt ist einfach: Grundlegende Daten sind nur dann grundlegend, wenn das Unternehmen sie grundlegend nutzt. Sobald Drittanbieter- oder Custom-Logik reale Ergebnisse steuert, werden diese Daten Teil der Migrationsanforderung.
Praktische Prüffragen für grundlegende E-Commerce-Daten
Eine nützliche frühe Prüfung sollte jede Datengruppe mit dem Geschäftsergebnis verbinden, das sie unterstützt. Ziel ist nicht, jedes Feld sofort zu untersuchen. Es geht darum, zu bestimmen, welche Datensätze und Strukturen getestet, geschützt oder früh eskaliert werden sollten, bevor Annahmen feststehen.
| Prüffrage | Warum sie wichtig ist |
|---|---|
| Welche Products sind am komplexesten oder am wertvollsten? | Simple Products zeigen selten das vollständige Risiko der Product-Struktur. |
| Welche Customer Groups oder Kontofälle brauchen Kontinuität? | Die Qualität der Customer-Migration hängt von mehr als Namen und E-Mail-Adressen ab. |
| Welche historischen Orders müssen operativ nutzbar bleiben? | Support, Rückerstattungen, Reporting und Prüfung der Auftragsabwicklung können von erhaltener Order-Bedeutung abhängen. |
| Welche CMS Pages und Blog Posts unterstützen Vertrauen, Traffic oder Conversion? | Content-Wert kann durch Änderungen an URLs, Metadaten, Bildern oder internen Links verloren gehen. |
| Welche Categories, Attribute, Bilder und Beziehungen tragen Geschäftswert? | Unterstützende Strukturen bestimmen häufig, ob Kerndatensätze nutzbar bleiben. |
| Welche Apps, Plugins, Module, Extensions oder externen Systeme ergänzen wichtige Datenbedeutung? | Diese Ebenen können Mapping, Transformation, individuelles Migrationsdesign oder tiefere Planung erfordern. |
Diese Fragen schaffen eine bessere Grundlage für repräsentative Tests, Scope-Diskussion und spätere Validierung, weil sie die Daten mit echtem Geschäftswert priorisieren.
Häufige Fehler bei der Planung grundlegender Daten
Mehrere Fehler wiederholen sich in E-Commerce-Migrationsprojekten.
Der erste ist die Annahme, dass Products, Customers, Orders, CMS Pages und Blog Posts vollständig sind, nur weil die Datensätze vorhanden sind. Vorhandensein ist erst der Anfang. Die Daten müssen weiterhin nutzbar sein.
Der zweite besteht darin, sich auf die größte Datengruppe zu konzentrieren und die empfindlichste zu übersehen. Ein Shop kann viele Products haben, aber stark von einer kleineren Menge historischer Orders, Customer Groups, Custom Fields oder trafficstarker Content-Seiten abhängen.
Der dritte Fehler ist, unterstützende Struktur als optional zu behandeln. Categories, Attribute, Varianten, Bilder, Metadaten, Beziehungen und interne Links tragen häufig die Bedeutung, auf die Customers und Mitarbeitende angewiesen sind.
Der vierte Fehler ist, benutzerdefinierte und Drittanbieterdaten zu spät zu erkennen. Wenn Apps, Plugins, Module, Extensions oder externe Systeme Shop-Funktionen prägen, müssen diese Abhängigkeiten früh geprüft werden.
Der fünfte ist die Verwechslung von grundlegendem Daten-Sizing mit Migrationsabnahme. Sizing hilft, den Scope zu definieren. Abnahme verlangt den Nachweis, dass der migrierte Shop weiterhin geschäftlich nutzbar ist.
Fazit
Products, Customers, Orders, CMS Pages, Blog Posts und ihre unterstützenden Strukturen bilden die praktische Grundlage der E-Commerce-Migrationsplanung. Diese Datengruppen erklären, was der Shop verkauft, wen er bedient, welche Historie er bewahrt und welcher Content Kundenvertrauen und Traffic-Kontinuität unterstützt.
Der sicherste Planungsansatz behandelt grundlegende Daten als geschäftlichen Kontext und nicht als isolierte Datensätze. Anzahlen sind wichtig, entscheidender ist jedoch, ob die migrierten Daten nach dem Launch weiterhin Kauf, Kontokontinuität, Serviceprüfung, operative Referenz, Content-Wert und Auffindbarkeit unterstützen.
Wenn der Shop von Custom Fields, Drittanbieterlogik, externen Kennungen oder ungewöhnlicher Plattformstruktur abhängt, klären Sie diese Anforderungen früh und weisen Sie die notwendige Expertise für ihre Interpretation zu. Der Migrationsplan sollte gewöhnliches Mapping von Transformation, individuellem Migrationsdesign und zielseitiger Implementierung unterscheiden.
Häufige Fragen
Welche E-Commerce-Datengruppen sollten vor einer Migration zuerst geprüft werden?
Die wichtigsten Ausgangsgruppen sind gewöhnlich Products, Customers, Orders, CMS Pages und Blog Posts. Unterstützende Strukturen wie Categories, Attribute, Varianten, Optionen, Bilder, SEO-Felder, URLs, Beziehungen, Custom Fields und Metadaten sollten ebenfalls geprüft werden, weil sie bestimmen, wie nützlich Kerndatensätze nach der Migration bleiben.
Warum sind Products mehr als einfache Katalogdatensätze?
Products hängen häufig von Varianten, Optionen, Attributen, Categories, Bildern, Reviews, Related Products, Preiskontext, Bestandslogik und Drittanbieterfeldern ab. Ein Product kann auf der Zielplattform existieren, während Auswahl, Auffindbarkeit, Merchandising oder Kaufverhalten schlechter werden.
Warum müssen Order-Daten sorgfältig geprüft werden?
Orders bewahren historischen und operativen Kontext. Sie können Customer Service, Rückerstattungen, Reporting, Prüfung der Auftragsabwicklung, Buchhaltungsunterstützung und interne Abläufe unterstützen. Übereinstimmende Order-Anzahlen beweisen nicht, dass die Bestellhistorie für Mitarbeitende oder Customers nutzbar bleibt.
Sollten CMS Pages und Blog Posts früh in die Migrationsplanung einbezogen werden?
Ja. CMS Pages und Blog Posts können Vertrauen, Navigation, SEO-Kontinuität, interne Links und Conversion unterstützen. Sie sollten hinsichtlich Content-Qualität, URL-Verhalten, Metadaten, Bildern, Formatierung und Links zu wichtigen Products oder Categories geprüft werden.
Erklären Datensatzanzahlen die gesamte Migrationskomplexität?
Nein. Datensatzanzahlen helfen beim Sizing des Kern-Migrationsscope, erklären aber geschäftliche Bedeutung, benutzerdefinierte Daten, Drittanbieterlogik, Beziehungen, SEO-Sensitivität oder Validierungsaufwand nicht vollständig. Sizing und Prüfung der Geschäftskontinuität sollten als getrennte Planungsfragen behandelt werden.
Wann benötigen grundlegende Daten ein individuelles Migrationsdesign?
Nicht standardmäßige Behandlung kann nötig sein, wenn wichtige Daten von nicht unterstützten Extension-Daten, externen Kennungen, Custom-Platform-Bedingungen, individuellen Strukturen oder benutzerdefinierter Migrationslogik abhängen. Engere Anforderungen können durch Mapping, Wertnormalisierung, Konfiguration oder selektive Filterung gelöst werden.