Die Planung des BigCommerce-Datenmodells sollte mit der Bedeutung beginnen, nicht mit Datensatzmengen. Products, Categories, Customers, Orders, CMS Pages, Blog Posts, Redirects und ergänzende Felder mögen vertraute Bezeichnungen tragen, doch BigCommerce bildet Commerce über klar strukturierte Katalog-, Preis-, Channel-, Customer-, Content- und Integrationsbereiche ab, deren Funktionsweise von der Quellplattform abweichen kann.
Ein Quellshop kann nach der Migration vollständig wirken und dennoch wirtschaftlich falsch abgebildet sein. Produktauswahlen können der falschen Struktur zugeordnet sein. Kategoriepfade können vorhanden sein, ohne die Produktsuche und Navigation sinnvoll zu erhalten. Customer-Datensätze können übertragen sein, aber den Preiskontext verlieren, der sie geschäftlich relevant machte. Redirects können technisch funktionieren und dennoch auf wenig geeignete Ziele führen. benutzerdefinierte Felder und Metafields können vorhanden sein, ohne noch mit der App, dem ERP, der Suche, dem Merchandising oder der Storefront-Funktion verbunden zu sein, die sie zuvor genutzt hat.
Ein belastbarer BigCommerce-Migrationsplan übersetzt deshalb Quellinformationen zuerst in die Bedeutungslogik von BigCommerce, bevor der Umfang als endgültig gilt.
Warum die Datenbedeutung in BigCommerce separat geprüft werden muss
BigCommerce ist eine gehostete SaaS-Zielplattform mit definierten Commerce-Strukturen. Das kann die Governance nach der Migration vereinfachen, verlangt aber auch explizitere Zuordnungsentscheidungen. Eine Quellplattform kann Produktoptionen, Personalisierungsfelder, Customer-Gruppen, Preisregeln, Landingpages und App-gesteuerte Funktionen überlappend organisiert haben. BigCommerce verlangt meist eine klarere Trennung dieser Bedeutungen.
Entscheidend ist daher nicht, ob ein Quelldatensatz grundsätzlich ein Ziel in BigCommerce hat. Wichtiger ist, ob die gewählte Zielstruktur den geschäftlichen Zweck dieses Datensatzes erhält.
| BigCommerce-Bereich | Zu bestätigende Bedeutung bei der Migration |
|---|---|
| Produktauswahl | Ob eine Auswahl aus dem Quellshop als Variante, Variantenoption, Modifier, benutzerdefiniertes Feld, Metafield, App-Konfiguration oder andere definierte Zielstruktur abgebildet werden sollte. |
| Kategoriestruktur | Ob Quellkategorien Katalogorganisation, Navigation, Merchandising und SEO-relevante Auffindbarkeit erhalten. |
| Preiskontext | Ob Basispreise, Mengenstaffeln, Price Lists, Customer-Group-Logik und externe Preisreferenzen ihre Bedeutung behalten. |
| Channel-Umfang | Ob Products, Categories, Preise, Inhalte und URLs zum richtigen Storefront- oder Channel-Kontext gehören. |
| Customer- und Order-Datensätze | Ob Customer-Identität, Account-Kontext, Gruppenzugehörigkeit, Order-Historie und Servicewert weiterhin nutzbar sind. |
| Inhalte und Routen | Ob CMS Pages, Blog Posts, Redirects und Seitenziele die ursprüngliche Customer-Absicht erhalten. |
| Benutzerdefinierte und App-Daten | Ob benutzerdefinierte Felder, Metafields, App-eigene Datensätze und externe Systemkennungen direkte Feldzuordnung oder Filterung, Datenumstrukturierung oder Einrichtung im Zielshop benötigen. |
Diese Prüfung verhindert eine oberflächliche Freigabe. Die Frage sollte nicht nur lauten: „Wurde der Datensatz übertragen?“ Entscheidend ist: „Liegt der Datensatz in BigCommerce jetzt in der Struktur, die Verkauf, Service, Preislogik, Auffindbarkeit und Integrationskontinuität tatsächlich unterstützt?“
Produktstruktur: Products, Varianten, Optionen und Modifier
Die Produktstruktur in BigCommerce verlangt eine genaue Interpretation, weil Quellplattformen Produktauswahlen unterschiedlich modellieren. Manche Shops verwenden Varianten für jede auswählbare Option. Andere nutzen benutzerdefinierte Optionsfelder, Plugins, Apps, Product Builder, Bundle-Systeme oder Theme-Logik. BigCommerce trennt mehrere Konzepte für Produktauswahlen, und diese Trennung beeinflusst Bestand, Preis, Auftragsabwicklung, Storefront-Darstellung und Reporting.
Eine Produktvariante steht normalerweise für eine tatsächlich verkaufbare Ausprägung eines Produkts. Größe, Farbe, Material, Verpackung, Modell, Ausführung oder Einheit können Teil der Variantenstruktur sein, wenn die Auswahl SKU, Bestand, Bild, Gewicht, Preis, Verfügbarkeit oder Auftragsabwicklung beeinflusst. Variantenoptionen beschreiben die auswählbaren Dimensionen, aus denen diese Variantenkombinationen entstehen.
Modifier erfüllen eine andere Funktion. Sie können eine kundenseitige Auswahl darstellen, die den Kaufvorgang verändert, ohne zwingend einen separat bestandsgeführten Artikel zu erzeugen. Beispiele sind Personalisierungstext, Gravur, Geschenkmitteilungen, optionale Extras, Datei-Uploads, Garantieauswahl oder Anpassungen ohne eigene Bestandsführung. Werden Quelloptionen der falschen Zielstruktur zugeordnet, kann die Produktseite vollständig aussehen, während die operative Funktion nicht mehr stimmt.
| Produktauswahl im Quellshop | BigCommerce-Frage | Verlorene Bedeutung bei falscher Zuordnung |
|---|---|---|
| Größe oder Farbe mit SKU und Bestand | Sollte sie Variante und Variantenoption werden? | Bestands- und Order-Line-Bedeutung kann verloren gehen. |
| Gravur oder Geschenkmitteilung | Entspricht sie eher einem Modifier oder benutzerdefiniertes Feld? | Kundeneingaben können fälschlich wie bestandsgeführte Optionen behandelt werden. |
| Bundle- oder Kit-Auswahl | Ist sie nativ unterstützt, App-eigen oder individuelle Logik? | Preis-, Auftragsabwicklungs- und Bestandserwartungen können brechen. |
| Garantie- oder Kompatibilitätsfeld | Ist es Anzeigeinformation, Produktmetadatum oder App-Funktion? | Wichtiger kommerzieller Kontext kann als Text erhalten bleiben, aber seine Funktion verlieren. |
| Upload-Feld oder Personalisierungsablauf | Ist App-Einrichtung im Ziel oder eine Datenumstrukturierung erforderlich? | Das Product kann migriert sein, während der ursprüngliche Kaufablauf nicht mehr funktioniert. |
Product-Daten sollten anhand echter Katalogmuster geprüft werden. Ein einfaches Product, ein variantenreiches Product, ein Modifier-lastiges Product, ein Bundle und ein Product mit benutzerdefinierten Daten zeigen deutlich mehr als eine reine Product-Anzahl.
benutzerdefinierte Felder, Metafields und Produktmetadaten
BigCommerce benutzerdefinierte Felder und Metafields erfüllen unterschiedliche Zwecke und sollten nicht als austauschbare Container behandelt werden. Product benutzerdefinierte Felder können zusätzliche Product-Informationen enthalten, die für die Storefront vorgesehen sind. Metafields sind programmatisch nutzbare Schlüssel-Wert-Daten an Ressourcen wie Products, Varianten, Categories und Marken. Sie eignen sich für Anwendungen und Integrationen und erscheinen nicht automatisch als gewöhnlicher Storefront- oder Control-Panel-Inhalt.
Diese Unterscheidung ist bei der Migration entscheidend. Ein Quellattribut kann wie „benutzerdefinierte Daten“ aussehen und dennoch eine sehr spezifische Funktion erfüllen:
| Zweck der Quelldaten | Frage für die BigCommerce-Zielstruktur |
|---|---|
| Kundensichtbare Spezifikation | Sollte der Wert als Product-Feld, benutzerdefiniertes Feld, strukturierter Seiteninhalt oder anderer sichtbarer Wert abgebildet werden? |
| Verkaufbare Auswahl | Definiert der Wert eine Variante, Variantenoption oder einen Modifier statt nur beschreibender Metadaten? |
| Such- oder Filtereingabe | Welche BigCommerce- oder App-Struktur nutzt den Wert tatsächlich für die Auffindbarkeit? |
| Interne operative Referenz | Sollte der Wert verborgen in einem Metafield oder im weitergeführten externen System bleiben? |
| ERP-, PIM- oder Buchhaltungsschlüssel | Welche Ressource besitzt die Kennung, und wie findet das verbundene System sie wieder? |
| App-eigene Funktion | Unterstützt die Zielanwendung den Import, oder muss der Ablauf neu gestaltet werden? |
Das Zielfeld sollte nach Nutzung, Sichtbarkeit und Ownership ausgewählt werden. Werden sämtliche Quellattribute in Product benutzerdefinierte Felder übertragen, können interne Daten offengelegt oder die Storefront schwer beherrschbar werden. Werden dagegen alle Werte in Metafields verschoben, können zwar Daten vorhanden sein, ohne dass Administratoren, Themes oder Anwendungen sie tatsächlich nutzen können. Eine saubere Zuordnung dokumentiert den vorgesehenen Verbraucher, die Ressourcenbeziehung und ob ein Wert kundensichtbar, operativ, integrationsbezogen oder bewusst ausgeschlossen bleibt.
Categories, Kategoriehierarchien, Navigation und Auffindbarkeit
Die Migration von Categories nach BigCommerce ist mehr als eine Ordnerübertragung. Categories, Kategoriebäume, Product-Zuordnungen, Menülogik, Storefront-Navigation und SEO-relevante Routen beeinflussen gemeinsam, wie Customers Produkte finden. Eine Quellkategorie kann gleichzeitig administrative Ordnung, öffentliche Landingpage, Merchandising-Sammlung, Kampagnengruppe, Menüeintrag, Suchfilter oder SEO-Seite gewesen sein.
Die BigCommerce-Planung sollte diese Rollen trennen. Eine Category kann als BigCommerce Category übernommen werden. Eine Menübeziehung kann dagegen Storefront-Einrichtung im Ziel erfordern. Eine wichtige Landingpage kann Inhaltserhalt oder einen Redirect-Plan benötigen. Eine Collection-ähnliche Quellstruktur kann Zuordnung, manuellen Neuaufbau, App-Unterstützung oder bewussten Ausschluss verlangen.
| Quellstruktur | Planungsfrage für BigCommerce |
|---|---|
| Product Category | Sollte sie als BigCommerce Category oder Eintrag im Kategoriebaum abgebildet werden? |
| Collection oder dynamische Gruppe | Ist sie eine Category, Merchandising-Regel, Storefront-Konfiguration oder App-Anforderung? |
| Navigationsmenü | Gehört es zu Katalogdaten oder zur Theme-/Storefront-Einrichtung? |
| SEO-Landingpage | Sollte sie als Inhalt, Category-Kontext, Redirect-Ziel oder neu aufgebaute Seite erhalten werden? |
| Kampagnen- oder temporäre Category | Sollte sie migriert, eingestellt, weitergeleitet oder ausgeschlossen werden? |
Bei Multi-Storefront- oder Channel-orientierten Händlern hängt die Bedeutung einer Category zusätzlich davon ab, wo Products erscheinen sollen. Eine Category kann in einer Storefront sinnvoll sein und in einer anderen verwirren. Product-Zuordnungen, Benennung, Routen und Redirect-Ziele sollten deshalb im jeweiligen Verkaufskontext geprüft werden.
Preise, Customer Groups und Price Lists
Die Preislogik ist eine der wichtigsten Datenmodell-Unterscheidungen in BigCommerce, weil sie auf mehreren Ebenen bestehen kann. Ein Quellshop kann Basispreise, Angebotspreise, Mengenpreise, Customer-Group-Preise, Großhandelsstaffeln, regionale Preise, verhandelte Käuferpreise, Price-List-Logik, App-gesteuerte Regeln oder externe Preissysteme verwenden.
Die Migration nach BigCommerce sollte diese Beziehungen nicht auf einen einzigen Product-Preis reduzieren, sofern das Unternehmen nicht bewusst ein einfacheres Preismodell anstrebt. Der Preiskontext ist als Beziehung zwischen Products, Customers, Gruppen, Price Lists, Mengenbedingungen, Storefronts, Channels, Apps und externen Systemen zu prüfen.
| Preisquelle | Zu erhaltende Bedeutung |
|---|---|
| Product-Basispreis | Standard-Verkaufswert. |
| Mengenpreis | Erwartete Preisstaffel nach Menge. |
| Customer-Group-Preis | Käufersegment- oder Großhandelslogik. |
| Price List | Strukturierter Preiszusammenhang für Zielgruppe, Channel oder Geschäftskontext. |
| App-gesteuerter Preis | Geschäftslogik, die möglicherweise App-eigen bleibt oder einen externen Preisinhaber benötigt. |
| Externes Preissystem | Kontinuität von Kennung und Synchronisierung, nicht nur sichtbarer Preis. |
Ein migriertes Product kann den richtigen Basispreis anzeigen und dennoch für einen Großhandelskäufer, eine Customer Group, einen Channel oder eine regionale Storefront die falsche kommerzielle Bedeutung haben. Kritische Preisfälle sollten daher als konkrete Beziehungen zwischen Product, Customer Group, Price List und Channel geprüft werden, statt aus dem Basispreis abgeleitet zu werden.
Channels, Storefronts und Verkaufskontext
Channel- und Storefront-Strukturen in BigCommerce können Product-Verfügbarkeit, Category-Darstellung, Währungskontext, Site-Beziehungen, Menüs, Preisannahmen, Redirects und Customer Experience beeinflussen. Channel-Bedeutung gehört deshalb zum Datenmodell und ist nicht nur eine Implementierungseinstellung.
Quellplattformen können Channel-Logik über mehrere Shops, Websites, Marktplätze, Regionen, Sprachversionen, Domains, Integrationen oder individuellen Code abbilden. BigCommerce benötigt für jede Beziehung eine explizite Zielinterpretation: Welche Products gehören zu welchen Channels? Welcher Kategoriebaum unterstützt welche Site? Welche Inhalte und Routen gehören zu welcher Storefront? Welche Preise oder Customer-Regeln gelten in diesem Kontext?
| Bedeutung im Quellsystem | In BigCommerce zu definierende Beziehung |
|---|---|
| Regionale oder markenspezifische Storefront | Channel, Site, Domain, Kategoriebaum, Content-Ownership und Redirect-Ziel. |
| Marketplace- oder Social-Channel | Product-Zuordnung, Ownership externer Listings, Kennungen und Synchronisierungsverantwortung. |
| Shopspezifischer Katalogausschnitt | Product-Channel-Zuordnung und in dieser Storefront sichtbare Category-Struktur. |
| Shopspezifische Preise | Price List, Customer Group, Channel-Kontext, externes Preissystem oder anderer definierter Owner. |
| Lokalisierte Inhalte oder Navigation | Storefront-eigene Inhalte, Theme-Konfiguration, übersetzte Inhalte oder separate Implementierungsebene. |
Gemeinsame Product-Datensätze können geteilt bleiben, während ihre Zuordnung und Darstellung je Channel variiert. Werden diese Beziehungen abgeflacht, kann die Administration vollständig aussehen, während eine Storefront das falsche Sortiment, den falschen Category-Pfad, Preiskontext oder Redirect erhält. Die Migrationszuordnung sollte daher sowohl den gemeinsamen Datensatz als auch jede Channel-spezifische Beziehung erfassen, die erhalten bleiben muss.
Customers, Accounts und Order-Historie
Customer- und Order-Daten sollten als kommerzieller und servicebezogener Kontext verstanden werden. Ein Customer-Datensatz kann Identität, Adressen, Account-Status, Customer-Group-Zuordnung, benutzerdefinierte Attribute, Einwilligungen, Order-Beziehungen und Preiserwartungen enthalten. Eine Order kann Product-Namen, SKUs, Mengen, Rabatte, Steuern, Versand, Rechnungsdaten, Auftragsabwicklung, Zahlungsbezeichnungen, Notizen, Rückerstattungen und externe Referenzen bewahren.
Der Migrationsplan sollte klären, wofür Customer- und Order-Historie nach der Migration benötigt werden. Customer Service, Wiederkäufe, Großhandelszugang, Support-Recherche, Reporting, Rückerstattungsprüfung und Integrationsabgleich können unterschiedliche Detailtiefe erfordern.
Ein Account-System der Quellplattform lässt sich möglicherweise nicht exakt auf das BigCommerce-Account-Verhalten übertragen. Passwörter, Gruppenzugehörigkeiten, Loyalty-Daten, Abonnements, Angebotsabläufe, Unternehmensaccounts, Customer-Freigaben oder externe CRM-Referenzen können separate Prüfung erfordern. Manche Werte lassen sich zuordnen. Manche können über direkte Feldzuordnung oder Filterung behandelt werden. Andere erfordern Datenumstrukturierung oder einen anwendungsspezifischen Migrationspfad. Wieder andere benötigen App-Einrichtung im Ziel oder bleiben außerhalb des Migrationsumfangs.
Orders verlangen dieselbe Disziplin. Historische Order-Daten sollten lesbar und nutzbar bleiben, doch aktuelle Zahlungs-, Checkout-, Versand-, Steuer-, Benachrichtigungs- und Auftragsabwicklungslogik gehört zur Einrichtung des Zielshops.
Inhalte, Seiten, Blog Posts, Redirects und Routenbedeutung
Content- und URL-Kontinuität in BigCommerce gehört zur Übersetzung des Datenmodells, weil Seiten, Blog Posts, Redirects, Product-Pfade, Category-Pfade und Storefront-Ziele Customer-Vertrauen und Sichtbarkeit in Suchmaschinen prägen. Ein Redirect kann technisch funktionieren und dennoch den Customer Journey schwächen, wenn eine alte Product-, Category- oder Content-URL auf ein breites oder thematisch unpassendes Ziel führt.
CMS Pages und Blog Posts sollten nach ihrem Zweck bewertet werden. Manche Seiten unterstützen Vertrauen, Richtlinien, Markenerklärung, Kaufberatung, Kampagnen-Traffic oder SEO-Auffindbarkeit. Einige Blog Posts liefern Long-Tail-Suchwert oder Produktwissen. Andere Quellseiten müssen möglicherweise nicht migriert werden, benötigen aber trotzdem einen Redirect auf ein sinnvolles Ziel.
| Inhalt oder Routentyp | Migrationsentscheidung |
|---|---|
| Product-URL | Erhalten oder auf das am besten passende Product weiterleiten. |
| Category-URL | Auffindbarkeits- und Navigationsabsicht möglichst erhalten. |
| CMS Page | Migrieren, neu aufbauen, zusammenführen, weiterleiten oder einstellen. |
| Blog Post | Erhalten, wenn er Traffic, Information, Vertrauen oder internen Linkwert trägt. |
| Kampagnenseite | Entscheiden, ob die Kampagne weiterläuft, einen Redirect benötigt oder eingestellt wird. |
| Storefront-spezifische Route | Richtige Storefront bzw. richtigen Channel als Ziel bestätigen. |
Routenidentität gehört in das BigCommerce-Datenmodell, weil Redirects die ursprüngliche Customer-Absicht mit einem nutzbaren Ziel verbinden. Gute Redirect-Beziehungen erhalten Customer Journeys, statt nur isolierte technische Zuordnungen darzustellen.
Apps, Integrationen und Daten externer Systeme
BigCommerce-Migrationen überschneiden sich häufig mit externen Systemen. ERP, PIM, CRM, Buchhaltung, Steuer-, Versand-, Abonnement-, Personalisierungs-, Such-, Review-, Loyalty-, Warehouse-, Marketplace- oder Marketing-Systeme können auf Kennungen und benutzerdefinierte Felder angewiesen sein, die bei einer normalen Storefront-Prüfung nicht sichtbar sind.
Die Datenmodellfrage lautet, ob BigCommerce die Daten besitzen, anzeigen, an eine App weitergeben, für Abstimmung bewahren oder ignorieren soll, weil der Ablauf neu aufgebaut wird. Diese Ergebnisse sind voneinander zu unterscheiden.
| Externe Abhängigkeit | Relevanz für die BigCommerce-Migration |
|---|---|
| ERP oder Buchhaltung | Product-IDs, SKUs, Order-Referenzen, Customer-Kennungen sowie Steuer- und Rabattkontext. |
| PIM | Ownership von Attributen, Product-Texten, Bildern, Varianten und benutzerdefinierte Felder. |
| CRM oder Marketing | Customer-Identität, Einwilligungen, Segmentierung, Order-Historie und benutzerdefinierte Attribute. |
| Subscription- oder Loyalty-App | App-eigene Datensätze, Funktionen und Kontinuitätserwartungen. |
| Such- oder Merchandising-App | Filterattribute, benutzerdefinierte Felder, Product-Tags, Regeln und Ranking-Funktion. |
| Versand- oder Steuersystem | Externe Kennungen und Checkout-nahe Funktionen. |
Wenn für die Daten bereits eine geeignete BigCommerce-Zielstruktur existiert, können direkte Zuordnung oder Filterung ausreichen. Wenn sie App-eigen, extern gesteuert oder von einer nicht nativen Beziehung abhängig sind, sollte die Zielanwendung, das externe System oder die erforderliche Datenumstrukturierung vor Abschluss der Source-to-Target-Zuordnung definiert werden.
BigCommerce-Datenumfang nach geschäftlicher Nutzung bewerten
Der Umfang einer BigCommerce-Migration sollte danach bewertet werden, wie die Daten nach der Migration genutzt werden. Products, Customers, Orders, Categories, CMS Pages, Blog Posts und Redirects können in reguläre Datensatzziele passen, doch ihre Bedeutung kann weiterhin von Produktauswahlstrukturen, Kategoriebäumen, Channel-Zuordnungen, Customer Groups, Price Lists, benutzerdefinierte Felder, Metafields, Anwendungen und externen Kennungen abhängen.
Eine hilfreiche Zuordnung unterscheidet folgende Ergebnisse:
| Ergebnis der Zuordnung | Bedeutung für BigCommerce |
|---|---|
| Nativer Datensatz und Beziehung | Die Quellbedeutung passt zu BigCommerce Product, Variante, Modifier, Category, Customer, Order, Content-Datensatz, Redirect oder einer anderen unterstützten Beziehung. |
| Storefront- oder Channel-Konfiguration | Der Datensatz existiert, seine Nutzung hängt aber von Channel-Zuordnungen, Kategoriebäumen, Sites, Themes, Menüs, Preiskontext oder anderer Konfiguration im Zielshop ab. |
| Ownership durch Anwendung oder Integration | Die Daten bleiben im Besitz eines ERP-, PIM-, CRM-, Subscription-, Loyalty-, Such- oder anderen verbundenen Systems und benötigen eine stabile systemübergreifende Kennung. |
| Gezielte Datenumstrukturierung | Die Quellstruktur muss neu aufgebaut werden, weil ihre Bedeutung nicht zur verfügbaren Zielstruktur oder Beziehung passt. |
| Ausschließen, archivieren oder neu gestalten | Der Wert ist veraltet, doppelt, an eingestellte Logik gebunden oder hat künftig keinen klaren geschäftlichen Owner. |
Dieses Modell hält die Migration auf die Übertragung von Bedeutung ausgerichtet und verhindert, dass eine hohe Datensatzanzahl mit einem brauchbaren BigCommerce-Datenmodell verwechselt wird. Ein belastbarer Umfang erklärt, was jede wichtige Quellbedeutung im Ziel wird, welche Beziehung sie erhält, wer sie nach dem Launch verantwortet und was bewusst außerhalb des Zielshops bleiben soll.
Fazit
Unterschiede im BigCommerce-Datenmodell sind relevant, weil die Plattform migrierten Datensätzen eine klar strukturierte kommerzielle Bedeutung gibt. Products, Varianten, Modifier, Categories, Customer Groups, Price Lists, Channels, Customers, Orders, CMS Pages, Blog Posts, Redirects, benutzerdefinierte Felder, Metafields, Apps und externe Kennungen sollten danach geprüft werden, wie das Unternehmen sie nach dem Launch nutzt.
Ein belastbarer BigCommerce-Migrationsplan erhält nicht nur das Vorhandensein der Daten, sondern auch ihre Funktion. Er trennt native Datensätze von Channel- und Storefront-Konfiguration, integrationsbezogenen Werten, Datenumstrukturierung und bewusst ausgeschlossenen Anforderungen, bevor das Ziel-Datenmodell endgültig festgelegt wird.
Häufige Fragen
Warum sind BigCommerce-Produktoptionen bei einer Migration wichtig?
Produktoptionen können unterschiedliche geschäftliche Bedeutungen haben. Manche Auswahlen sollten Varianten werden, andere entsprechen eher Modifiern oder benutzerdefinierte Felder, und wieder andere hängen von Apps oder individueller Logik ab. Wird die Bedeutung falsch interpretiert, können Produktseiten vollständig wirken, während Bestand, Preise, Auftragsabwicklung oder Customer-Auswahl nicht korrekt funktionieren.
Reichen BigCommerce benutzerdefinierte Felder und Metafields für alle benutzerdefinierten Quelldaten aus?
Nein. Sie können bestimmte zusätzliche Daten erhalten, reproduzieren aber nicht automatisch die Funktionen der Quellplattform. App-eigene Datensätze, externe Systemkennungen, individuelle Product-Logik und spezifische Umstrukturierungen können Datenumbau, Anwendungsmigration oder Einrichtung im Zielshop erfordern.
Erhalten BigCommerce Categories die Quellnavigation automatisch?
Nicht immer. Categories, Kategoriebäume, Menüstruktur, SEO-Landingpages sowie Storefront- und Channel-Kontext sollten getrennt geprüft werden. Ein Category-Datensatz kann vorhanden sein, während der Weg zur Produktsuche weiterhin von Zielnavigation, Channel-Kontext, Content oder Redirect-Beziehungen abhängt.
Wie sollten Price Lists und Customer Groups die Migrationsplanung beeinflussen?
Sie sollten als Beziehungen und nicht als isolierte Felder behandelt werden. Ein Product-Preis kann korrekt aussehen, während eine Customer Group, Price List, Mengenregel oder Storefront-Bedingung noch gesondert geprüft werden muss.
Wie sollten App- oder integrationsbezogene Daten in BigCommerce abgebildet werden?
Zuerst sollte das weiterhin führende System bestimmt werden. Ein BigCommerce-Feld, Metafield oder eine externe Kennung sollte nur dann erhalten werden, wenn die Zielanwendung oder Integration sie tatsächlich nutzt. Abonnementverträge, Loyalty-Guthaben, Suchregeln, Marketplace-Status und ähnliche Anwendungsdaten sollten dem unterstützten Datenpfad der Zielanwendung folgen, statt in generische Product- oder Customer-Felder abgeflacht zu werden.
Wie bleibt Channel-spezifische Katalogbedeutung in BigCommerce erhalten?
Vor der Zuordnung sollte feststehen, welche Products, Preise, Categories, Inhalte und Sichtbarkeitsregeln zu welchem Channel gehören. Gemeinsame Datensätze können geteilt bleiben, aber Channel-spezifische Unterschiede dürfen nicht vereinheitlicht werden, wenn sie beeinflussen, was Käufer sehen oder Mitarbeiter verwalten.