Wenn BigCommerce als Zielplattform ausgewählt wird, sollte die Vorbereitung zuerst festlegen, wie aus dem Quellshop ein beherrschbarer BigCommerce-Katalog wird, bevor ein Migrationslauf beginnt. Products, Varianten, Optionen, Modifier, benutzerdefinierte Felder, Metafields, Categories, Price Lists, Customer Groups, Channels, Customers, Orders, Inhalte und Integrationen sind getrennte Verantwortungsbereiche. Eine Quellplattform kann mehrere davon in einem Product- oder Extension-Datensatz zusammenführen.
Das Vorbereitungspaket sollte für jede wichtige Beziehung den vorgesehenen Ziel-Owner benennen, repräsentative Nachweise enthalten, eine verantwortliche Person zuordnen und einen klaren Bereitschaftszustand definieren. Dadurch wird die Auswahl repräsentativer Migrationsstichproben aussagekräftig und auf konkrete Quelldaten zurückführbar.
Betriebs- und Katalogumfang für BigCommerce festlegen
Definieren Sie zuerst die vorgesehenen Betriebsgrenzen in BigCommerce.
| Bereich | Vorbereitungsentscheidung | Nachweis |
|---|---|---|
| Katalogidentität | Welche Quelldatensätze zu Products und Varianten werden | Product-Family-Map mit Quell-IDs und SKU-Ownership |
| Käuferauswahl | Welche Werte Varianten, Modifier, benutzerdefinierte Felder oder App-Daten sind | Repräsentative Optionsmatrix |
| Katalogorganisation | Welche Source Categories, Marken, Filter und Landingpages erhalten bleiben | Übersicht zu Categories und Auffindbarkeit |
| Kommerzieller Kontext | Welche Customer Groups, Price Lists, Mengenpreise, Promotions und Währungen relevant sind | Inventar der Preisbeziehungen |
| Channel-Umfang | Welche Products, Categories, Inhalte, Währungen und Locales zu jedem Channel bzw. jeder Storefront gehören | Channel-Zuordnungsmatrix |
| Benutzerdefinierte Daten | Welche Datensätze benutzerdefinierte Felder, Metafields, Apps oder externen Systemen gehören | Feld- und Abhängigkeitsregister |
Dokumentieren Sie, ob der „Shop“ im Quellsystem eine einzelne Storefront, mehrere regionale Storefronts, einen Marketplace-Channel, eine Marke, einen Geschäftsbereich oder einen Customer-spezifischen Katalog darstellt. Ähnliche Product-Datensätze können eine gemeinsame BigCommerce-Identität mit Channel-Zuordnungen benötigen oder getrennte Identitäten, wenn sich die kommerzielle Ownership unterscheidet. Dieselbe Grenze sollte konsistent für Categories, Inhalte, Preise, Währungen und Customer-Zugriff gelten, damit der Zielkatalog keine Datensätze aus unterschiedlichen Verkaufskontexten vermischt.
Zugriffe, Exporte und Quelldefinitionen vorbereiten
Bereiten Sie die Zugriffe auf Quellshop und BigCommerce vor, die zum Abrufen und Interpretieren der relevanten Daten benötigt werden. Bewahren Sie datierte Kopien auf, damit das Team den Ausgangszustand auch dann noch nachvollziehen kann, wenn sich der Live-Shop vor der Migration verändert.
Sammeln Sie:
- Administratorzugriff auf Quellshop und BigCommerce mit geeigneten Berechtigungen;
- Exporte von Products, Varianten, Categories, Customers, Orders, Inhalten und Redirects, soweit verfügbar;
- Product-Medien und Dokumente, wenn Quelllinks ablaufen oder Authentifizierung benötigen können;
- Nachweise zu Price Lists, Customer Groups, Mengenpreisen, Promotions und Währungen;
- Channel- oder Storefront-Zuordnungen und Listen lokalisierter Inhalte;
- Verzeichnisse zu benutzerdefinierte Felder, Metafields, Apps und externen Kennungen;
- Berichte aus ERP-, PIM-, WMS-, CRM-, Marketplace- oder Buchhaltungssystemen, die gemeinsame Schlüssel identifizieren;
- ein Änderungsprotokoll für Datensätze, die sich wahrscheinlich vor dem Migrationsfenster ändern.
| Nachweis | Owner | Bereitschaftskriterium |
|---|---|---|
| Zugriffsprotokoll | Shop-Administratoren | Benötigte Bereiche von Quelle und BigCommerce sind erreichbar |
| Exportarchiv | Daten-Owner | Dateien lassen sich öffnen, enthalten die erwarteten Datensätze und tragen ein Exportdatum |
| Feldverzeichnis | Katalog- oder technischer Owner | Wichtige Felder haben Zweck, Typ, Parent-Objekt und Ziel-Owner |
| Preisnachweise | Kommerzieller Owner | Basis-, Gruppen-, Listen-, Mengen- und Promotion-Kontexte sind getrennt dokumentiert |
| Channel-Inventar | Channel-Owner | Für jeden Channel sind Product-, Category-, Content-, Locale- und Währungsumfang definiert |
Products, Varianten, Optionen und Modifier vorbereiten
BigCommerce unterscheidet verkaufbare Varianten von Buyer Modifiern und beschreibenden Product-Daten. Bereiten Sie Quellbeispiele vor, die diese Unterschiede sichtbar machen.
Nehmen Sie insbesondere auf:
- einfache Products;
- Products mit Child-SKUs und Variantenwerten für Preis, Bestand, Bild, Gewicht, Barcode oder externe IDs;
- Quelloptionen, die ein Product verändern, ohne einen eigenen Bestand zu erzeugen;
- Personalisierung, Datei-Upload, Datum, Maßangaben oder Serviceauswahl;
- Products mit benutzerdefinierte Felder, Metafields, ausführlichen Spezifikationen oder Kompatibilitätsdaten;
- Bundles, Kits, Subscriptions, Garantien oder App-eigene Konfigurationen;
- Products mit unterschiedlichen Channel-Zuordnungen;
- Products, die mit externen Katalog- oder Bestandssystemen synchronisiert werden.
| Verhalten im Quellshop | Vorbereitungsentscheidung für BigCommerce | Benötigter Nachweis |
|---|---|---|
| Auswahl identifiziert eine separate verkaufbare Einheit | Product- und Varianten-Ownership definieren | Parent-/Child-IDs, Optionswerte, SKU, Preis, Bestand, Bilder und externe IDs |
| Auswahl verändert das Product, hat aber keinen eigenen Bestand | Modifier oder andere Zielbeziehung definieren | Eingabetyp, erlaubte Werte, Preis-/Gewichtseffekt und Beispiel einer Order Line |
| Wert beschreibt das Product | benutzerdefiniertes Feld, Metafield, Content- oder App-Owner definieren | Feldtyp, kontrollierte Werte sowie Anzeige- und Integrationsverbraucher |
| Kombination folgt individueller Logik | App oder individuellen Ziel-Owner definieren | Regelbeispiele, Komponenten-IDs und historische Order-Nachweise |
Normalisieren Sie Optionsnamen und -werte vor dem Import. Inkonsistente Bezeichnungen können getrennte Optionssets und schwache Filter erzeugen, obwohl das zugrunde liegende Geschäftskonzept identisch ist.
Categories, Preise, Customer Groups und Channels vorbereiten
Bei der Vorbereitung für BigCommerce sollten Auffindbarkeit und Preislogik als zusammenhängende, aber getrennte Strukturen behandelt werden.
Für Categories sollten Sie vorbereiten:
- Quellhierarchie und Product-Zuordnungen;
- Marken- und Herstellerbeziehungen;
- Filter- oder Facettenwerte;
- Landingpage-Inhalte und Metadaten;
- interne oder veraltete Categories;
- Channel-spezifische Category-Zuordnungen;
- URLs und Redirect-Prioritäten.
Für Preise benötigen Sie getrennte Nachweise zu Basispreisen, Angebotspreisen, Mengenpreisen, Customer-Group-Preisen, Price Lists, Coupons sowie App- oder ERP-gesteuerten Preisen.
| Kommerzielle Beziehung | Vorbereitungsfrage | Bereitschaftsnachweis |
|---|---|---|
| Customer Group | Welche Customers gehören dazu, und welche Zugriffs- oder Preisbedeutung trägt die Gruppe? | Customer-Beispiele und Zusammenfassung der Gruppenregel |
| Price List | Welche Products oder Varianten, Währungen, Customers oder Channels verwenden sie? | Price-List-Export und Zuordnungsübersicht |
| Mengenpreis | Welche Mengenschwellen und Käuferkontexte gelten? | Product-Beispiele mit Schwellenwerten |
| Channel-Zuordnung | Welche Products und Categories gehören zu welchem Channel? | Channel-Katalogmatrix |
| Promotion | Ist die Regel aktuell, historisch oder veraltet? | Regel-Owner und Entscheidung: erhalten, neu aufbauen oder einstellen |
Historische Order-Preise dürfen nicht mit der aktiven Preiskonfiguration zusammengeführt werden. Historische Orders benötigen ihre aufgezeichneten Werte; das künftige BigCommerce-Preismodell benötigt separat vorbereitete Regeln und Zuordnungen.
Customers und historische Orders vorbereiten
Bereiten Sie Customer-Beispiele für Einzelkäufer, Guest Orders, mehrere Adressen, Customer Groups, Steuerstatus, Company- oder B2B-Kontext, benutzerdefinierte Felder, Marketingpräferenzen, Loyalty, Subscriptions und externe Account-IDs vor.
Bereiten Sie Order-Beispiele vor für:
- bezahlte, ausstehende, stornierte, erstattete und teilweise erstattete Orders;
- mehrere Fulfillment-Zustände und Versandarten;
- Rabatte, Coupons, Geschenkgutscheine, Steuern, Abgaben und manuelle Anpassungen;
- Varianten- und Modifier-Auswahlen;
- Customer-Group- oder Price-List-Kontext;
- Channel- oder Marketplace-Ursprung;
- ERP-, Buchhaltungs-, CRM- und Fulfillment-Referenzen.
| Vorbereitungsfrage | Nachweis | Bereitschaftskriterium |
|---|---|---|
| Wie werden doppelte Customers behandelt? | Dublettenbeispiele und Matching-Schlüssel | Regeln für getrenntes Behalten und Zusammenführen sind dokumentiert |
| Welche Customer Groups bleiben bestehen? | Gruppenliste und kommerzieller Zweck | Jede erhaltene Gruppe hat einen Owner und eine zugehörige Regel |
| Welche Order-Details müssen Support-Teams sehen? | Repräsentatives Order-Paket | Lines, Modifier, Summen, Status, Refunds und Referenzen sind erklärt |
| Welche externen IDs bleiben operativ relevant? | Systemübergreifende Key-Map | Jeder Schlüssel ist der richtigen Objektebene zugeordnet |
| Welche sensiblen Felder werden nicht benötigt? | Freigegebener Feldumfang | Ausgeschlossene Daten sind vor der Migration dokumentiert |
Inhalte, URLs und Redirect-Eingaben vorbereiten
Erstellen Sie ein Routeninventar für Products, Categories, Marken, CMS Pages, Blog Posts, Kampagnenseiten, Dateien und lokalisierte Inhalte. Berücksichtigen Sie bekannte Relevanz für Traffic, Umsatz, Backlinks, Paid Media, Customer Service oder Compliance.
Für jede priorisierte Route dokumentieren Sie:
- Quellpfad;
- vorgesehenes BigCommerce Product, Category, Seite, Blog Post, Channel oder externes Ziel;
- Content-Owner;
- Anforderungen an Metadaten und interne Links;
- Channel- und Locale-Umfang;
- Redirect-Anforderung oder Entscheidung zur Stilllegung.
Trennen Sie Content-Datensätze von Theme- und Page-Builder-Darstellung. Eine Quellseite kann wiederverwendbare Inhalte, Product-Referenzen, Formulare, Widgets, Skripte und Layoutdefinitionen enthalten, die unterschiedliche Ziel-Owner benötigen.
Apps, Metafields und externe Systeme erfassen
Erstellen Sie ein Abhängigkeitsregister für Apps, individuelle Skripte, benutzerdefinierte Felder, Metafields, Webhooks und verbundene Systeme. Berücksichtigen Sie Reviews, Suche, Subscriptions, Bundles, Loyalty, B2B, Personalisierung, Steuern, Versand, Zahlungen, Marketplaces, ERP, PIM, WMS, CRM, Buchhaltung, Analytics und Consent-Systeme.
Dokumentieren Sie für jede Abhängigkeit:
- geschäftlichen Zweck;
- erzeugte oder veränderte Datensätze;
- zugehörige Products, Customers, Orders oder Inhalte;
- aktuellen Daten-Owner und künftigen Owner;
- Export- oder API-Nachweis;
- externe Kennungen;
- ob die Abhängigkeit weitergeführt, ersetzt oder eingestellt wird.
Das Abhängigkeitsregister ist erst dann ausreichend, wenn kein wichtiger benutzerdefinierter Wert lediglich als „aus einer App“ beschrieben wird.
Repräsentative BigCommerce-Migrationsstichproben auswählen
Wählen Sie einen kompakten Stichprobensatz, der gewöhnliche und außergewöhnliche Beziehungen abdeckt.
| Stichprobe | Zweck der Vorbereitung |
|---|---|
| Einfaches Product | Gewöhnliches Muster für Product, Category, Medien, Preis und Bestand festlegen |
| Variantenreiches Product | Product-/Variantenidentität, Optionen, Bestand, Bilder und externe IDs sichtbar machen |
| Modifier-gesteuertes Product | Kundeneingaben zeigen, die nicht zu einer bestandsführenden Variante werden dürfen |
| Product mit benutzerdefinierte Felder oder Metafields | Ownership strukturierter benutzerdefinierter Daten zeigen |
| Product mit Customer-Group- oder Price-List-Kontext | Bedingte kommerzielle Beziehungen sichtbar machen |
| Channel-spezifisches Product oder Category | Channel-Zuordnungen und lokalisierten Umfang sichtbar machen |
| Komplexer Customer | Gruppen, Adressen, benutzerdefinierte Felder und externe IDs abdecken |
| Komplexe historische Order | Modifier, Rabatte, Auftragsabwicklung, Refunds und Channel-Kontext abdecken |
| Priorisierte Content-Route | Vorbereitung von Seite, Metadaten, internen Links und Redirect zeigen |
Hängen Sie jeder Stichprobe Quell-IDs, Quell-URLs, erwartete Ziel-Owner, externe Schlüssel und bekannte Ausschlüsse an. Das Stichprobenregister sollte erklären, wofür der Quelldatensatz steht, welche Beziehungen relevant sind und welche Nachweise dazugehören. Verwenden Sie für jeden wichtigen Betriebsbereich mindestens einen gewöhnlichen und einen außergewöhnlichen Datensatz. Wenn mehrere Quellstrukturen wesentlich voneinander abweichen, nutzen Sie getrennte Stichproben, statt ein einzelnes Product oder eine einzelne Order für widersprüchliche Muster stehen zu lassen.
BigCommerce-Bereitschaftsgate abschließen
| Bereitschaftsfrage | Erforderlicher Nachweis | Bereitschaftskriterium |
|---|---|---|
| Ist der Zugriff vollständig? | Zugriffsprotokoll | Benötigte Bereiche von Quelle und Ziel sind verfügbar |
| Sind Product-Beziehungen klassifiziert? | Product-Family- und Optionsmatrix | Varianten, Modifier, benutzerdefinierte Felder und App-Daten haben Owner |
| Sind Preis- und Channel-Beziehungen dokumentiert? | Preis- und Channel-Matrizen | Zuordnungen von Gruppe, Liste, Product, Währung und Channel sind explizit |
| Sind Customers und Orders repräsentiert? | Stichprobenregister | Wichtige Account- und historische Order-Muster sind abgedeckt |
| Sind priorisierte Routen definiert? | URL-Inventar | Jeder priorisierte Quellpfad hat ein Ziel oder eine Stilllegungsentscheidung |
| Sind Abhängigkeiten zugeordnet? | App- und Integrationsregister | Jede wichtige Abhängigkeit hat einen weiterführenden Owner |
| Sind Backups und Exporte aktuell? | Datiertes Archiv | Quellnachweise können unabhängig wiederhergestellt werden |
| Sind offene Entscheidungen kontrolliert? | Entscheidungsprotokoll | Kritische Punkte haben Owner und Fälligkeitsdaten |
Die Vorbereitung ist abgeschlossen, wenn das Migrationsteam erklären kann, wie jede hochwertige Quellbeziehung in BigCommerce dargestellt werden soll, ohne sich auf undokumentierte Annahmen zu stützen. Offene Punkte dürfen verbleiben, benötigen aber jeweils einen Owner, einen definierten Nachweis und ein Entscheidungsdatum vor Beginn der betroffenen Migrationsarbeit.
Fazit
Die Vorbereitung auf BigCommerce sollte ein nachweisgestütztes Modell für Products, Varianten, Modifier, Categories, Preise, Customer Groups, Channels, Customers, Orders, Inhalte und Integrationen liefern. Die wichtigste Aufgabe besteht nicht darin, mehr Datensätze zu exportieren, sondern zu definieren, welches BigCommerce-Objekt jede Beziehung übernimmt, und Stichproben zu sammeln, die die tatsächliche Komplexität sichtbar machen.
Ein diszipliniertes Vorbereitungspaket gibt repräsentativen Migrationstests einen nachvollziehbaren Quellstichprobensatz und klare Verantwortlichkeiten für die Bereitschaft.
Häufige Fragen
Was sollte vor dem Export eines Katalogs für BigCommerce vorbereitet werden?
Definieren Sie Product- und Varianten-Ownership, unterscheiden Sie Modifier von Varianten, dokumentieren Sie Categories und Channels und identifizieren Sie Preis- sowie benutzerdefinierte Datenbeziehungen. Der Export wird deutlich aussagekräftiger, sobald klar ist, was jeder Quellwert bedeutet.
Warum sollten Customer Groups und Price Lists getrennt vorbereitet werden?
Eine Gruppe klassifiziert Customers, während eine Price List kommerzielle Werte unter definierten Bedingungen zuweist. Wird nur eine der beiden Strukturen erhalten, können Customer-Segmentierung oder Product-Preise unvollständig bleiben.
Welche BigCommerce-Products gehören in die repräsentative Migrationsstichprobe?
Nehmen Sie ein einfaches Product, ein variantenreiches Product, ein Modifier-gesteuertes Product, ein Product mit benutzerdefinierten Daten, ein Product mit bedingter Preislogik und ein Channel-spezifisches Product auf. Ergänzen Sie jede plattformspezifische Konfiguration mit erheblichem Umsatz- oder Betriebsrisiko.
Sollte jede Source Category zu einer BigCommerce Category werden?
Nein. Manche Quellgruppen sind Navigationslinks, Filter, Kampagnen-Collections, Markenstrukturen oder interne Klassifikationen. Ordnen Sie jede Gruppierung nach ihrem fortbestehenden Zweck zu.
Welche Order-Nachweise sollten vorbereitet werden?
Bereiten Sie Orders mit Varianten- und Modifier-Auswahl, Rabatten, Steuern, Versand, unterschiedlichen Status, Refunds und Referenzen auf externe Systeme vor. Die Beispiele sollen historische Bedeutung erklären, ohne die künftige Checkout-Konfiguration zu definieren.
Wann ist die Vorbereitung auf BigCommerce abgeschlossen?
Sie ist abgeschlossen, wenn der Zugriff funktioniert, Quellnachweise aktuell sind, Products und kommerzielle Beziehungen Ziel-Owner haben, priorisierte URLs zugeordnet sind, Abhängigkeiten erfasst wurden und repräsentative Migrationsstichproben dokumentiert sind.