Fehler bei einer BigCommerce-Migration entstehen häufig dann, wenn Datensätze zwar übernommen werden, aber die Beziehung verloren geht, die ihnen im Storefront oder im Betrieb ihre eigentliche Bedeutung gibt. Produktvarianten und Modifikatoren können im Quellsystem ähnlich aussehen, sich bei der Auftragsabwicklung jedoch unterschiedlich verhalten. Customer Groups und Preislisten können beide beeinflussen, was ein Käufer sieht, sind aber nicht dasselbe Preisfeld. Channels, Sites, Kategoriestrukturen, Inhalte, Lagerorte und Storefront-Frameworks schaffen zusätzliche Zusammenhänge.
Die folgenden Fehlerbilder konzentrieren sich auf wiederkehrende Probleme, durch die ein BigCommerce-Shop zwar mit Daten gefüllt ist, wirtschaftlich und operativ jedoch nicht konsistent funktioniert. Zu jedem Fehler wird benannt, welche Beziehung erhalten bleiben muss und welches konkrete Prüfergebnis zeigt, dass das Risiko unter Kontrolle ist.
Fehler 1: Varianten, Modifikatoren und Produktfelder als dasselbe Auswahlmodell behandeln
Was schiefgeht
Optionen aus dem Quellsystem werden dem BigCommerce-Feld zugeordnet, das auf den ersten Blick am bequemsten erscheint. Lagergeführte untergeordnete SKUs werden zu Modifikatoren, Personalisierungen zu Varianten und technische Spezifikationen zu auswählbaren Kaufoptionen.
BigCommerce-Varianten entstehen aus Kombinationen von Variantenoptionswerten und können eigenständige kommerzielle Daten tragen. Modifikatoren bilden Entscheidungen des Käufers ab, die den ausgelieferten Artikel anpassen oder ergänzen, aber nicht bestimmen, welche lagergeführte Variante ausgewählt wird. Product benutzerdefinierte Felder und Metafields dienen wiederum anderen beschreibenden oder betrieblichen Zwecken.
Frühwarnzeichen
| Frühwarnzeichen | Was es bedeutet |
|---|---|
| Größen- und Farbkombinationen mit eigenem Bestand werden als Modifikatoren angelegt. | Lagerrelevante Auswahlmöglichkeiten werden von der Variantenidentität getrennt. |
| Gravur, Datum, Dateiupload oder Garantieauswahl werden als Varianten angelegt. | Nicht lagerrelevante Personalisierung wird in künstliche SKUs umgewandelt. |
| Untergeordnete SKUs aus dem Quellsystem gehen verloren, weil nur das übergeordnete Product als Bestandseinheit behandelt wird. | Auftragsabwicklung und Bestandskontinuität brechen auf Variantenebene. |
| Produktspezifikationen sind nur in Beschreibungen oder als Käuferauswahl sichtbar. | Strukturierte Merkmale werden mit Verkaufssteuerungen vermischt. |
Vorbeugung
Klassifizieren Sie jeden Quellwert danach, wie er die Auftragsabwicklung beeinflusst. Verwenden Sie Varianten für eigenständig identifizierbare und verkaufbare Kombinationen, Modifikatoren für kaufspezifische Anpassungen, die keine andere lagergeführte Variante auswählen, und benutzerdefinierte Felder oder Metafields für beschreibende oder betriebliche Daten.
Bewahren Sie Variantenoptionswerte, SKU, Bestand, Preis, Gewicht, Bilder und externe Kennungen als zusammengehörige Beziehung. Modifikatorauswahlen müssen an der Order-Position erhalten bleiben; Modifikatorkombinationen erhalten keinen eigenen Bestand.
Empfehlungsbeispiel
Bei maßgeschneiderten Hosen sollten Bundweite und Schrittlänge als Varianten modelliert werden, wenn jede Kombination separat gelagert und ausgeliefert wird. Monogrammtext bleibt ein Modifikator, Pflegehinweise für den Stoff bleiben Product individuelle Daten.
Bestehensbedingung
Jede geprüfte Auswahl führt zur richtigen ausgelieferten Variante, Modifikatorauswahlen bleiben an der Order-Position sichtbar und beschreibende Felder erzeugen keine falschen Varianten oder Bestandsdatensätze.
Fehler 2: Categories übernehmen, aber Kategoriestrukturen und Storefront-Navigation beschädigen
Was schiefgeht
Categories aus dem Quellsystem werden als eine flache oder globale Hierarchie importiert, ohne BigCommerce-Kategoriestrukturen, Channel-Kontext, Menüs, facettierte Suche, Sortierung oder das Storefront-Framework zu berücksichtigen. Products bleiben Categories zugeordnet, Käufer treffen jedoch auf fehlende Zweige, irrelevante Filter oder die falsche Struktur im jeweiligen Storefront.
Eine Source Category kann außerdem eine Marke, Kampagne, interne Gruppierung oder SEO-Landingpage darstellen und muss nicht zwangsläufig eine dauerhafte Kataloghierarchie abbilden.
Frühwarnzeichen
- Es wird angenommen, dass eine einzige Kategoriestruktur für jeden Storefront oder Channel geeignet ist.
- Product-Zuordnungen werden geprüft, ohne zu kontrollieren, welche Struktur der jeweilige Storefront tatsächlich verwendet.
- Marken-, Attribut- und Kampagnenwerte werden vollständig in Categories umgewandelt.
- Navigation und facettierte Suche sollen sich automatisch aus importierten Category-Datensätzen ergeben.
Vorbeugung
Klassifizieren Sie Gruppierungen aus dem Quellsystem nach ihrem Zweck. Erstellen Sie die vorgesehene Kategoriestruktur oder weisen Sie die vorhandenen Strukturen dem richtigen Storefront-Kontext zu für jeden Storefront-Kontext die vorgesehene Kategoriestruktur, erhalten Sie Product-to-Category-Beziehungen und halten Sie Marken-, Filter-, Kampagnen- und Navigationsbedeutung voneinander getrennt.
Legen Sie fest, welche Werte die facettierte Suche steuern und welche Categories Inhalte, Sortierung, Bilder oder Redirects benötigen. Behandeln Sie Stencil, Catalyst und Headless-Storefront-Navigation als Implementierungen, die Katalogbeziehungen nutzen, nicht als automatische Folge eines Category-Imports.
Empfehlungsbeispiel
Bei einem Händler mit Retail- und Wholesale-Storefronts sollten unterschiedliche, channelgerechte Kategoriestrukturen verwendet werden, wenn sich die Käuferwege unterscheiden. Die gemeinsame Product-Identität kann bestehen bleiben; Product-Attribute oder individuelle Daten für Filter sollten erhalten bleiben, statt als Categories dupliziert zu werden.
Bestehensbedingung
Jeder Storefront verwendet die vorgesehene Kategoriestruktur, Products erscheinen in den richtigen Zweigen, die Navigation erreicht diese Zweige und Filter basieren auf konsistenten Daten statt auf unbeabsichtigten Category-Duplikaten.
Fehler 3: Customer Groups von den Preislisten trennen, die ihnen ihre wirtschaftliche Bedeutung geben
Was schiefgeht
Customer Groups werden als Bezeichnungen migriert, während Preislisten, Preise auf Variantenebene, Category-Zugriff oder Channel-Zuordnungen getrennt behandelt werden. Käufer erscheinen in der richtigen Gruppe, erhalten aber weiterhin Katalogpreise, die falsche Währung oder Zugriff auf das falsche Sortiment.
BigCommerce-Preislisten können Variantenpreise überschreiben und über Customer Groups, Channels oder eine Kombination aus Customer Group und Channel zugewiesen werden. Eine Preisliste ohne ihre Zuweisung bildet deshalb kein vollständiges Preismodell.
Frühwarnzeichen
| Frühwarnzeichen | Was es bedeutet |
|---|---|
| Die Migration einer Gruppe gilt als abgeschlossen, sobald Customers den richtigen Gruppennamen anzeigen. | Die wirtschaftliche Bedeutung der Gruppe wurde nicht erhalten. |
| Preise werden nur auf Product-Ebene zugeordnet, obwohl sich Varianten unterscheiden. | Die Preislistenabdeckung ist für einzelne verkaufbare Einheiten falsch. |
| Preislistenzuweisungen berücksichtigen den Channel-Kontext nicht. | Ein gültiger Preis kann im falschen Storefront erscheinen oder dort fehlen, wo er benötigt wird. |
| Mengenpreise und Preislistenüberschreibungen werden ohne Vorrangregeln kombiniert. | Konkurrierende Preismechanismen können inkonsistente Ergebnisse erzeugen. |
Vorbeugung
Modellieren Sie Gruppe, Category-Zugriff, Preisliste, Variantenpreisdatensatz, Währung, Channel und Zuweisung als zusammenhängende Strukturen. Erhalten Sie genau die Beziehung, die bestimmt, welcher angemeldete Käufer auf welchem Storefront welchen Variantenpreis erhält.
Trennen Sie historische Order-Preise von aktiven Preislistendatensätzen. Bewahren Sie externe Vertrags- oder ERP-Preiskennungen, wenn ein anderes System weiterhin die Preisautorität besitzt.
Empfehlungsbeispiel
Für eine VIP-Gruppe, die in einem regionalen Storefront einkauft, müssen Gruppenmitgliedschaft, Category-Zugriff, Preisliste, Variantenpreise, Währung und die Zuweisung zwischen dieser Gruppe und dem Channel erhalten bleiben.
Bestehensbedingung
Ein repräsentativer angemeldeter Customer sieht im vorgesehenen Channel das richtige Sortiment und die richtigen Variantenpreise, während Customers außerhalb der Gruppe die korrekten Fallback-Preise erhalten.
Fehler 4: Channels, Sites und Storefronts als bloße Kennzeichnungen behandeln
Was schiefgeht
Products, Categories, Customers, Preise, Währungen, Menüs und Inhalte werden migriert, ohne die Channel- und Site-Beziehungen zu erhalten, die bestimmen, wo sie erscheinen. Der Shop hat einen korrekten Standard-Storefront, während sekundäre Marken, Regionen, Marktplätze oder Headless-Erlebnisse einen falschen Katalog oder falsche Konfiguration übernehmen.
In BigCommerce steht ein Channel für einen Verkaufskontext, während eine Site eine vom Händler kontrollierte Website bezeichnet, die an einen Storefront-Channel gebunden ist. Channel-spezifische Zuweisungen und Einstellungen beeinflussen daher deutlich mehr als nur eine sichtbare Bezeichnung.
Frühwarnzeichen
| Frühwarnzeichen | Was es bedeutet |
|---|---|
| Datensätze fallen auf den primären Channel zurück, weil keine Channel-ID angegeben ist. | Die Channel-Zugehörigkeit fehlt in den migrierten Datensätzen. |
| Product- und Preislistenzuweisungen werden global statt je Storefront geprüft. | Storefront-spezifische Unterschiede bei Sortiment und Preis werden eingeebnet. |
| Domains, Sites, Menüs, Währungen und Kategoriestrukturen werden getrennt dokumentiert. | Die vollständige Storefront-Beziehung wird nicht als zusammenhängendes System gesteuert. |
| Apps und Integrationen gehen davon aus, dass jede Order- oder Product-Interaktion zum Standard-Channel gehört. | Nachgelagerte Systeme klassifizieren Herkunft und Kontext falsch. |
Vorbeugung
Definieren Sie das Channel-Modell vor der finalen Zuordnung. Identifizieren Sie jeden Storefront-, Marketplace-, POS-, Marketing- oder Custom-Channel, die Site und Domain des jeweiligen Storefronts sowie Product-, Kategoriestruktur-, Preis-, Währungs-, Menü-, Order- und App-Kontexte, die dazu gehören.
Erhalten Sie Channel-IDs und Quell-Channel-Referenzen in Integrationszuordnungen. Verwenden Sie den Standard-Channel nicht als ungeklärten Fallback.
Empfehlungsbeispiel
Bei zwei Marken-Storefronts und einem Amazon-Channel kann ein gemeinsamer Product-Katalog bestehen bleiben, sofern fachlich passend. Products und Preislisten müssen jedoch den richtigen Storefront-Channels zugewiesen sein, jede Marke muss die vorgesehene Kategoriestruktur und Site verwenden und die Herkunft von Marketplace-Orders muss separat erhalten bleiben.
Bestehensbedingung
Products, Preise, Menüs, Kategoriestrukturen, Orders und Integrationen lassen sich dem vorgesehenen Channel und der vorgesehenen Site zuordnen. Kein sekundärer Storefront funktioniert versehentlich nur aufgrund des Standard-Channel-Verhaltens.
Fehler 5: Bestand ohne Standort- und Channel-Kontext importieren
Was schiefgeht
Eine einzige Bestandsmenge wird dem Product oder der Variante zugeordnet, obwohl das Quellsystem Lagerhäuser, Filialen, Abholpunkte, Lieferanten oder Channel-Zuteilungen verfolgt. Die Gesamtsumme wirkt plausibel, aber Abholverfügbarkeit, Auftragsabwicklung und externe Synchronisierung werden falsch.
Frühwarnzeichen
- Ein Gesamtbestand ersetzt mehrere Quellstandorte.
- Mengen werden dem Parent Product statt der lagergeführten Variante zugeordnet.
- Abhol- oder Fulfillment-Regeln werden aus der Standortzuordnung weggelassen.
- Externe Lagerkennungen werden nach dem Import der Anfangsbestände verworfen.
Vorbeugung
Ordnen Sie Bestand genau der Product-Variante und dem BigCommerce-Standort zu, dem er gehört. Erhalten Sie Standortkennungen, Varianten-SKUs, externe Bestandskennungen und alle Channel- oder Abholbeziehungen, die der fortlaufende Prozess benötigt.
Trennen Sie aktuell verkaufbaren Bestand von historischen Bewegungen, reserviertem Bestand, beschädigtem Bestand, Lieferantenverfügbarkeit und anderen Zuständen, die nicht in die Anfangsmenge gehören.
Empfehlungsbeispiel
Bei einem Händler mit einem Zentrallager und drei Abholfilialen sollte jeder Quellstandort dem entsprechenden BigCommerce-Standort zugeordnet werden. Variantenbestände und Lagerkennungen bleiben erhalten; Channel- oder Abholverfügbarkeitsregeln bleiben von der reinen Menge getrennt.
Bestehensbedingung
Geprüfte Varianten zeigen an jedem Standort die vorgesehene Menge, Abhol- oder Fulfillment-Dienste erkennen den richtigen Bestandsverantwortlichen und das weiterführende Bestandssystem aktualisiert dieselben Varianten-Standort-Datensätze ohne Duplikate.
Fehler 6: Redirects als abschließenden technischen Import behandeln
Was schiefgeht
Redirects werden erst erstellt, nachdem Product-, Category-, Seiten- und Storefront-Routen bereits festgelegt wurden. Alte URLs werden mechanisch dem nächstliegenden Zielpfad zugeordnet, ohne Nutzerabsicht, Channel, Site, Locale oder Inhaltsverantwortung zu erhalten.
BigCommerce kann Redirects und Site-Routen verwalten, doch eine Redirect-Datei behebt weder fehlende Inhalte noch falsche Kategoriestrukturen, Unterschiede im Storefront-Framework oder channel-spezifische Zielseiten.
Frühwarnzeichen
| Frühwarnzeichen | Was es bedeutet |
|---|---|
| Die Redirect-Planung umfasst Product-URLs, aber keine Categories, Seiten, Blog Posts, gefilterten Routen oder Kampagneninhalte. | Das Redirect-Inventar bildet die tatsächliche Traffic-Oberfläche nicht vollständig ab. |
| Für verschiedene Storefronts wird dasselbe Ziel verwendet, obwohl jede Site eine andere Routenstruktur hat. | Channel-spezifische Nutzerwege werden zusammengelegt. |
| Redirects zeigen auf unveröffentlichte oder im aktiven Storefront nicht vorhandene Seiten. | Die Zuordnung ist technisch vorhanden, aber für Kunden unbrauchbar. |
| Alte Query-Parameter und von Apps erzeugte Pfade werden ignoriert. | Wichtige nicht-kanonische und integrationsgenerierte Routen können unbemerkt ausfallen. |
Vorbeugung
Erstellen Sie ein Routeninventar, das mit der Verantwortung für das Ziel verknüpft ist. Ordnen Sie jede wichtige Quell-URL einem Product, einer Category, einer Seite, einem Blog Post, einer Site-Route, einer Storefront-Anwendung, einem Ersatzinhalt oder einer bewusst beschlossenen Stilllegung zu.
Priorisieren Sie Umsatz, organischen Traffic, Backlinks, Customer-Lesezeichen und aktive Kampagnen. Halten Sie Channel- und Site-Kontext explizit fest, wenn dasselbe Quellmuster unterschiedliche Ziele benötigt.
Empfehlungsbeispiel
Bei einem Multi-Storefront-Händler sollten die wichtigsten Product- und Category-URLs für jede Marken-Site separat zugeordnet werden. Ausgelaufene Kampagnenseiten erhalten relevante Ersatzinhalte, und Headless-Anwendungsrouten bleiben bestehen, wenn der Storefront sie außerhalb des Kernkatalogs verantwortet.
Bestehensbedingung
Priorisierte URLs erreichen nützliche Inhalte auf der vorgesehenen Site und im vorgesehenen Channel, kein Redirect zeigt auf ein nicht verfügbares Ziel und ausgelassene Pfade besitzen eine bewusste Stilllegungsentscheidung.
Fehler 7: benutzerdefinierte Felder und Metafields ohne Anwendungsverantwortung kopieren
Was schiefgeht
benutzerdefinierte Felder, App-Daten, Integrationskennzeichen, SEO-Werte und externe Kennungen aus dem Quellsystem werden gemeinsam in Product benutzerdefinierte Felder oder Metafields geschrieben. Werte kommen ohne klaren Datentyp, Berechtigung, Namespace, Verbraucher oder Parent Resource an.
BigCommerce unterstützt Metafields für mehrere Ressourcen und Product benutzerdefinierte Felder für Storefront-Informationen. Diese Strukturen stellen jedoch nicht automatisch die App, das Theme, die Integration oder den Workflow wieder her, der die Quelldaten verwendet hat.
Frühwarnzeichen
- Das Zielfeld wird nach der Bezeichnung des Quellfelds ausgewählt statt nach dem System, das den Wert nutzt.
- Werte auf Variantenebene werden dem übergeordneten Product zugeordnet.
- App-eigene Felder werden unter nicht zugehörigen Namespaces neu angelegt.
- Quell-IDs mit Verweisen auf Products, Customers, Medien oder Orders werden unverändert kopiert.
Vorbeugung
Klassifizieren Sie individuelle Daten nach Verantwortlichem und Zweck. Nutzen Sie Product benutzerdefinierte Felder für geeignete, im Storefront sichtbare Product-Informationen, Resource Metafields für typisierte betriebliche oder anwendungsbezogene Daten und externe Systeme für Datensätze, die diese weiterhin verantworten.
Übersetzen Sie Referenzen in Ziel-IDs, erhalten Sie Namespaces und Berechtigungen und dokumentieren Sie Theme, App, API oder Integration, die das jeweilige Feld verwendet.
Empfehlungsbeispiel
Eine öffentlich sichtbare Materialangabe kann als Product benutzerdefiniertes Feld gespeichert werden, wenn der Storefront sie anzeigen soll. Ein lagerbezogener Code auf Variantenebene bleibt Variant Metafield; der Subscription-Status bleibt bei der Subscription-Anwendung, die ihn verantwortet.
Bestehensbedingung
individuelle Daten befindet sich an der richtigen Ressource, wird vom vorgesehenen Storefront oder System verwendet und enthält keine verwaisten Namespaces, ersetzten Parent-Bezüge oder ungeänderten Quell-IDs.
Fehler 8: Vorhandene Customers und Orders mit betrieblicher Kontinuität gleichsetzen
Was schiefgeht
Die Anzahl von Customers und Orders stimmt, aber Identität, Adressen, Gruppenzuordnung, Einwilligungen, Varianten in Order-Positionen, Rabatte, Steuern, Versand, Rückerstattungen, Consignments, Shipments, Status und externe Referenzen sind unvollständig. Historische Zahlungs- und Versandbezeichnungen werden anschließend fälschlich als aktuelle Checkout- und Fulfillment-Konfiguration interpretiert.
Dieser Fehler schwächt Support und Finanzprozesse, selbst wenn der Shop neue Orders erfolgreich annehmen kann.
Frühwarnzeichen
- Customer-Identität wird ausschließlich über die E-Mail-Adresse abgeglichen.
- Gruppenzuordnung wird geprüft, ohne Preisgestaltung und Category-Zugriff zu kontrollieren.
- Orders werden nur anhand von Nummer und Gesamtbetrag stichprobenartig geprüft.
- Multi-Address-, erstattete, teilweise versandte oder channel-spezifische Orders fehlen in den Stichproben.
Vorbeugung
Erhalten Sie Customer-Identität, Adressen, Attribute, Einwilligungen, Gruppe und externe IDs entsprechend ihrem geschäftlichen Zweck. Bewahren Sie historische Order-Positionen, Varianten, Preise, Anpassungen, Steuern, Versandadressen, Consignments, Shipments, Rückerstattungen, Status, Notizen, Channel-Herkunft und externe Referenzen in dem Umfang, den Support und Finance benötigen.
Trennen Sie historische Nachweise von aktueller Zahlungs-, Checkout-, Versand-, Steuer- und Fulfillment-Konfiguration.
Empfehlungsbeispiel
Bei einer teilweise versandten regionalen Order sollten Customer und Gruppe, gekaufte Varianten, Channel, Versandadressen, Consignments, Sendungsverfolgung, Rabatt, Steuer, Erstattungsnachweise und ERP-Order-ID erhalten bleiben. Der zukünftige regionale Checkout und Versand werden separat konfiguriert.
Bestehensbedingung
Customers bleiben eindeutig identifizierbar und wirtschaftlich korrekt klassifiziert, historische Orders bleiben für Support und Finance nachvollziehbar und der laufende Betrieb verlässt sich nicht auf importierte Bezeichnungen als Konfiguration.
Übergreifende Prioritäten zur Fehlervermeidung
| Priorität | Erforderliche Kontrolle |
|---|---|
| Verantwortlichkeit von Auswahlmodellen | Varianten, Modifikatoren, benutzerdefinierte Felder, Metafields und App-Daten nach ihrer Funktion trennen. |
| Storefront-Kontext | Beziehungen zwischen Channel, Site, Kategoriestruktur, Menü, Route und Preisgestaltung erhalten. |
| Wirtschaftlicher Kontext | Customer Groups mit Category-Zugriff, Preislisten, Variantenpreisen und Channels verbinden. |
| Betriebliche Identität | Kennungen für Varianten, Standorte, Customers, Orders, Channels und externe Systeme stabil halten. |
| Historische Trennung | Order-Nachweise erhalten, ohne sie als aktuelle Checkout- oder Fulfillment-Konfiguration zu behandeln. |
Prüfen Sie diese Kontrollen gemeinsam, weil BigCommerce-Fehler häufig mehrere Ebenen zugleich betreffen. Ein Variantenfehler kann gleichzeitig Preise, Bestand, Storefront-Auswahl, Order-Nachweise und externe Kennungen beeinträchtigen. Der Präventionsnachweis sollte für jede betroffene Ebene den Verantwortlichen und das erforderliche Prüfergebnis benennen.
Fazit
Fehler bei BigCommerce-Migrationen entstehen, wenn zusammengehörige Datensätze unabhängig voneinander importiert werden. Varianten, Modifikatoren, Kategoriestrukturen, Customer Groups, Preislisten, Channels, Sites, Lagerorte, Redirects, individuelle Daten, Customers und Orders tragen jeweils Kontext, der verbunden bleiben muss.
Der stärkste Ansatz zur Fehlervermeidung definiert diese Beziehungen vor der großflächigen Zuordnung. Wenn jeder Datensatz den richtigen Verantwortlichen, Channel, wirtschaftlichen Kontext, die richtige externe Identität und eine klare Bestehensbedingung besitzt, kann der migrierte Shop über Storefronts und Systeme hinweg konsistent funktionieren.
Häufige Fragen
Was ist der Unterschied zwischen einer BigCommerce-Variante und einem Modifikator?
Eine Variante stellt die verkaufbare Kombination dar und kann SKU, Preis, Bestand, Bilder und weitere kommerzielle Daten tragen. Ein Modifikator verändert oder individualisiert den ausgelieferten Artikel, wählt aber keine andere lagergeführte Variante aus.
Warum können migrierte Categories in einem BigCommerce-Storefront trotzdem fehlschlagen?
Category-Datensätze müssen auch zur vorgesehenen Kategoriestruktur und zum Storefront-Kontext gehören. Navigation, facettierte Suche, Sortierung, Inhalte und Channel-Zuweisung sind eigenständige Beziehungen.
Stellen Customer Groups automatisch Gruppenpreise wieder her?
Nein. Gruppenpreise können von Preislisten, Variantenpreisen, Category-Zugriff, Währung, Channel und Preislistenzuweisungen abhängen. Die Gruppenbezeichnung allein reicht nicht aus.
Wie beeinflusst Multi-Storefront den Migrationsumfang?
Products, Kategoriestrukturen, Preislisten, Währungen, Menüs, Sites, Routen, Orders und Apps können channel-spezifische Bedeutung besitzen. Das Migrationsmodell muss diese Zuweisungen erhalten, statt alles auf den ersten Storefront zurückfallen zu lassen.
Sollten alle benutzerdefinierte Felder aus dem Quellsystem zu BigCommerce Product benutzerdefinierte Felder werden?
Nein. Manche Werte gehören in Resource Metafields, an Varianten, in Apps, externe Systeme oder die Storefront-Implementierung. Das Ziel hängt vom Verantwortlichen des Felds, seinem Verbraucher, seiner Sichtbarkeit und seiner Parent Resource ab.
Konfigurieren importierte Orders den BigCommerce-Checkout und die Auftragsabwicklung?
Nein. Importierte Orders bewahren historische Transaktionsnachweise. Aktuelles Checkout-, Zahlungs-, Versand-, Steuer-, Standort- und Fulfillment-Verhalten erfordert eine separate BigCommerce-Konfiguration und klare Integrationsverantwortung.