Wenn CS-Cart als Zielplattform ausgewählt wird, muss die Vorbereitung damit beginnen, das künftige Betriebsmodell eindeutig festzulegen: eine vom Händler betriebene Store-Builder-Umgebung oder ein Multi-Vendor-Marketplace. Beide nutzen verwandte Katalogstrukturen, doch ein Marketplace ergänzt Vendor-Verantwortung, Vendor-Administratoren, seller-spezifische Products und Orders, Provisionen, Accounting-Datensätze, Auszahlungen, Storefront-Berechtigungen und erweiterungsabhängige Geldflüsse.
Ziel der Vorbereitung ist, belastbare Quelldaten und Nachweise bereitzustellen, bevor die Migrationskonfiguration endgültig festgelegt wird. Für jeden wichtigen Bereich sollten Aktion, Verantwortlicher, Nachweis und Bereitschaftsbedingung dokumentiert sein. Product Options, Features und Variations müssen getrennt bleiben; Storefront-Umfang muss explizit sein; Vendor-Datensätze dürfen nicht auf Customer Accounts reduziert werden; und historische Orders müssen Seller- und Finanzkontext bewahren.
CS-Cart-Edition, Version, Storefronts und Zugriff bestätigen
Dokumentieren Sie die genaue CS-Cart- oder Multi-Vendor-Edition, Version, Installationspfad, Datenbank, aktiven Storefronts, Companies oder Vendors, Sprachen, Währungen, Themes, Plattform-Erweiterungen und externen Synchronisierungen. Langjährig betriebene Installationen können aktualisierte Product-Variation-Strukturen, nicht mehr verwendete Erweiterungen, Custom Templates oder Datenbankanpassungen enthalten, die den verfügbaren Quelldatensatz verändern.
Bereiten Sie den Quellzugriff vor, der für den gewählten Migrationspfad erforderlich ist. Der technische Verantwortliche sollte die richtige Datenbank, den Dateibaum, die Administrationsumgebung und mögliche Zugriffsbeschränkungen bestätigen. Bei Multi-Vendor sollten zusätzlich Marketplace-Administrator und die Personen identifiziert werden, die Vendor-Beziehungen und Accounting-Datensätze fachlich verstehen.
| Aktion | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Edition und Version bestätigen | Technischer Verantwortlicher | Versions- und Lizenz-/Editionsnachweis | Annahmen zu Store Builder und Multi-Vendor werden nicht vermischt. |
| Storefront-Umfang dokumentieren | Commerce-Verantwortlicher | Storefront-Liste, Domains, Sprachen, Währungen, Company-Zuordnungen | Jeder aktive Storefront hat einen dokumentierten Geschäftszweck. |
| Quellzugriff bestätigen | Hosting- oder Datenbankverantwortlicher | Verbindungsstatus, Datenbankpräfix, Hinweis zum File Root | Erforderliche Quelldatensätze und Dateien sind erreichbar. |
| Themes und Erweiterungen inventarisieren | Entwickler oder Agentur | Aktives Theme, Erweiterungsliste, Übersicht zu benutzerdefinierte Tabellen und geänderten Dateien | Core-Datensätze und erweiterungseigenes Verhalten lassen sich trennen. |
| Externe Systeme identifizieren | Integrationsverantwortlicher | Liste von ERP/PIM/WMS/Marketplace/Accounting und stabile Kennungen | Werte, die außerhalb von CS-Cart gepflegt werden, haben eine benannte Autorität. |
Führen Sie nach dem Stichtag der Nachweiserhebung ein Änderungsprotokoll. Neue Erweiterungen, Änderungen an Product Variations, Vendor-Zusammenführungen, Storefront-Änderungen oder Category-Restrukturierungen sollten während der Vorbereitung dokumentiert werden.
Products, Options, Features, Variations und Categories vorbereiten
CS-Cart trennt Product-Eigenschaften, auswählbare Options, Product Features, Variations, Categories, Quantity Discounts, Download-Dateien, Bilder, SEO-Werte und Storefront-Zuordnungen. Options erfassen Buyer Choices oder Eingaben. Features beschreiben strukturierte Merkmale und können Filterung oder Vergleich unterstützen. Variations gruppieren ähnliche Products anhand von Feature-Werten und können eine eigenständige Product-Identität besitzen.
Erstellen Sie ein Product-Inventar, das für jeden kommerziellen oder beschreibenden Wert den zuständigen Datenträger identifiziert.
| Quellmuster | Vorbereitungsaktion | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Auswählbare Option | Option Type, Variants, Pflichtstatus, Kombinationsregeln und Preis-/Gewichtswirkung dokumentieren | Product- und Option-Zuordnungsexport | Buyer-Choice-Verhalten ist explizit. |
| Product Variation | Variation Group, Feature-Werte, Product IDs, SKU, Preis, Bestand, Bilder und Status dokumentieren | Variation-Group-Manifest | Jedes unabhängig verwaltete Product bleibt identifizierbar. |
| Product Feature | Feature Group, Typ, Werte, Category-/Storefront-Umfang und Filternutzung dokumentieren | Feature-Inventar | Beschreibende und Discovery-Werte sind von Options getrennt. |
| Product in mehreren Categories | Alle Zuweisungen, primären Merchandising-Kontext und Storefront-Umfang dokumentieren | Product-to-Category-Export | Gemeinsame Platzierung ist sichtbar, ohne von doppelten Products auszugehen. |
| Downloadable Product | Dateien, Aktivierungsbedingungen, Product-Beziehung und Originalpfad dokumentieren | Product-/File-Manifest | Dateien und Product-Beziehungen sind verfügbar. |
| Mengen- oder Wholesale-Preis | Product, Schwellenwert, User-Group-/Customer-Kontext, Währung und Betrag dokumentieren | Pricing-Inventar | Bedingte kommerzielle Werte werden nicht auf den Basispreis reduziert. |
Dokumentieren Sie unzulässige oder zulässige Option-Kombinationen, Dateianhänge, Required Products, Bundles, Reward-Beziehungen und erweiterungseigene Product-Felder, sofern sie aktiv sind. Ähnlich benannte Options und Features dürfen nicht zusammengeführt werden, bevor geklärt ist, ob eines eine Käuferauswahl und das andere eine Spezifikation darstellt.
Storefront-, Company- und Katalogumfang dokumentieren
CS-Cart kann mehrere Storefronts verwenden, und Multi-Vendor kann Vendors einführen, deren Products, Administratoren, Pages, Versandmethoden und Orders unterschiedlichen Marketplace-Teilnehmern gehören. Erstellen Sie eine Scope-Matrix, die zeigt, welche Datensätze zum gemeinsamen Katalog, zu einem bestimmten Storefront, zu einem Vendor oder zu einem externen Channel gehören.
| Umfangsbereich | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Storefront-Domains und -Sprachen | Plattformadministrator | Storefront-Einstellungen und Domain-Liste | Jeder öffentliche Store-Kontext ist identifiziert. |
| Product- und Category-Verfügbarkeit | Katalogverantwortlicher | Storefront-/Company-Zuordnungsexport | Gemeinsame und eingeschränkte Katalogdatensätze sind unterscheidbar. |
| Features und Filter | Merchandising-Verantwortlicher | Feature-to-Category- und Storefront-Map | Discovery-Vokabulare besitzen expliziten Umfang. |
| CMS Pages und Layouts | Content-Verantwortlicher | Page-, Block-, Layout-, Menü- und Storefront-Inventar | Inhalte und Darstellung sind dem richtigen Storefront zugeordnet. |
| Company- oder Vendor-Verantwortung | Marketplace-Verantwortlicher | Product-, Order-, Administrator- und Page-Zuordnungen | Seller-eigene Datensätze werden nicht standardmäßig als Marketplace-eigen behandelt. |
Vendors, Administratoren, Plans und finanzielle Beziehungen vorbereiten
Dieser Abschnitt gilt, wenn das Quell- oder Zielbetriebsmodell Multi-Vendor einschließt. Ein Vendor ist ein unabhängiges verkaufendes Unternehmen mit zugeordneten Administratoren, Products, Orders, Versandkontext, Status und Accounting-Beziehungen. Vendor Plans, Transaktionsgebühren, Provisionen, Payouts, Withdrawals und Marketplace-Payment-Erweiterungen können zusätzliche Datensätze erzeugen.
Erstellen Sie ein Vendor-Ledger, das aktive, ausstehende, deaktivierte, zusammengeführte, historische und doppelte Vendors unterscheidet. Dokumentieren Sie die Administratoren jedes Vendors, Product- und Order-Verantwortung, Plan- oder Provisionskontext, Nachweise zum Kontostand, Payout- und Withdrawal-Datensätze sowie externe Seller-Kennungen.
| Marketplace-Datensatz | Vorbereitungsaktion | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Vendor-Identität | Company ID, Status, rechtliche/Kontaktdaten, Storefront Page und externen Schlüssel dokumentieren | Vendor-Inventar | Jeder beizubehaltende Seller besitzt eine vorgesehene Identität. |
| Vendor-Administratoren | User Account, Vendor-Beziehung, Status und Berechtigungskontext dokumentieren | Administrator-to-Vendor-Map | Seller-Zugriffsbeziehungen sind dokumentiert. |
| Vendor-eigene Products | Product- und Category-Verantwortung, Freigabestatus und Storefront-Umfang dokumentieren | Product-to-Vendor-Export | Katalogverantwortung ist explizit. |
| Vendor Plans oder Provisionen | Plan, Gebühr, Provision, Gültigkeitsdaten und verantwortliche Erweiterung dokumentieren | Plan-/Provisionsinventar | Finanzregeln sind von gewöhnlichen Vendor-Profilfeldern getrennt. |
| Accounting, Payouts und Withdrawals | Transaktionstyp, Vendor, Betrag, Status, Datum und zugehörige Order dokumentieren | Stichproben der Finanzhistorie | Marketplace-Finanzkontext ist nachvollziehbar. |
| Geteilte oder vendor-spezifische Orders | Parent-/Suborder-Beziehungen und verantwortlichen Vendor dokumentieren | Repräsentative Order-Gruppen | Historische Seller-Verantwortung bleibt interpretierbar. |
Gehen Sie nicht davon aus, dass jeder Customer mit Company Name ein Vendor ist oder ein Vendor-Administrator-Account den vollständigen Seller-Datensatz enthält.
Customers, User Groups, Adressen und Account-Felder vorbereiten
CS-Cart Customer-Datensätze können Adressen, User Groups, Freigabestatus, Profile Fields, Newsletter, Rewards, Reviews und externe Kennungen enthalten. Multi-Vendor umfasst zusätzlich Vendor-Administratoren, deren Zuständigkeit von gewöhnlichen Customers getrennt werden muss.
| Datensatzbereich | Vorbereitungsaktion | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Customer-Identität | Duplikate, gemeinsame E-Mail-Adressen, Guests, Freigaben und externe Schlüssel identifizieren | Customer-Ausnahmeliste | Identitätsausnahmen besitzen Verantwortlichen und Entscheidung. |
| User Groups | Mitgliedschaft und sämtliche Auswirkungen auf Preis, Steuer, Zugriff oder Content dokumentieren | Group-to-Rule-Matrix | Gruppenbedeutung ist über die Bezeichnung hinaus dokumentiert. |
| Profile Fields | Verantwortlichen, Typ, Pflichtstatus und Nutzung dokumentieren | Profile-Field-Inventar | Aktive Custom Values besitzen eine Zielentscheidung. |
| Adressen | Wiederverwendbare Profile von Order-Zeitpunkt-Snapshots trennen | Customer- und Order-Beispiele | Account- und Transaktionsdatensätze bleiben getrennt. |
| Vendor-Administratoren | Seller-Admin-Identität mit dem Vendor-Datensatz verbunden halten | Administrator-Map | Marketplace-Zugriff wird nicht in Customer-Segmentierung eingeebnet. |
| Externe Account-IDs | CRM-, ERP-, Loyalty- oder B2B-Schlüssel dokumentieren | Identifier-Map | Weiterführende Systeme können dasselbe Konto wiederfinden. |
Orders, Seller-Verantwortung, Summen und historischen Status vorbereiten
Order-Vorbereitung sollte erhalten, was gekauft wurde, von wem, von welchem Seller, zu welchem Preis und unter welchem historischen Payment-, Shipping-, Steuer-, Rabatt- und Statuskontext. Multi-Vendor Orders können geteilt sein, sodass jeder Vendor einen zugehörigen Teil des ursprünglichen Kaufs verwaltet.
| Order-Nachweis | Vorbereitungsaktion | Bereitschaftsbedingung |
|---|---|---|
| Product- und Variation-Positionen | Product ID, Variation/Features/Options, Seller, Menge, Preis und Snapshot-Text dokumentieren | Gekaufte Artikel und Seller-Verantwortung bleiben interpretierbar. |
| Parent- und Vendor-Orders | Ursprüngliche Order und zugehörige seller-spezifische Orders dokumentieren | Multi-Vendor-Historie wird nicht in unverbundene Transaktionen aufgeteilt. |
| Billing- und Shipping-Adressen | Order-Snapshots getrennt von Customer-Profilen bewahren | Historische Adressnachweise sind vollständig. |
| Steuern, Shipping, Rabatte, Gebühren und Rewards | Jede wesentliche Summe und die verantwortliche Erweiterung inventarisieren | Endbeträge lassen sich erklären. |
| Payment- und Fulfillment-Referenzen | Bezeichnungen, Transaktions-IDs, Versandmethoden, Tracking und verantwortlichen Vendor dokumentieren | Historischer Verarbeitungskontext ist nachvollziehbar. |
| Status, Refunds und Kommentare | Reihenfolge, Sichtbarkeit, betroffenen Seller und zugehörige Datensätze dokumentieren | Mitarbeitende können den historischen Lebenszyklus interpretieren. |
| Accounting-Referenzen | Orders mit Provisionen, Payouts, Withdrawals oder Balance-Datensätzen verknüpfen, sofern relevant | Marketplace-Finanzhistorie bleibt verbunden. |
Historische Orders sollten nicht anhand aktueller Product-, Vendor-Plan-, Provisions-, Versand- oder Payment-Einstellungen neu berechnet werden.
Plattform-Erweiterungen, Themes, benutzerdefinierte Felder und Integrationen inventarisieren
CS-Cart-Erweiterungen können Product Variations, SEO Names, Vendor Plans, Marketplace Payments, Rewards, Reviews, Layouts, benutzerdefinierte Felder, Order Totals, Reports oder externe Verbindungen verantworten. Verwenden Sie „Plattform-Erweiterung“ oder den exakten Komponentennamen, damit Plattformfunktionalität nicht mit Erweiterungen des Migration Service verwechselt wird.
| Auswirkung der Abhängigkeit | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Product- oder Katalogerweiterung | Felder/Tabellen, Product IDs, Einstellungen und repräsentative Datensätze | Aktive Katalogwerte besitzen einen definierten Verantwortlichen. |
| Vendor- oder Accounting-Erweiterung | Vendor-, Plan-, Provisions-, Payout- oder Withdrawal-Datensätze | Marketplace-Finanzdaten sind separat klassifiziert. |
| Payment- oder Shipping-Erweiterung | Historische Referenzen und Konfigurationszusammenfassung | Transaktionsnachweise sind von aktueller Store-Konfiguration getrennt. |
| SEO- oder Routen-Erweiterung | SEO Names, Rewrite-Einstellungen und Redirect-Tabellen | Wichtige Quellpfade können rekonstruiert werden. |
| Theme- oder Layout-Anpassung | Theme-Dateien, Layout-/Block-Zuordnungen, Screenshots | Geschäftsinhalte sind von Darstellung getrennt. |
| ERP-/PIM-/WMS-/Marketplace-Integration | Autorität, Synchronisierungsrichtung und stabile IDs | Weiterführende Systeme können wieder mit Zielentitäten verbunden werden. |
| benutzerdefinierte Tabelle oder Field | Schema, Parent Keys, Verbraucher und Geschäftszweck | Jeder aktive Custom Value hat eine Disposition. |
CMS Pages, SEO Names, Media und Routennachweise vorbereiten
Bereiten Sie CMS Pages, gegebenenfalls Blog Posts, Product- und Category-Beschreibungen, Vendor Pages, Menüs, Layouts, Blocks, Banner, Anhänge und Media nach Verantwortlichem und Storefront vor. Dokumentieren Sie Sprache, Status, Route, Storefront, Vendor-Beziehung, eingebettete Links und vorgesehene Behandlung.
Für priorisierte Product-, Category-, Feature-, CMS-, Vendor- und Blog-Routen dokumentieren Sie Quellobjekt, Storefront, Sprache, SEO Name, aktuellen Pfad, geschäftliche Bedeutung und Redirect- oder Ausschlussentscheidung. Blog Posts, Vendor-Storefront-Pages und CMS Blocks können ähnliche Bezeichnungen haben und trotzdem unterschiedlichen Verantwortlichen gehören; erfassen Sie IDs, Storefront-Umfang, Autor- oder Vendor-Beziehung, Media und Menüplatzierung separat. Bewahren Sie Originalbilder, Download-Dateien, Anhänge und Theme Assets außerhalb des Datenbank-Backups auf.
Backup- und Input-Readiness-Paket erstellen
| Paketbestandteil | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Datenbank-Backup | Datenbankadministrator | Dump mit Zeitstempel und Hinweis zum Datenbankpräfix | Alle Core-, Extension- und Vendor-Tabellen des vorgesehenen Stores sind enthalten. |
| Dateien und Media | Hosting- oder technischer Verantwortlicher | Dateiarchiv oder erreichbarer Source Tree | Bilder, Downloads, Anhänge, Themes und Erweiterungen sind verfügbar. |
| Editions- und Umfangsdatensatz | Plattformverantwortlicher | Version, Edition, Storefronts, Companies/Vendors, Sprachen, Währungen | Beziehungen von Store Builder und Multi-Vendor sind explizit. |
| Zugriffsregister | Projektverantwortlicher | Access Owner und Verbindungsstatus | Erforderlicher Zugriff ist verfügbar, ohne Zugangsdaten offenzulegen. |
| Änderungsprotokoll | Store Administrator | Strukturelle Änderungen nach dem Nachweis-Stichtag | Späte Änderungen können bewusst eingearbeitet werden. |
Repräsentative Migrations-Teststichproben auswählen
Erstellen Sie ein Stichprobenmanifest mit Source IDs, Geschäftsgrund, zugehörigem Storefront oder Vendor, verknüpften Dateien und erwarteten Quellbeziehungen. Das CS-Cart-Stichprobenmanifest ist bereit, wenn jede Quellerwartung, jeder Storefront- oder Vendor-Verantwortliche, jede verknüpfte Datei und jede Kennung vollständig dokumentiert und einem Prüfer zugewiesen ist.
Nehmen Sie mindestens auf:
- einfache Products sowie Products mit Options, Features, Variations, mehreren Categories, Dateien oder besonderer Preisgestaltung;
- Datensätze aus verschiedenen Storefronts;
- gewöhnliche Customers, Customers mit User Groups, Vendor-Administratoren und Custom Profile Fields;
- Standard-Orders und Orders mit Variations, ungewöhnlichen Summen, Refunds, Tracking und externen IDs;
- bei Multi-Vendor vendor-eigene Products, Parent-/Suborders, Plans, Provisionen, Payouts oder Withdrawals;
- priorisierte CMS-, Blog-, Product-, Category-, Vendor- und SEO-Routen;
- einen aktiven Datensatz einer Plattform-Erweiterung und eine Beziehung zu einem externen System.
Abschließendes CS-Cart-Readiness-Gate anwenden
| Readiness-Frage | Erforderliches Ergebnis |
|---|---|
| Sind Edition und Storefront-Umfang bekannt? | Version, Store-Builder- oder Multi-Vendor-Modell, Storefronts, Sprachen und Companies/Vendors sind dokumentiert. |
| Sind Katalognachweise vollständig? | Products, Options, Features, Variations, Categories, Preise, Media und Umfang sind repräsentiert. |
| Sind Marketplace-Beziehungen vorbereitet? | Vendors, Administratoren, seller-eigene Products, Orders, Plans und Accounting-Datensätze haben Verantwortliche. |
| Sind Customers und Orders interpretierbar? | Groups, Profile, Adressen, Status, Summen, Seller-Kontext und externe IDs sind dokumentiert. |
| Sind Erweiterungen und individuelle Daten klassifiziert? | Jede aktive Abhängigkeit besitzt Geschäftszweck und Zielentscheidung. |
| Sind Content und Routen inventarisiert? | Storefront-, Vendor-, CMS-, Blog-, Media- und SEO-Beziehungen sind dokumentiert. |
| Sind Backup, Zugriff und Stichproben bereit? | Das Source-Paket ist wiederherstellbar und repräsentative IDs sind gelistet. |
Die Vorbereitung bleibt offen, solange Edition, Vendor-Verantwortung, Product Variation, Order-Splitting, Accounting-Historie, Storefront-Umfang oder ein aktiver Erweiterungsdatensatz undokumentiert sind.
Fazit
Die Vorbereitung für CS-Cart muss das tatsächliche Betriebsmodell widerspiegeln. Products, Options, Features, Variations, Storefronts, Customers, Orders, Inhalte und Erweiterungen bilden eine Vorbereitungsebene; Multi-Vendor ergänzt Sellers, Administratoren, seller-eigene Katalogdatensätze, Split Orders, Plans, Provisionen, Payouts und Withdrawals.
Ein kontrolliertes Source-Paket macht diese Beziehungen explizit und stellt repräsentative Datensätze für die Migrationskonfiguration bereit.
Häufige Fragen
Warum müssen CS-Cart Store Builder und Multi-Vendor vor der Migration unterschieden werden?
Multi-Vendor führt Vendors, Vendor-Administratoren, seller-eigene Products, Split Orders, Plans, Provisionen, Accounting, Payouts und Withdrawals ein. Diese Beziehungen gehören nicht zu einem gewöhnlichen Store-Builder-Datenmodell.
Was ist der Unterschied zwischen CS-Cart Options, Features und Variations?
Options erfassen Buyer Choices oder Eingaben, Features beschreiben und klassifizieren Products, und Variations gruppieren unabhängig verwaltete Products anhand von Feature-Werten. Bereiten Sie sie als getrennte Nachweisgruppen vor.
Wie sollten mehrere CS-Cart-Storefronts dokumentiert werden?
Dokumentieren Sie für jeden Storefront Domain, Sprache, Währung, Theme, Products, Categories, Content, Routen, Features und Company-Umfang. Gemeinsame und eingeschränkte Datensätze sollten in einer gemeinsamen Matrix sichtbar sein.
Welche Vendor-Datensätze gehören in ein Multi-Vendor-Vorbereitungspaket?
Nehmen Sie Vendor-Profile, Status, Administratoren, Product-Verantwortung, Order-Verantwortung, Plans, Provisionen, Accounting-Transaktionen, Payouts, Withdrawals und, sofern verwendet, externe Seller-Kennungen auf.
Sollten Daten aus CS-Cart-Erweiterungen wie gewöhnliche Product- oder Order-Felder behandelt werden?
Nicht automatisch. Dokumentieren Sie Erweiterung, betroffene Entitäten, Tabellen oder Felder, repräsentative IDs und den fachlichen Verbraucher. Aktive Datensätze benötigen einen expliziten Verantwortlichen; obsolete Daten können archiviert oder ausgeschlossen werden.
Welche Orders sollten für die CS-Cart-Vorbereitung ausgewählt werden?
Verwenden Sie gewöhnliche und komplexe Orders, Positionen mit Variations und Options, unterschiedliche Summen und Status, Refunds, Tracking, externe IDs und, wenn Multi-Vendor beteiligt ist, Parent-/Suborders, Vendor-Verantwortung und verknüpfte Accounting-Datensätze.