Der passende Migrationsansatz für BigCommerce hängt davon ab, wie viel des Quellshops als unterstützte BigCommerce-Daten abgebildet werden kann, ohne geschäftliche Bedeutung zu verlieren. Ein einfacher Produktkatalog kann einen geradlinigen Pfad erlauben. Ein variantenreicher Katalog, segmentierte Preisstrukturen, Multi-Channel-Aufbau, benutzerdefinierte Felder mit Anforderungen außerhalb des unterstützten Mapping-Umfangs, App-eigene Datensätze, externe Kennungen oder ein SEO-kritischer Redirect-Plan können stärkere Vorbereitung, Add-ons, Managed Service oder eine Prüfung über Custom Service erfordern.
Die Wahl des Service-Pfads sollte deshalb nicht allein mit der Shopgröße beginnen. Komplexität in BigCommerce entsteht häufig aus Produktauswahlen, Preisregeln, Channel-Zuordnungen, Storefront-Kontinuität, Customer-Segmentierung, Integrationen und Konfiguration im Ziel. Ein großer Shop kann einen gut beherrschbaren Pfad haben, wenn die Daten unterstützt und prüfbar sind. Ein kleinerer Shop kann Custom Service benötigen, wenn App- oder benutzerdefinierte Daten für den Betrieb zentral sind.
Innerhalb der Next-Cart Migration Services sollten die BigCommerce-Nachweise bestimmen, ob unterstützter Umfang ausreicht, ob die Ausführung stärker von Experten geführt werden sollte oder ob plattformspezifische Strukturen Add-ons beziehungsweise Custom Service erfordern.
Was der Migrationsansatz für BigCommerce bedeutet
Ein BigCommerce-Migrationsansatz entscheidet über Umfang, Verantwortung, Unterstützungsniveau und Tiefe der Validierung. Er sollte definieren, welche Datensätze nach BigCommerce migriert werden, welche Einstellungen im Ziel direkt in BigCommerce konfiguriert werden müssen, welche Add-ons für unterstützte Anpassungen erforderlich sind, welche Anforderungen Custom Service benötigen und welche Stichproben der Demo Migration vor der Full Migration bestehen müssen.
| Art der Arbeit | BigCommerce-Beispiel | Auswirkung auf den Service-Pfad |
|---|---|---|
| Unterstützte migrierte Datensätze | Products, Categories, Customers, Orders, Bilder, Content-Seiten, Redirects und unterstützte zugehörige Felder. | Kann je nach Ausführungs- und Validierungsbedarf zu Standard Service oder Managed Service passen. |
| Unterstützte Anpassungen | Product-, Customer-, Order-, Content- oder Redirect-Daten benötigen eine definierte Bedingung nach Datenkategorie, eine Wert-Expression oder ein anderes Zielfeld. | Kann Data Filter, Advanced Data Mapping oder Data Transformation erfordern. |
| Individuelle oder nicht unterstützte Anforderungen | App-eigene Daten, nicht unterstützte benutzerdefinierte Felder mit nicht standardmäßiger Interpretation, externe Kennungen, individuelle Preislogik, Feed-Daten oder besondere Transformation. | Erfordert Prüfung über Custom Service. |
| Einrichtung im Ziel | Storefront-Theme, Checkout-Einstellungen, Zahlungssetup, Steuerregeln, Versandkonfiguration, Apps, Channels und Live-Integrationen. | Muss in BigCommerce eingerichtet und getestet werden, statt als migrierter Datensatz behandelt zu werden. |
Der passende Pfad schützt vor zwei gegensätzlichen Fehlern: einem zu leichten Ansatz für komplexe Geschäftsdaten und einer unnötigen Eskalation jeder plattformspezifischen Besonderheit zu Custom Service, obwohl ein unterstütztes Add-on oder eine Aufgabe zur Zielkonfiguration genügt.
Wann Standard Service ausreichen kann
Standard Service kann ausreichen, wenn der BigCommerce-Umfang unterstützt wird, die Quelldaten sauber sind und der Händler Eingaben vorbereiten sowie das Ergebnis sicher validieren kann. Das bedeutet typischerweise, dass Products, Categories, Customers, Orders, Bilder, Seiten, Redirects und zugehörige Felder ohne individuelle Transformation oder nicht unterstützte App-Daten migriert werden können.
Standard Service ist besonders geeignet, wenn Produktauswahlen einfach oder klar strukturiert sind, die Preislogik nicht stark segmentiert ist, Channel-Anforderungen begrenzt bleiben, Customer-Daten überwiegend Standardstrukturen folgen und der Händler Stichproben der Demo Migration ohne intensive Koordination prüfen kann.
| Bereitschaftssignal für Standard Service | BigCommerce-spezifischer Grund |
|---|---|
| Products haben klare SKUs, Optionen, Varianten, Bilder und Categories. | Die Katalogprüfung kann sich auf unterstützte BigCommerce-Produktstrukturen konzentrieren. |
| Modifier oder kundenseitige Personalisierung sind begrenzt oder leicht zu erkennen. | Der Katalog benötigt seltener besondere Interpretation. |
| Preislogik besteht überwiegend aus Basispreis, Angebotspreis oder einfachem unterstütztem Rabattkontext. | Komplexität durch Price Lists oder B2B-Preislogik bleibt begrenzt. |
| Channels sind einfach oder kein wesentlicher Teil der Launch-Komplexität. | Product-Sichtbarkeit und Storefront-Umfang lassen sich leichter validieren. |
| Customers und Orders sind gewöhnliche historische Datensätze. | Buyer Lookup und Order-Historie lassen sich mit repräsentativen Stichproben prüfen. |
| Redirect- und Content-Umfang sind klar. | SEO-Kontinuität lässt sich ohne individuelle Content-Transformation prüfen. |
Standard Service wird riskant, wenn der Händler nicht erklären kann, wie Quelloptionen, Preise, Channels oder App-Daten in BigCommerce erscheinen sollen. Ein unterstützter Datensatztyp bedeutet nicht automatisch, dass jedes Quellverhalten unterstützt wird.
Wann Managed Service sicherer sein kann
Managed Service kann sinnvoller sein, wenn die Daten größtenteils unterstützt werden, die Ausführung aber Koordination, Sequenzierung und Expertensteuerung benötigt. Das kann bei großen Katalogen, vielen Produktoptionen, wichtigen Redirects, hochwertiger Order-Historie, launchkritischem SEO, Multi-Channel-Sichtbarkeit oder begrenzten internen Kapazitäten für die Migration auftreten.
Managed Service kann die operative Belastung reduzieren, erweitert nicht aber nicht unterstützte App-Datensätze automatisch zum Standardumfang. Der Service ist am besten als stärker geführter Ausführungs- und Koordinationspfad für unterstützte oder klar abgegrenzte Daten zu verstehen. Bei nicht unterstützten Datensätzen oder individuellen Transformationen kann weiterhin Custom Service erforderlich sein.
| Eignung für Managed Service | BigCommerce-Szenario |
|---|---|
| Unterstützter Umfang mit vielen Prüfpunkten | Products, Varianten, Categories, Bilder, Customers, Orders, Seiten und Redirects benötigen koordinierte Prüfung. |
| Hochwertige SEO-Kontinuität | Redirects, Product-URLs, Category-URLs, Seiten und Metadaten brauchen sorgfältige Launch-Sequenzierung. |
| Variantenreicher Katalog | Produktauswahlen werden unterstützt, erfordern aber disziplinierte Stichprobenprüfung. |
| Multi-Channel- oder Preissensitivität | Channel-Zuordnungen, Price Lists oder Customer-Group-Preise erfordern strukturierte Validierung. |
| Begrenzte interne Kapazität | Der Händler möchte von Next-Cart geführte Ausführungsunterstützung und behält die finale Ergebnisprüfung. |
Managed Service sollte wegen des Bedarfs an Ausführungsunterstützung und Prüfdiziplin gewählt werden, nicht als Ersatz für einen klaren Umfang. Akzeptanzkriterien und repräsentative Stichproben bleiben erforderlich.
Wann Add-ons die Anforderung lösen können
Add-ons sind geeignet, wenn eine Anforderung unterstützt, klar begrenzt und spezifisch ist. Data Filter kann unterstützte BigCommerce Products, Customers oder Orders anhand feldbasierter Bedingungen für die jeweilige Datenkategorie auswählen. Advanced Data Mapping kann ein unterstütztes Standard-Quellfeld auf ein anderes kompatibles unterstütztes BigCommerce-Zielfeld abbilden, ohne den Wert zu verändern. Data Transformation kann Expressions auf unterstützte Zielwerte anwenden. Diese Funktionen ersetzen Custom Service nicht bei nicht unterstützten Datensätzen, externen Systemen, individueller Logik oder App-eigenen Daten, die BigCommerce nicht als reguläre Migrationsdaten übernimmt.
| Add-on-Bedarf | BigCommerce-Beispiel | Grenzprüfung |
|---|---|---|
| Data Filter | Unterstützte Products, Customers, Orders, CMS Pages oder Blog Posts migrieren, die definierte feldbasierte Bedingungen für ihre Datenkategorie erfüllen. | Feld, Bedingung sowie Ein- oder Ausschlussregel müssen explizit sein. |
| Data Transformation | Expressions anwenden, um unterstützte Feldwerte für BigCommerce während der Migration zu transformieren. | Eingabewerte, erwartete Ausgaben und Ausnahmefälle müssen testbar sein. |
| Advanced Data Mapping | Unterstützte Standard-Quellfelder auf andere unterstützte BigCommerce-Zielfelder abbilden, ohne die Werte zu verändern. | Die Zuordnung darf kein nicht unterstütztes BigCommerce-Verhalten oder keine nicht unterstützte Zielstruktur erzeugen. |
| Begrenzte Sonderanforderung | Eine klar definierte unterstützte Anpassung für Products, Categories, URLs, Customers oder Orders anwenden. | Bei individueller Logik oder nicht unterstützten Datensätzen ist Custom Service zu prüfen. |
Gute Add-on-Anforderungen werden als präzise Akzeptanzkriterien formuliert. Schwache Anforderungen bleiben bei Formulierungen wie „genau wie im Quellshop“, ohne unterstützte Felder oder das erwartete Ergebnis zu definieren.
Wann Custom Service geprüft werden sollte
Custom Service sollte geprüft werden, wenn die BigCommerce-Anforderung über unterstütztes Standardverhalten hinausgeht. Auslöser ist nicht die Größe des Händlers, sondern benutzerdefinierte Daten, nicht unterstützte Quellstrukturen, individuelle Transformation, App-Datensätze, externe Kennungen, eine Custom Platform oder notwendige Anpassungen an der Migrationslogik.
Bei BigCommerce treten solche Anforderungen häufig bei Produktoptionen, benutzerdefinierte Felder, Metafields, Preisen, ERP-Daten, Subscriptions, Reviews, Marketplace-Feeds, B2B-ähnlichen Strukturen, Customer-Segmentierung, Loyalty-Daten sowie Headless- oder App-verbundenem Storefront-Verhalten auf.
| Auslöser für Custom Service | Warum sich der Ansatz ändert |
|---|---|
| Quelloptionen passen nicht sauber zu Varianten, Variantenoptionen oder Modifiern. | Der Katalog benötigt möglicherweise individuelle Interpretation, bevor BigCommerce ihn sinnvoll nutzen kann. |
| App-eigene Subscriptions, Loyalty-, Bundle-, Review-, Feed- oder Marketplace-Datensätze werden erwartet. | Die Daten gehören möglicherweise nicht zu den Standardplattform-Datensätzen. |
| benutzerdefinierte Felder oder externe Kennungen müssen für ERP, CRM, Buchhaltung oder Support nutzbar bleiben. | Unterstützte Zuordnung kann die geschäftliche Bedeutung möglicherweise nicht vollständig erhalten. |
| Erweiterte Preislogik hängt von individuellen oder externen Regeln ab. | Price Lists oder Mengenpreise bilden das Quellverhalten möglicherweise nicht vollständig ab. |
| Quellinhalte hängen von Page Buildern, Skripten oder individueller Storefront-Logik ab. | BigCommerce-Inhalte und Redirects können besondere Behandlung oder manuellen Neuaufbau benötigen. |
| Eine Custom Platform ist Teil der Source- oder Target-Situation. | Quellstrukturen müssen möglicherweise direkt analysiert werden, bevor eine Zuordnung verlässlich ist. |
Custom Service sollte anhand konkreter Beispiele abgegrenzt werden. Der Händler sollte repräsentative Products, Customers, Orders, Content-Datensätze, benutzerdefinierte Felder mit Anforderungen außerhalb unterstützter Zuordnung, App-Exporte, externe Kennungen und erwartete Ergebnisse bereitstellen. Ohne Beispiele bleibt die Custom-Service-Prüfung zu abstrakt für einen verlässlichen Service-Pfad.
Was die Demo Migration entscheiden sollte
Die Demo Migration sollte zeigen, ob der gewählte BigCommerce-Ansatz ausreichend belastbar ist. Sie ist nicht lediglich eine Vorschau von Datensatzmengen. Die Stichproben müssen nachweisen, dass BigCommerce-spezifische Datenbedeutung die Migration übersteht.
| Stichprobe der Demo Migration | Unterstützte Entscheidung |
|---|---|
| Einfaches Product | Grundmuster für Product, Category, Bild, Preis und Bestand. |
| Variantenreiches Product | Ob Optionen und Varianten korrekt funktionieren. |
| Modifier-ähnliches Product | Ob Customer-Personalisierung einen anderen Pfad benötigt. |
| Product mit benutzerdefinierte Felder außerhalb unterstützter Mapping-Anforderungen oder mit Metafields | Ob die Zuordnung unterstützt wird oder Custom Service erforderlich ist. |
| Price-List- oder Mengenpreisbeispiel | Ob die Preiserwartung unterstützt, konfiguriert oder individuell behandelt werden muss. |
| Channel-spezifisches Product | Ob Channel-Zuordnung und Sichtbarkeit separat geprüft werden müssen. |
| Customer mit Gruppe oder benutzerdefiniertes Feld | Ob Customer-Identität und Segmentierung erhalten bleiben. |
| Rabattierte oder erstattete Order | Ob historischer Order-Kontext lesbar bleibt. |
| Priorisierte URL oder Content-Seite | Ob SEO- und Redirect-Erwartungen angepasst werden müssen. |
Der Ansatz ist zu leicht, wenn die Demo Migration Produktauswahlen, Pricing, Channel-Umfang, Customer-Segmentierung, Redirects oder App-eigene Daten nicht erklären kann. Dann muss der Umfang vor der Full Migration angepasst werden, statt darauf zu hoffen, dass der vollständige Lauf die Abweichung automatisch löst.
Entity Points und Umfangsplanung für BigCommerce
Entity Points helfen bei der Planung des Volumens ausgewählter Datenkategorien, beweisen aber nicht, dass Quelldaten zu BigCommerce passen. Bei BigCommerce können berechtigte Product-, Customer-, Order- und Blog-Posts-Datensätze Entity Points verbrauchen, wenn sie auf einem Pfad erstmals migriert werden; bereits auf demselben Pfad gezählte Datensätze werden weiterhin nur einmal gezählt. Channel-, Price-List-, Modifier- und App-Komplexität wird separat bewertet. Neue berechtigte Datensätze können Entity Points verbrauchen, wenn sie erstmals migriert werden.
Für BigCommerce sollten Entity Points gemeinsam mit Struktur und Komplexität betrachtet werden. Ein kleiner Quellshop kann Custom Service benötigen, wenn App-eigene Felder, externe IDs, individuelle Preise oder Storefront-Logik zentral sind. Ein größerer Shop kann Standard Service oder Managed Service nutzen, wenn die Datensätze unterstützt werden und der Händler sie zuverlässig validieren kann.
| Umfangssignal | Was es abschätzen hilft | Was es nicht beweist |
|---|---|---|
| Product-Anzahl | Katalogvolumen und möglichen Entity-Points-Verbrauch. | Ob Varianten, Modifier, benutzerdefinierte Felder, Bilder, Categories und Channels korrekt zugeordnet werden. |
| Customer-Anzahl | Volumen der Buyer-Datensätze. | Ob Gruppen, benutzerdefinierte Felder, Dubletten, externe IDs und Buyer-Beziehungen nutzbar bleiben. |
| Order-Anzahl | Volumen historischer Orders. | Ob Refunds, Rabatte, Zahlungskontext, Auftragsabwicklung und individuelle Status verständlich bleiben. |
| Blog-Posts-Anzahl | Content-Volumen, sofern relevant. | Ob URLs, Redirects, Metadaten und Content-Darstellung launchbereit sind. |
Entity Points unterstützen die Planung, ersetzen aber nicht die Bewertung des Service-Pfads.
Wie Additional Migration Options die BigCommerce-Launch-Planung beeinflussen
Additional Migration Options sind relevant, wenn sich der BigCommerce-Quellshop nach Demo Migration oder Full Migration weiter verändert oder wenn der Händler die Behandlung späterer Daten anpassen muss. Die Option sollte zur tatsächlichen Änderung passen und nicht allein deshalb gewählt werden, weil innerhalb der aktiven gekauften Migration eine weitere Aktion verfügbar ist.
| Aktuelle Option | BigCommerce-spezifische Nutzung | Erforderliche erneute Validierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Nutzen, wenn der Quellshop neue berechtigte Products, Customers, Orders oder Blog Posts enthält und akzeptierte Filter, Mappings, Channel-Annahmen, Redirect-Behandlung und Katalogstruktur weiterhin gelten. | Neue Datensätze, betroffene Varianten oder Modifier, Channel-Sichtbarkeit, Order-Historie und priorisierte URLs erneut prüfen. |
| Continue the Migration with a New Configuration | Nutzen, wenn Filter, Mappings, Interpretation von Product-Optionen, Customer-Segmentierung, Redirect-Behandlung, Price-List-Annahmen oder Channel-/Storefront-Umfang geändert werden müssen. | Sowohl geänderte Regeln als auch repräsentative Datensätze erneut prüfen, die zuvor unter der älteren Konfiguration akzeptiert wurden. |
| Perform a New Migration | Nutzen, wenn das frühere Zielergebnis nicht als Arbeitsgrundlage bestehen bleiben soll, die BigCommerce-Zielumgebung zurückgesetzt oder wesentlich überarbeitet wurde oder ein sauberes Migrationsergebnis unter neu freigegebenem Umfang benötigt wird, während der gekaufte Source-Platform-to-Target-Platform-Pfad unverändert bleibt. | Den vollständigen Akzeptanzsatz für Katalog, Customers, Orders, Inhalte, Redirects, Channels und individuelle Anforderungen wiederholen. |
Diese Unterscheidung ist besonders wichtig, wenn während eines aktiven BigCommerce-Launchfensters neue Orders und Customers entstehen, der Hauptkatalog aber unverändert bleibt.
Additional Migration Options bauen BigCommerce-Apps, Theme-Code, Checkout-Konfiguration, Channel-Integrationen, Zahlungseinstellungen oder Abläufe externer Systeme nicht neu auf. Wenn spätere Quelländerungen solche Bereiche betreffen, muss der Händler die Zielimplementierung und erneute Validierung getrennt von der Datenaktion koordinieren.
Die Ausführungsverantwortung folgt weiterhin dem gewählten Migration Service. Customers mit Standard Service oder Custom Service ohne Expert Handle führen verfügbare Aktionen selbst aus. Bei Managed Service oder Custom Service mit Expert Handle kann Next-Cart die vereinbarte Aktion durchführen, während der Customer für die abschließende Prüfung und das Migrationsergebnis verantwortlich bleibt.
Warnsignale für einen zu leichten Ansatz
Ein BigCommerce-Ansatz ist zu leicht, wenn er plattformspezifische Komplexität wie gewöhnliche Datensatzübertragung behandelt. Warnsignale zeigen sich meist in Katalogbedeutung, Pricing, Channel-Umfang, Redirects, Customer-Segmentierung oder App-Daten.
| Warnsignal | Wahrscheinliche Reaktion |
|---|---|
| Produktauswahlen lassen sich nicht als Varianten, Variantenoptionen, Modifier, Zielkonfiguration oder Custom-Umfang klassifizieren. | Katalogumfang neu definieren, bevor der endgültige Pfad gewählt wird. |
| Price Lists, Customer-Group-Preise oder Mengenpreise sind geschäftskritisch, aber nicht in Stichproben enthalten. | Preisstichproben ergänzen und Bedarf für Add-ons oder Custom Service prüfen. |
| Channel-Zuordnungen oder Product-Sichtbarkeit unterscheiden sich je Storefront. | Channel-Vorbereitung und Validierung verstärken. |
| Redirects, CMS Pages oder Blog Posts sind hochwertig, aber nur grob abgegrenzt. | Content- und SEO-Kontinuität als launchkritischen Nachweis behandeln. |
| benutzerdefinierte Felder, Metafields, App-Daten oder externe IDs sind zentral für den Betrieb. | Prüfen, ob unterstützte Feldzuordnung die Anforderung erhält; Custom Service prüfen, wenn dies nicht ausreicht. |
| Demo Migration enthält nur einfache Products und saubere Orders. | Stichprobensatz vor der Full Migration erweitern. |
| Quelldaten ändern sich kurz vor dem Launch ohne Plan für spätere Aktionen. | Timing, Migrationsaktion, Ownership und erneute Validierung festlegen. |
Diese Signale sollten vor der Full Migration bearbeitet werden. Wird bis zum Launch gewartet, lässt sich schwerer unterscheiden, ob ein Problem aus der Migration oder aus fehlender BigCommerce-Zielkonfiguration stammt.
Den praktischen Pfad wählen
Der praktische BigCommerce-Ansatz ist der leichteste Pfad, der das Geschäftsergebnis dennoch schützt. Standard Service kann ausreichen, wenn unterstützte Datensätze und Customer-geführte Validierung realistisch sind. Managed Service ist sicherer, wenn unterstützter Umfang stärkere Koordination verlangt. Add-ons eignen sich, wenn unterstützte Datensätze gefiltert, Feldwerte transformiert oder Felder neu zugeordnet werden müssen. Custom Service ist notwendig, wenn nicht unterstützte, individuelle, App-eigene oder von externen Systemen abhängige Anforderungen beziehungsweise besondere Transformationen bewertet werden müssen.
Ein verlässlicher Ansatz lässt sich in vier Aussagen zusammenfassen:
- welche Datensätze nach BigCommerce migriert werden;
- welche BigCommerce-Einstellungen, Apps, Channels oder Storefront-Funktionen separat konfiguriert werden müssen;
- welche Add-ons oder Custom-Service-Anforderungen zum Umfang gehören;
- welche Stichproben der Demo Migration vor der Full Migration bestehen müssen.
Sind diese vier Aussagen klar, ist der Ansatz in der Regel bereit zur Umsetzung. Sind sie unklar, sollte der Händler den Umfang weiter präzisieren, bevor die Auswahl des Service-Pfads als abgeschlossen gilt.
Fazit
Die Wahl des BigCommerce-Migrationsansatzes sollte darauf beruhen, wie BigCommerce nach dem Launch funktionieren soll. Standard Service, Managed Service, Add-ons und Custom Service haben jeweils eine eigene Rolle, doch keiner davon sollte allein anhand der Datensatzmengen gewählt werden. Der richtige Ansatz berücksichtigt Katalogstruktur, Varianten, Modifier, Price Lists, Channels, Customers, Orders, Redirects, Inhalte, Apps, Entity Points, spätere Migrationsaktionen und Nachweise aus der Demo Migration.
Ein praktischer Service-Pfad schützt sowohl die Migrationsausführung als auch die geschäftliche Validierung. Er sollte erklären, was migriert wird, was in BigCommerce eingerichtet werden muss, wofür Add-ons benötigt werden, was Custom Service erfordert und was vor dem Launch bewiesen werden muss.
Häufige Fragen
Wann reicht Standard Service für eine BigCommerce-Migration aus?
Standard Service kann ausreichen, wenn der BigCommerce-Umfang unterstützt wird, Product-Strukturen klar sind, Pricing und Channels beherrschbar bleiben, Customers und Orders gewöhnliche Muster haben, Redirects und Inhalte abgegrenzt sind und der Händler das Ergebnis sicher validieren kann.
Wann sollte Managed Service für eine BigCommerce-Migration erwogen werden?
Managed Service ist sinnvoll, wenn die Migration innerhalb unterstützter Funktionen bleibt, aber stärkere Ausführungsunterstützung, Koordination, Stichprobenprüfung, Launch-Sequenzierung oder Hilfe bei der Validierung von Katalog, Redirects, Preisen oder Channels benötigt wird.
Wie unterscheiden sich Add-ons und Custom Service bei einer BigCommerce-Migration?
Add-ons passen unterstützte Datensatzfilterung, Transformation von Feldwerten oder Feldzuordnungen an. Für BigCommerce sollte Custom Service geprüft werden, wenn Multi-Storefront-Zuordnungen, B2B-Datensätze, App-eigene Daten, externe Kennungen oder individuelle Katalog- und Customer-Transformationen nicht über unterstützte Zuordnung oder klar begrenzte Add-ons behandelt werden können.
Was sollte Demo Migration für BigCommerce vor der Full Migration beweisen?
Demo Migration sollte zeigen, dass repräsentative BigCommerce-Datensätze erwartungsgemäß funktionieren: Products, Varianten, Modifier, Preisbeispiele, Customer-Datensätze, Order-Stichproben, Redirects, Inhalte, Channel-Zuordnungen und gegebenenfalls relevante individuelle oder integrationsbezogene Beispiele.
Welche Additional Migration Option passt zu einem BigCommerce-Launch-Update?
Verwenden Sie Continue the Migration with the Last Used Configuration, wenn akzeptierte Einstellungen weiterhin für neue berechtigte Datensätze passen. Verwenden Sie Continue the Migration with a New Configuration, wenn Filter, Mappings, Channel-Umfang, Redirects oder Product-Behandlung geändert werden müssen. Verwenden Sie Perform a New Migration, wenn das Projekt ein sauberes Zielergebnis unter wesentlich überarbeitetem Umfang oder BigCommerce-Zielsetup benötigt, während der gekaufte Migrationspfad unverändert bleibt. Ein anderer Source-Platform-to-Target-Platform-Pfad erfordert einen separat gekauften Migration Service.