Probleme bei CS-Cart-Migrationen entstehen meist dann, wenn die Zielplattform wie eine flache Product-Datenbank behandelt wird. Das tatsächliche Betriebsmodell kann einen oder mehrere Storefronts, gemeinsame und Storefront-spezifische Objekte, Product Features, Options, Product Variations, Vendor-Verantwortung, individuelle Order-Status, Erweiterungen und externe Integrationen umfassen. Ein Datensatz kann vorhanden sein, während Storefront-, Seller-, Auswahl- oder Betriebsbedeutung falsch ist.
Die folgenden Fehlerbilder konzentrieren sich auf diese wiederkehrenden Muster. Jedes beschreibt Fehlermechanismus, Frühwarnzeichen, Vorbeugung, eine praktische Empfehlung und eine Bestehensbedingung.
Übersicht zur Vermeidung typischer CS-Cart-Migrationsfehler
| Bereich | Verdeckter Fehler | Schwerpunkt der Vorbeugung |
|---|---|---|
| Installationsmodell | Storefront- oder Marketplace-Annahmen passen nicht zum tatsächlichen CS-Cart-Setup. | Editions-, Storefront-, Vendor- und Zuständigkeitsgrenzen bestätigen. |
| Katalog | Features, Options und Product Variations werden als austauschbar behandelt. | Werte nach Discovery-, Auswahl-, Bestands- und Identitätszweck klassifizieren. |
| Storefronts | Gemeinsame und Storefront-spezifische Objekte verlieren ihren Umfang. | Zuordnungs- und Sharing-Regeln je Objekttyp erhalten. |
| Vendors | Seller-Identität wird auf ein Product-Feld reduziert. | Vendor-, Product-, Order- und Fulfillment-Beziehungen erhalten. |
| Customers und Orders | Groups, Status, Refunds und Storefront-/Vendor-Kontext werden zu generischer Historie. | Operativ interpretierbare Beziehungen erhalten. |
| Content und SEO | Products werden übertragen, Layouts, Blocks, Routen und Landing Pages jedoch nicht. | Verantwortung für Content, Theme und Redirects festlegen. |
| Erweiterungen und APIs | Erweiterungseigene Tabellen und Kennungen werden ausgelassen oder falsch wiederverbunden. | Custom Ownership inventarisieren und systemübergreifende Schlüssel erhalten. |
| Aktuelle Konfiguration | Historische Bezeichnungen werden mit aktuellem Payment-, Shipping-, Tax- oder Promotion-Setup verwechselt. | Aktive Regeln unter ihren tatsächlichen Zielverantwortlichen neu aufbauen. |
Fehler 1: In das falsche CS-Cart-Betriebsmodell migrieren
Was schiefgeht
Das Projekt geht von einem gewöhnlichen Shop aus, obwohl die Zielumgebung mehrere Storefronts oder ein Marketplace-orientiertes Vendor-Modell nutzen kann. Products, Categories, Customers, Orders, Pages, Einstellungen und Checkout-Verhalten können je nach Installation unterschiedliche Verantwortliche haben. Ein strukturell gültiger Import kann Datensätze deshalb dem falschen Storefront zuweisen, zu breit sichtbar machen oder die für das Geschäftsmodell notwendige Vendor-Beziehung entfernen.
Frühwarnzeichen
| Warnzeichen | Wahrscheinliche Folge |
|---|---|
| Ziel-Edition und aktivierte Module sind nicht dokumentiert. | Der Umfang basiert auf Funktionen, die die tatsächliche Installation möglicherweise nicht verwendet. |
| „Store“, „Storefront“ und „Vendor“ werden austauschbar verwendet. | Zuständigkeit von Datensätzen wird uneindeutig. |
| Für einen Multi-Store-Betrieb wird nur ein Beispielshop geprüft. | Storefront-spezifische Preise, Content, Customers oder Checkout-Pfade bleiben ungetestet. |
| Marketplace-Datensätze werden nur als Products und Orders beschrieben. | Vendor-Verantwortung und Seller-Betrieb verschwinden. |
Vorbeugung
Dokumentieren Sie vor dem Field Mapping das tatsächliche CS-Cart-Betriebsmodell: Anzahl der Storefronts, Administrator-Modi, Vendor-Nutzung, Richtlinie für Customer Sharing, Regeln zur Objektfreigabe, Erweiterungen und externe Systeme. Bestimmen Sie für jede Entität, ob sie global, Storefront-spezifisch, geteilt, vendor-eigen oder erweiterungseigen ist.
Empfehlungsbeispiel
Erstellen Sie eine einseitige Zuständigkeitsübersicht für je ein Product, eine Category, einen Customer, eine CMS Page, eine Promotion, eine Shipping Method, einen Vendor und eine Order. Zeigen Sie, welche Storefronts jedes Objekt sehen oder bearbeiten dürfen und ob Werte je Storefront unterschiedlich sein können.
Bestehensbedingung
Jeder repräsentative Datensatz besitzt den richtigen globalen, Storefront-spezifischen, geteilten oder vendor-eigenen Umfang, und Administratoren können erklären, warum er in jedem vorgesehenen Kontext erscheint.
Fehler 2: Features, Options und Product Variations vermischen
Was schiefgeht
Quellattribute und Varianten werden derjenigen CS-Cart-Struktur zugeordnet, die den Wert technisch akzeptiert. Product Features, Options und Product Variations erfüllen unterschiedliche Zwecke: beschreibende und filterbare Informationen, Customer-Auswahlen sowie gruppierte verkaufbare Products mit eigener Identität. Werden sie als austauschbar behandelt, können Filterung, Auswahl auf der Product-Seite, Preisaufschläge, Bilder, Bestand oder SKU-Verantwortung beschädigt werden.
Frühwarnzeichen
| Verhalten des Quellwerts | Falsches Zielsignal |
|---|---|
| Er beschreibt ein Product und unterstützt Filterung. | Er wird nur als Customer Option angelegt. |
| Er verändert die verkaufbare SKU oder den Bestand. | Er wird als beschreibender Feature-Text gespeichert. |
| Er ergänzt eine Auswahl oder einen Modifier ohne eigenen Bestand. | Er erzeugt unnötige eigenständige Product-Datensätze. |
| Eine Variation benötigt ein eigenes Bild oder eigene Listing-Präsenz. | Alle Auswahlen bleiben in einem generischen Product verborgen. |
Vorbeugung
Klassifizieren Sie jeden wichtigen Wert nach seinem Zweck: Beschreibung, Filter, Vergleich, Buyer Selection, Preis- oder Gewichtsaufschlag, SKU-Identität, Bestandsverantwortung, Bildverantwortung und Listing-Sichtbarkeit. Verwenden Sie Features für beschreibende/filterbare Eigenschaften, geeignete Option-Strukturen für nicht identitätsbildende Auswahlmöglichkeiten und Product Variations, wenn verwandte verkaufbare Products eine gruppierte Auswahl und eigene Product-Datensätze benötigen.
Empfehlungsbeispiel
Bei einem Hemd kann Material als beschreibendes Feature dienen, Größe und Farbe können variationsfähige Werte sein, wenn jede Kombination eigene SKU und eigenen Bestand besitzt, und Geschenkverpackung bleibt eine Buyer Choice ohne eigenen Bestand. Prüfen Sie, wie Farbvarianten in Listings erscheinen und wie die Größenauswahl auf der Product-Seite funktioniert.
Bestehensbedingung
Repräsentative Product-Familien erhalten korrektes Filter-, Vergleichs-, Buyer-Selection-, SKU-, Bestands-, Bild- und Listing-Verhalten, ohne künstliche Kombinationen oder eingeebnete Kennungen.
Fehler 3: Storefront-Zuordnung und Regeln zur Objektfreigabe verlieren
Was schiefgeht
Objekte werden in alle Storefronts kopiert oder unnötig isoliert, weil die Migration das Sharing-Verhalten von CS-Cart ignoriert. Products können Storefront-spezifische Eigenschaften tragen, Categories bestimmen die Storefront-Platzierung, manche Objekte werden unverändert geteilt und andere Werte sind global. Eine pauschale Duplizierungsstrategie führt zu auseinanderlaufender Pflege; eine pauschale Sharing-Strategie zeigt falsche Inhalte oder kommerzielle Bedingungen.
Frühwarnzeichen
| Umfangssignal | Entstehendes Risiko |
|---|---|
| Jeder Storefront erhält ein doppeltes Product. | Aktualisierungen laufen auseinander und Kennungen vervielfachen sich. |
| Categories werden als global teilbar behandelt. | Storefront-Platzierung von Products wird falsch. |
| Gemeinsame Promotions oder Shipping Methods werden unabhängig neu erstellt. | Gleichartige Regeln entwickeln sich zwischen Storefronts auseinander. |
| Globale Status oder Profile Fields sollen je Storefront unterschiedlich sein. | Administratoren versuchen eine nicht unterstützte oder irreführende Trennung. |
Vorbeugung
Klassifizieren Sie Objekte als global, Storefront-spezifisch, Storefront-übergreifend konfigurierbar oder unverändert geteilt. Erhalten Sie Product- und Category-Zuordnungen gemeinsam und definieren Sie, welche Product-Werte je Storefront abweichen dürfen. Vermeiden Sie Duplikation, wenn das CS-Cart-Sharing-Modell auch künftig der vorgesehene Verwaltungsansatz ist.
Empfehlungsbeispiel
Für zwei regionale Storefronts kann dasselbe Core Product geteilt werden, wenn dies fachlich passt. Ordnen Sie es den Categories zu, die es in den jeweiligen Storefronts platzieren, und erhalten Sie Storefront-spezifische Preise oder Beschreibungen nur dort, wo der Betrieb bewusst abweicht. Wirklich gemeinsame Shipping- oder Content-Objekte bleiben unter einem Zuständigkeitsmodell.
Bestehensbedingung
Products, Categories, Customers, Content, Promotions, Shipping Methods und andere scoped Objects erscheinen exakt in den vorgesehenen Storefronts, ohne unbeabsichtigte Duplikation oder Freigabe.
Fehler 4: Vendor-Verantwortung als Product-Attribut behandeln
Was schiefgeht
In einem Marketplace wird ein Vendor auf einen Namen reduziert, der einem Product angehängt ist. Vendor-Administratoren, Vendor-Status, Product-Verantwortung, Order-Kontext, Fulfillment-Verantwortung, Kommunikation und finanzielle Beziehungen werden nicht erhalten. Products können sichtbar sein, während der Marketplace nicht mehr verwalten kann, wem sie gehören, wer sie pflegt und wer sie erfüllt.
Dasselbe Problem tritt auf, wenn ein Source Marketplace Sellers in benutzerdefinierte Tabellen oder einer Erweiterung statt in einem sauberen Vendor-Modell gespeichert hat.
Frühwarnzeichen
| Vendor-Signal | Fehlermuster |
|---|---|
| Seller-Name ist der einzige migrierte Vendor-Wert. | Administrative und operative Identität fehlen. |
| Vendor-eigene Products werden als Marketplace-eigene Products importiert. | Seller-Pflege und Reporting werden unzuverlässig. |
| Inaktive oder ausstehende Vendors werden ausgelassen. | Product-Sichtbarkeit und Account-Zugriff verändern sich unerwartet. |
| Vendor Orders werden ohne Company- oder Seller-Kontext geprüft. | Support und Fulfillment können den Verantwortlichen nicht bestimmen. |
Vorbeugung
Übertragen Sie Vendor-Identität, Status, Administratoren, Products, Storefront-Sichtbarkeit, Order-Beziehungen, Fulfillment-Verantwortung und externe Seller-Kennungen. Behandeln Sie vendor-erzeugte Features, Extension Records, Provisionen oder Payout-Informationen als eigenständig verantwortete Daten statt als gewöhnliche Product- oder Customer-Felder.
Empfehlungsbeispiel
Prüfen Sie einen aktiven Vendor mit vielen Products, einen deaktivierten Vendor, dessen Historie lesbar bleiben muss, und eine Order mit vendor-eigenen Artikeln. Bestätigen Sie, wer jedes Product administrieren darf und wer Fulfillment- und Support-Verantwortung trägt.
Bestehensbedingung
Repräsentative Vendors behalten klare Identität, Status, Administratorzugriff, Product-Verantwortung, Storefront-Sichtbarkeit, Order-Kontext, Fulfillment-Verantwortung und externe Nachverfolgbarkeit über den Marketplace hinweg.
Fehler 5: Products importieren, ohne ihre Verkaufbarkeit zu erhalten
Was schiefgeht
Products gelten als erfolgreich migriert, weil Titel, Preise und Mengen vorhanden sind. Status, Sichtbarkeit, Mindest- oder Höchstmengen, Download-Dateien, angehängte Dateien, Bilder, Product Codes, Returnability, Bestandsverhalten und Category-Zuordnung können trotzdem falsch sein. Verborgene oder deaktivierte Products können sichtbar werden, digitale Products als versandpflichtig behandelt werden und kaufbare Products einen falschen Bestandszustand anzeigen.
Frühwarnzeichen
| Product-Signal | Verdeckter Defekt |
|---|---|
| Nur aktive Products werden geprüft. | Hidden-, Disabled-, Discontinued- oder Direct-Link-Fälle bleiben ungetestet. |
| Product Code wird nicht als Integrationsschlüssel behandelt. | Feeds und Warehouse-Systeme erzeugen Duplikate. |
| Downloadable oder dateibasierte Products werden wie gewöhnliche Products kopiert. | Auslieferungs- und Zugriffsverhalten verschwinden. |
| Menge wird geprüft, ohne Out-of-Stock-Verhalten zu berücksichtigen. | Storefront-Verfügbarkeit weicht von der beabsichtigten Quelle ab. |
Vorbeugung
Definieren Sie Verkaufbarkeit nach Product Class. Erhalten Sie Product Code, Status, Sichtbarkeit, Category-Platzierung, Bestandsverantwortung, Mengenregeln, digitales oder dateibasiertes Verhalten, Bilder, Versandeigenschaften und gegebenenfalls Returnability. Prüfen Sie Products sowohl im Administration Panel als auch im Storefront-Kontext der Customers.
Empfehlungsbeispiel
Verwenden Sie ein aktives physisches Product, ein verborgenes Direct-Link-Product, ein deaktiviertes historisches Product, ein Downloadable Product und ein Low-Stock-Product mit nicht standardmäßiger Out-of-Stock-Aktion. Bestätigen Sie Verwaltungs- und Customer-Verhalten.
Bestehensbedingung
Jedes repräsentative Product ist entsprechend seiner Product Class, seines Bestandsverhaltens, seiner Category-Platzierung und seines Storefront-Kontexts genau wie vorgesehen sichtbar, kaufbar, auslieferbar und wartbar.
Fehler 6: Customer Accounts, Groups und Profilbedeutung einebnen
Was schiefgeht
Customer-Datensätze werden als Name und E-Mail übertragen, während User Groups, Storefront-Account-Umfang, Profile Fields, Adressen, Tax- oder Wholesale-Kontext, Consent und Order-Beziehungen zu generischen Notizen werden. Erwartungen an gemeinsame oder getrennte Accounts können Storefront-übergreifend umgekehrt werden. Business Customers verlieren gruppenbasierte Behandlung, während doppelte Accounts entstehen, wenn dieselbe Person in mehreren Stores existiert hat.
Frühwarnzeichen
| Customer-Signal | Wahrscheinliches Problem |
|---|---|
| Password Portability wird vorausgesetzt. | Customers können nicht wie erwartet auf Accounts zugreifen. |
| User Groups werden nur als Bezeichnungen kopiert. | Preis-, Zugriffs- oder Steuerbedeutung geht verloren. |
| Storefront-Richtlinie zum Account Sharing ist unbekannt. | Ein Customer wird dupliziert oder falsch freigegeben. |
| Custom Profile Fields sind nicht klassifiziert. | Erforderlicher operativer oder Compliance-Kontext verschwindet. |
Vorbeugung
Trennen Sie Customer-Identität, Account-Zugriff, Storefront-Umfang, Gruppenmitgliedschaft, Profile Fields, Adressen, Consent, externe Kennungen und historische Order-Beziehungen. Definieren Sie Regeln für Duplikate und Aktivierung. Erhalten Sie Gruppenbedeutung nur dort, wo die Zieloperation sie weiterhin verwendet.
Empfehlungsbeispiel
Prüfen Sie einen Retail Customer, der Storefront-übergreifend geteilt wird, einen Wholesale Customer mit gruppenbasierter Behandlung, einen wahrscheinlichen Duplikatfall und einen Customer mit mehreren Adressen und Custom Profile Fields. Definieren Sie Account-Zugriff und Order-Zuordnung für jeden Fall.
Bestehensbedingung
Repräsentative Customers behalten nutzbare Identität, korrekten Storefront-Umfang, die beabsichtigte Gruppen- und Profilbedeutung, vorhersehbaren Account-Zugriff und vollständige Order-Beziehungen ohne ungeklärte Duplikate.
Fehler 7: Order-Summen erhalten, aber Status- und Zuständigkeitskontext verlieren
Was schiefgeht
Historische Orders behalten ihre Summen, verlieren aber aussagekräftigen Status, Storefront- oder Vendor-Verantwortung, Product-Group Shipping, Payment- und Shipping-Bezeichnungen, Rabatte, Steuern, Refunds, Returns, Invoices, Credit Memos oder externe Referenzen. CS-Cart kann individuelle Order-Statusnamen verwenden, während die interne Statusbedeutung weiterhin operatives Verhalten beeinflusst; Bezeichnungen allein können deshalb irreführend sein.
Frühwarnzeichen
| Order-Nachweis | Fehlende Bedeutung |
|---|---|
| Ein Statuslabel bleibt erhalten. | Der zugrunde liegende Geschäftszustand ist unklar. |
| Eine einzige Shipping Method wird angezeigt. | Multi-Vendor- oder gruppierter Shipping-Kontext geht verloren. |
| Die Endsumme stimmt. | Discounts, Tax, Refunds oder Credit Adjustments lassen sich nicht erklären. |
| Company- oder Storefront-ID fehlt. | Der verantwortliche Store oder Vendor ist nicht nachverfolgbar. |
Vorbeugung
Erstellen Sie eine historische Statuszuordnung, die Quellbedeutung erhält, ohne Gleichheit mit dem aktuellen Workflow zu erzwingen. Bewahren Sie Customer-, Storefront- oder Vendor-, Product-, Finanz-, Shipping-, Refund-, Return-, Invoice-, Credit- und External-Reference-Kontext, den Support und Reporting benötigen. Trennen Sie historische Order-Interpretation vom aktiven Payment- und Shipping-Setup.
Empfehlungsbeispiel
Verwenden Sie eine abgeschlossene Order, eine stornierte Order, eine erstattete oder retournierte Order und eine Marketplace Order mit gruppiertem Versand. Ein Support-Mitarbeiter sollte Transaktion und Verantwortlichen erklären können, ohne das Quellsystem erneut zu öffnen.
Bestehensbedingung
Repräsentative Orders bleiben über Customer, Store oder Vendor, Products, Status, finanzielle Anpassungen, Shipping, Refunds oder Returns und externe Abstimmung hinweg verständlich.
Fehler 8: Content ohne Layout-, Block- und URL-Verantwortung übertragen
Was schiefgeht
CMS Pages, Blog Posts, Product-Beschreibungen und Categories werden übertragen, Layouts, Blocks, Menüs, Theme Templates, SEO Names, Redirects und von Erweiterungen eingefügte Inhalte dagegen nicht. Text kann im Administration Panel vorhanden sein, während Customer Journeys, Landing Pages oder Mobile Layouts defekt sind. Das Kopieren von Source Markup kann außerdem Code erhalten, den das CS-Cart-Theme nicht sicher rendert.
Frühwarnzeichen
| Content-Signal | Fehlermuster |
|---|---|
| Page Text wird ohne Layout geprüft. | Wichtige Blocks und Calls to Action verschwinden. |
| Product-URLs werden ohne Category- oder SEO-Name-Kontext verglichen. | Prioritätsrouten ändern sich unerwartet. |
| Source HTML enthält Scripts oder Template Tags. | Content wird schlecht dargestellt oder erzeugt Sicherheits- und Wartungsrisiken. |
| Von Apps erzeugte Tabs oder Badges werden als Product-Felder behandelt. | Der Wert existiert, aber die Storefront-Komponente fehlt. |
Vorbeugung
Trennen Sie Content-Datensätze von Darstellung und Routing. Inventarisieren Sie priorisierte Pages, Blog Posts, Product- und Category-URLs, Menüs, Layouts, Blocks, Theme Templates und erweiterungseigene Komponenten. Erhalten Sie sauberen Content und SEO-Intent und weisen Sie Darstellung sowie Redirect-Implementierung den jeweiligen Zielverantwortlichen zu.
Empfehlungsbeispiel
Für eine Campaign Landing Page sollten freigegebener Text und Media erhalten, die alte URL zugeordnet, Layout und Promotional Blocks in CS-Cart neu aufgebaut und anschließend geprüft werden, ob die Seite auf Desktop und Mobile zu den vorgesehenen Category- und Product-Pfaden führt.
Bestehensbedingung
Priorisierte Inhalte und Entry URLs behalten beabsichtigte Bedeutung, Ziel, Navigationspfad und Customer-facing Darstellung, ohne von Source-spezifischem Markup oder Erweiterungen abhängig zu sein.
Fehler 9: Erweiterungseigene Tabellen, Hooks und externe Kennungen ignorieren
Was schiefgeht
Berücksichtigt werden nur Core-CS-Cart-Tabellen und API-Entitäten. Erweiterungen, individueller Code, Database Tables, Hooks, Imports, Exports, Feeds, ERP-Verbindungen und Marketplace-Integrationen können Felder und Workflows außerhalb des gewöhnlichen Product-, Customer- und Order-Modells verantworten. Die Neuinstallation einer Erweiterung garantiert nicht, dass historische Datensätze, Einstellungen, Kennungen oder Beziehungen wiederhergestellt werden.
Frühwarnzeichen
| Dependency-Signal | Entstehendes Risiko |
|---|---|
| Die Erweiterungsliste enthält keine Spalte zur Datenverantwortung. | Custom Records werden stillschweigend ausgelassen. |
| Ein Modul wird neu installiert und danach als vollständig angenommen. | Einstellungen und historische Daten fehlen weiterhin. |
| Externe Systeme gleichen nur über Source Database IDs ab. | Neue Datensätze werden dupliziert oder Updates treffen das falsche Objekt. |
| Custom Hooks verändern Order- oder Product-Verhalten. | Korrekte Core Data erzeugen andere Geschäftsergebnisse. |
Vorbeugung
Inventarisieren Sie jede Erweiterung und Anpassung nach verantworteten Tabellen, Feldern, Einstellungen, Hooks, Storefront-Komponenten, API-Endpunkten, externen Kennungen und fortbestehendem Geschäftszweck. Bewahren Sie Cross-Reference Keys für weiterführende Systeme und stellen Sie obsolete Abhängigkeiten ein, statt sie automatisch nachzubauen.
Empfehlungsbeispiel
Für einen ERP Connector und eine Product-Bundle-Erweiterung sollten Product Code und External-ID-Vertrag, benutzerdefinierte Tabellen, Aktualisierungsrichtung und Storefront-Verhalten dokumentiert werden. Bestätigen Sie, ob die Zielerweiterung dieselbe Struktur verwenden kann oder eine neu gestaltete Beziehung benötigt.
Bestehensbedingung
Jede geschäftskritische Erweiterung und Integration besitzt einen expliziten Datenverantwortlichen, einen Identity Contract, eine Zielbehandlungsentscheidung und eine funktionierende Abhängigkeit ohne verborgene benutzerdefinierte Tabellen oder doppelte Synchronisierung.
Fehler 10: Historische Bezeichnungen als aktuelle Commerce-Konfiguration behandeln
Was schiefgeht
Payment-, Shipping-, Tax-, Promotion- und Checkout-Bezeichnungen in historischen Orders werden als Wiederherstellung des aktuellen Shop-Verhaltens interpretiert. Aktive Methoden benötigen jedoch Konfiguration, Zugangsdaten, Tarife, Standorte, Einschränkungen, Steuern, Promotions und Storefront-Kontext. Eine gut lesbare historische Order beweist nicht, dass ein neuer Customer den vorgesehenen Kaufweg erfolgreich abschließen kann.
Frühwarnzeichen
| Historischer Nachweis | Falsche Annahme |
|---|---|
| Payment Name erscheint in alten Orders. | Gateway und Zugangsdaten sind aktiv. |
| Shipping Charge ist erhalten. | Aktuelle Methoden können denselben Lieferpfad berechnen. |
| Tax Amount ist lesbar. | Aktuelle Standorte, Products, Customers und Raten erzeugen die beabsichtigte Steuer. |
| Coupon Code existiert in der Historie. | Die aktuelle Promotion besitzt korrekte Bedingungen und Limits. |
Vorbeugung
Erhalten Sie historische Bezeichnungen für die Interpretation von Transaktionen, bauen Sie aber aktuelles Payment-, Shipping-, Tax-, Promotion-, Notification- und Checkout-Verhalten unter der tatsächlichen CS-Cart-Konfiguration und Storefront-Verantwortung neu auf. Halten Sie beide Zwecke getrennt, damit Historie nicht als Betriebsbereitschaft erscheint.
Empfehlungsbeispiel
Für einen Shop mit Inlandszustellung, internationalem Versand, Wholesale Customers und Pickup sollte jeder aktuelle Kaufpfad unabhängig definiert werden. Historische Orders können Bezeichnungen und Erwartungen erklären, dürfen aber keine Live-Regeln automatisch erzeugen.
Bestehensbedingung
Historische Orders bleiben verständlich, während jede aktuelle Payment-, Shipping-, Tax-, Promotion- und Checkout-Regel eine bewusste Zielkonfiguration und einen Verantwortlichen besitzt.
Fazit
Die Qualität einer CS-Cart-Migration hängt davon ab, Betriebsumfang und Verhalten zu erhalten: Storefront-Zuordnung, Zweck von Features und Variations, Vendor-Verantwortung, Customer- und Order-Kontext, Content-Darstellung, Erweiterungsdaten und aktuelle Konfiguration. Der stärkste Präventionsansatz trennt gemeinsame von scoped Records, Standardentitäten von Custom Ownership und historische Nachweise vom aktuellen Commerce-Verhalten.
Häufige Fragen
Was sollte vor der Datenzuordnung zu CS-Cart bestätigt werden?
Bestätigen Sie das tatsächliche Installationsmodell, die Zahl der Storefronts, Vendor-Nutzung, aktivierte Module, Regeln zur Objektfreigabe, Richtlinie für Customer Accounts, Erweiterungen und externe Systeme. Diese Entscheidungen bestimmen Datensatzverantwortung, bevor Field Mapping beginnt.
Sind Product Features, Options und Product Variations austauschbar?
Nein. Features beschreiben oder filtern Products, Options unterstützen Buyer Choices oder Modifiers und Product Variations gruppieren verwandte verkaufbare Products, die ihre eigene Identität, Bestände, Bilder und Listing-Funktion behalten können.
Warum kann ein Product im falschen CS-Cart-Storefront erscheinen?
Product-Sichtbarkeit hängt von Storefront- und Category-Zuordnung, Sharing-Regeln, Administrator-Kontext und Storefront-spezifischen Eigenschaften ab. Wird der Product-Datensatz ohne seinen Umfang kopiert, kann er falsch sichtbar oder verborgen sein.
Wie sollten Multi-Vendor-Seller-Daten behandelt werden?
Erhalten Sie Vendor-Identität, Status, Administratoren, Product-Verantwortung, Order-Kontext, Fulfillment-Verantwortung und externe Seller-Kennungen. Ein Vendor ist eine operative Entität und kein bloßes Product-Feld.
Warum sind Custom Order Status bei der Migration riskant?
Eine vertraute Bezeichnung kann eine andere zugrunde liegende Geschäftsbedeutung verbergen. Historische Status benötigen eine bedeutungsbasierte Zuordnung, damit Support und Reporting korrekt bleiben, ohne anzunehmen, dass der Source Workflow zum aktuellen Target Workflow wird.
Stellt die Neuinstallation einer CS-Cart-Erweiterung ihre Daten automatisch wieder her?
Nicht zwingend. Erweiterungen können benutzerdefinierte Tabellen, Einstellungen, Felder, Storefront Blocks und externe Kennungen besitzen. Daten und Verhalten benötigen eine explizite Entscheidung zur Zielbehandlung.