Wenn X-Cart als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn X-Cart als Zielplattform ausgewählt wird, muss die Vorbereitung mit der exakten Generation des Quellsystems und dem installierten Modulsatz beginnen. X-Cart-Shops können sich über Versionen, Editionen, Upgrades und Modulgenerationen hinweg erheblich unterscheiden. Product-Attribute können Spezifikationen, kundenseitig auswählbare Werte oder Variation-Dimensionen darstellen. Ältere Installationen können Product Variants nutzen, während neuere Quellumgebungen Product Variations und andere Modul- oder API-Strukturen verwenden. Memberships, Multi-Vendor-Datensätze, individuelle Module und externe Integrationen verändern zusätzlich die Bedeutung von Product-, Customer- oder Order-Datensätzen.
Ziel der Vorbereitung ist, den tatsächlichen Shop zu beschreiben und nicht ein angenommenes generisches X-Cart-Schema. Jeder Bereitschaftsbereich sollte Aktion, Verantwortlicher, Nachweis und Freigabebedingung festhalten. Dadurch entsteht eine kontrollierte Grundlage für die Migrationskonfiguration.
X-Cart-Version, Edition, Zugriff und Modulherkunft feststellen
Dokumentieren Sie die exakte X-Cart-Version, Edition beziehungsweise Package-Kontext, Upgrade-Historie, aktive Module, individuelle Module, Theme, Shop- oder Marketplace-Konfiguration, API-Generation und Hosting-Umgebung. Die Versionsherkunft ist besonders wichtig, wenn der Katalog Änderungen zwischen Product Variants und Product Variations, Modulwechsel oder individuelle Datenbankmigrationen durchlaufen hat.
| Aktion | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Exakte X-Cart-Version und Update-Historie bestimmen | Technischer Verantwortlicher | Admin-Screenshot, Package-Information, Upgrade-Notizen | Quellgeneration und bekannte Upgrades sind dokumentiert. |
| Aktive und inaktive Module inventarisieren | Shopadministrator oder Entwickler | Modulliste mit Autor, Version, Status und Zweck | Jedes geschäftskritische Modul hat einen Verantwortlicher. |
| Nutzung von Product Variants oder Product Variations bestimmen | Katalog- und technische Verantwortlicher | Modulstatus, repräsentative Products, relevante Datenspeicherorte | Das aktive Variation-Modell ist eindeutig. |
| Quellverbindung und Dateizugriff bestätigen | Hosting- oder technischer Verantwortlicher | Zugriffsstatus, Allowlist- oder Authentifizierungshinweise | Die vorgesehene Quellinstallation ist erreichbar. |
| Theme- und Custom-Code-Ebenen dokumentieren | Entwickler oder Agentur | Theme-Name, Pfade individueller Module, Overrides, Deployment-Notizen | Präsentation und individuelles Verhalten sind von Core-Datensätzen unterscheidbar. |
| APIs und Synchronisierungen dokumentieren | Integrations-Verantwortlicher | API-Version, Credential-Verantwortlicher, Webhook- oder Scheduled-Job-Liste | Externe Systeme und ihre Datensatzschlüssel sind bekannt. |
Leiten Sie die aktuelle Shopstruktur nicht aus alten Projektdokumenten oder Modulrechnungen ab. Die aktive Modulliste, Datenbank, Codebasis und repräsentative Datensätze sollten übereinstimmen.
Products, Product Classes, Attribute und Variations vorbereiten
Die Product-Vorbereitung in X-Cart sollte Base Product, Product Class, Attributdefinition, Attributwert, kundenseitig auswählbaren Wert, Spezifikation und verkaufbare Variation unterscheiden. Ein Attribut namens „Color“ kann bei einem Product rein beschreibend sein und bei einem anderen eine Variation-Dimension mit eigener SKU, Preis, Bestand, Gewicht oder Bild darstellen.
Erstellen Sie ein Kataloginventar mit Product ID, SKU, Name, Status, gegebenenfalls Product Type, Category-Zuordnungen, Product Class, Attributen, Variations oder Variants, Preisen, Bestand, Gewicht, Bildern, Dateien, Memberships, Tax Classes, Vendor- oder Seller-Zuständigkeit sowie externen Identifikatoren.
| Quellmuster | Vorbereitungsaktion | Nachweis | Freigabebedingung |
|---|---|---|---|
| Class-Level-Attribut | Class, Attributgruppe, Typ, erlaubte Werte und zugeordnete Products dokumentieren | Product-Class- und Attributexport | Gemeinsame Definitionen sind von Product-spezifischen Werten trennbar. |
| Einfaches Attribut oder Spezifikation | Festhalten, ob der Wert beschreibend, filterbar oder vom Customer eingegeben wird | Repräsentative Products und Screenshots der Shop-Oberfläche | Spezifikationen werden nicht mit verkaufbaren Variations verwechselt. |
| Auswählbare Variation-Dimension | Attribute für Variations und jede aktive Kombination dokumentieren | Variation-Manifest mit SKU, Bestand, Preis, Gewicht und Bild | Jede verkaufbare Kombination besitzt eine stabile Identität. |
| Legacy-Product-Variants-Modul | Modulgeneration, Upgrade-Status und Variant-Datensätze dokumentieren | Modulnachweis und repräsentative Product IDs | Ältere und aktuelle Variation-Strukturen werden nicht unbemerkt vermischt. |
| Product mit Dateien oder digitaler Bereitstellung | Dateireferenzen und Zugriffsregeln dokumentieren | Product-/Dateiliste und Order-Beispiele | Dateien und historische Kaufbeziehungen sind verfügbar. |
| Membership- oder Vendor-eingeschränktes Product | Zugriffs- oder Zuständigkeitsbeziehung dokumentieren | Membership-/Vendor-Matrix | Product-Sichtbarkeit oder Zuständigkeit ist über die Product-Zeile hinaus dokumentiert. |
Normalisieren Sie Attributnamen erst, nachdem der Katalog-Verantwortlicher bestätigt hat, dass zwei Werte dieselbe Bedeutung tragen. Gemeinsame Product Classes können eine falsche Änderung auf viele Products übertragen.
Categories, Navigation, Membership-Sichtbarkeit und Katalogumfang vorbereiten
Categories, Menüs, Product Classes, Memberships, Vendors und Darstellung in der Shop-Oberfläche können gemeinsam die Auffindbarkeit bestimmen. Bereiten Sie Category-Hierarchie und Product-Zuordnungen vor, nehmen Sie aber nicht an, dass Category-Zugehörigkeit Navigation oder Zugriffsregeln automatisch wiederherstellt.
Bei Shops mit Memberships sollte dokumentiert werden, welche Products, Categories, Preise, Inhalte oder Kontofunktionen von einer Membership abhängen. Bei Marketplace- oder Multi-Vendor-Umgebungen sind Vendor-Zuständigkeit, Vendor-spezifische Identifikatoren, Seller-Products, gegebenenfalls Provisionen oder Settlement-Referenzen sowie die Beziehung zwischen Vendor- und Order-Datensätzen festzuhalten.
| Katalogbereich | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Category-Hierarchie | Katalog-Verantwortlicher | Parent-Child-Liste und Product-Zuordnungen | Beibehaltene Categories besitzen einen klaren Zweck und Parent. |
| Navigation und Menüs | Verantwortlicher für die Shop-Oberfläche | Menü-Screenshots und Zielliste | Menüpräsentation ist von Category-Daten getrennt. |
| Product Classes | Katalogarchitekt | Class-zu-Product- und Class-zu-Attribut-Mapping | Gemeinsame Attributvererbung ist sichtbar. |
| Membership-Einschränkungen | B2B- oder Account-Verantwortlicher | Membership-zu-Product/Category/Preis-Matrix | Zugriffs- und Preiseffekte sind explizit. |
| Vendor- oder Seller-Umfang | Marketplace-Verantwortlicher | Vendor-zu-Product- und Vendor-zu-Order-Beispiele | Seller-Zuständigkeit wird nicht in Manufacturer- oder Brand-Felder abgeflacht. |
Customers, Memberships, Adressen und Orders vorbereiten
X-Cart-Customer-Daten können Benutzer, Adressen, Memberships, Rollen, Profilfelder, Kontostatus, Marketingpräferenzen, Vendor-Profile und externe IDs umfassen. Trennen Sie Login-Identität von Customer-, Mitarbeiter-, Administrator-, Vendor- oder Membership-Rollen.
Bei Orders sollten die zum Order-Zeitpunkt geltenden Product-Beschreibungen, SKUs, Attribute, ausgewählten Variations, Preise, Rabatte, Steuern, Versand- und Zahlungsbezeichnungen, Status, Notizen, Sendungen, Refunds, Retouren, Vendor-Kontext und externe Referenzen erhalten bleiben. Dokumentieren Sie, welche Module zusätzliche Order-Positionen, Zuschläge, Subscription-Datensätze, Zahlungstransaktionen, Daten der Auftragsabwicklung oder Marketplace-Settlement-Details erzeugen.
| Datensatzbereich | Vorbereitungsaktion | Nachweis | Freigabebedingung |
|---|---|---|---|
| Benutzer und Customers | Customer-, Administrator-, Vendor- und weitere Rollen klassifizieren | Benutzer-Rollen-Inventar | Konten werden nicht allein deshalb zusammengeführt, weil sie dieselbe Tabelle verwenden. |
| Memberships | Aktuelle und historische Membership-Bedeutung dokumentieren | Membership-Liste und Customer-Beispiele | Membership-abhängiges Katalog- oder Preisverhalten hat einen Verantwortlicher. |
| Adressen | Profiladressen von Order-Snapshots trennen | Customer- und Order-Adressbeispiele | Historische Adressen bleiben interpretierbar. |
| Order-Status | Statusnamen, Prozessbedeutung und Modulabhängigkeiten festhalten | Status-Mapping und repräsentative Orders | Historischer Zustand ist ohne alte Admin-Farbe oder -Icon verständlich. |
| Order-Positionen und Summen | Variation-Werte, Rabatte, Steuern, Gebühren, Versand und moduleigene Positionen einschließen | Repräsentatives Order-Detail | Transaktion lässt sich aus ihren historischen Nachweisen rekonstruieren. |
| Externe IDs | Zahlungs-, ERP-, Marketplace-, Shipment- oder Accounting-Schlüssel dokumentieren | Identifier-Ledger | Weiterbestehende Systeme können denselben Datensatz finden. |
„Bereinigen“ Sie historische Orders nicht, indem alte Product-Namen oder Attribute durch aktuelle Katalogwerte ersetzt werden. Der Quell-Snapshot ist Teil des Nachweises.
Module, individuellen Code, Custom Tables und externe Systeme inventarisieren
X-Cart-Module können Core-Datenstrukturen erweitern oder ersetzen, Datenbanktabellen hinzufügen, Model-Verhalten ergänzen, API-Ressourcen erzeugen, Felder hinzufügen oder Darstellung in der Shop-Oberfläche steuern. Aktuelle und ältere X-Cart-Generationen verwenden zudem unterschiedliche Modulpfade und Frameworks. Erstellen Sie deshalb ein Zuständigkeits-Ledger statt lediglich einer Liste installierter Module.
| Modulauswirkung | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| Product- oder Customer-Feld | Feldschlüssel, Datentyp, Entity Verantwortlicher, repräsentative IDs | Der Wert besitzt einen Ziel-Verantwortlicher oder eine bewusste Ausschlussentscheidung. |
| Variation- oder Bestandserweiterung | Kombinationsdatensätze, Bestandsquelle, externer SKU-Schlüssel | Verkaufbare Identität und Bestandsverantwortung sind eindeutig. |
| Subscription-, Booking-, Bundle- oder Service-Datensatz | Parent Product, Customer, Order und Schedule-Beziehungen | Spezialisierte Datensätze werden nicht zu Product-Metadaten reduziert. |
| Marketplace-Modul | Vendor-, Offer-, Commission-, Payout- und Order-Beziehungen | Marketplace-Datensätze bleiben von Core-Katalogidentität getrennt. |
| Zahlungs- oder Auftragsabwicklungsmodul | Historische Transaktions-, Shipment- oder Statusreferenzen | Historie ist von zukünftiger Konfiguration trennbar. |
| Individueller Code oder Custom Table | Schema, Schlüsselbeziehungen, aktiver Ablauf, Daten-Verantwortlicher | Die Geschäftsentität, nicht nur die Tabelle, ist dokumentiert. |
| Externes PIM, ERP, WMS, CRM oder Marketplace | Zuständigkeit pro Feld und stabile IDs | Das weiterführende System of Record ist benannt. |
Klassifizieren Sie Module als aktiv und erforderlich, aktiv aber ersetzbar, nur historisch relevant, inaktiv mit zu erhaltenden Daten oder obsolet. Ein inaktives Modul kann weiterhin Datensätze besitzen, die für historische Orders benötigt werden.
Inhalte, Medien, URLs und Bestandteile der Shop-Oberfläche vorbereiten
X-Cart-Inhalte können Product- und Category-Beschreibungen, statische oder CMS Pages, Blog Posts bei entsprechender Modulfunktion, Menüs, Banner, Labels, Übersetzungen, E-Mail-Templates, Theme-Blöcke und moduleigene Seiten umfassen. Bereiten Sie Inhalte nach Zuständigkeit vor, statt jeden sichtbaren Text als einen gemeinsamen CMS-Export zu behandeln.
Dokumentieren Sie wichtige Product-, Category-, Inhalts-, Membership-, Vendor- und Modul-Routes. Nehmen Sie Canonical-Pfade, Sprach- oder Geltungsbereich der Shop-Oberfläche, Traffic-Relevanz, route-erzeugendes Modul und geplante Behandlung auf. Themes und Module können Routes erzeugen, die nicht als gewöhnliche Inhaltsdatensätze vorliegen.
Bereiten Sie Originalmedien und Dateien zusammen mit ihren Datenbankbeziehungen vor. Dokumentieren Sie externen Speicher, generierte Größen, fehlende Originale, groß-/kleinschreibungssensitive Pfade und Dateien, die durch modulspezifische Zugriffsregeln geschützt sind.
Ein wiederherstellbares X-Cart-Quellpaket erstellen
Ein Self-Hosted-X-Cart-Quellpaket sollte ein Datenbankbackup, relevante Anwendungs- und Public-Dateien, Umgebungsdetails, Modulmanifeste, Deployment- oder Upgrade-Notizen, Zugriffsstatus und ein Protokoll struktureller Änderungen nach dem Stichtag für die Nachweise enthalten.
| Paketbestandteil | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Datenbank | Datenbankadministrator | Zeitgestempelter Dump und Hinweis zur Wiederherstellbarkeit | Core- und Modultabellen stammen aus demselben Shopzustand. |
| Anwendungs- und Public-Dateien | Technischer Verantwortlicher | Dateiarchiv oder zugängliche Source Tree | Module, Themes, Medien und geschützte Dateien sind verfügbar. |
| Umgebung | Technischer Verantwortlicher | PHP-, Datenbank-, Queue-, Cache-, Storage- und Webserver-Notizen | Versionsabhängiges Verhalten kann interpretiert werden. |
| Modulmanifest | Entwickler oder Shopadministrator | Aktive/inaktive Modulliste mit Versionen | Moduleigene Entitäten sind nachvollziehbar. |
| Änderungsprotokoll | Projekt-Verantwortlicher | Späte Änderungen nach der Nachweissammlung | Neue Products, Module oder Schemaänderungen sind sichtbar. |
Repräsentative Migrationstestfälle auswählen
Erstellen Sie ein Sample-Manifest mit Quell-IDs, zugehörigen Modul- oder externen Systemdatensätzen, Medien und den erwarteten Quellbeziehungen. Das Manifest ist bereit, wenn die ausgewählten Nachweise vollständig, nachvollziehbar und einem Reviewer zugewiesen sind.
Nehmen Sie auf:
- einfache Products und Products aus mehreren Product Classes;
- Products mit beschreibenden Attributen, kundenseitig eingegebenen Werten und aktiven Variations;
- einen Legacy-Variant- oder migrierten Variation-Fall, falls der Shop den entsprechenden Modulwechsel durchlaufen hat;
- Membership-beschränkte oder Vendor-eigene Products, sofern verwendet;
- Customers mit Memberships, mehreren Adressen, externen IDs oder Vendor-Rollen;
- Gast- und registrierte Orders mit Variations, ungewöhnlichen Summen, Refunds, Shipments und moduleigenen Datensätzen;
- wichtige Category-, Inhalts-, Medien- und Route-Beispiele;
- einen aktiven Custom-Module-Datensatz und eine externe Systembeziehung.
Abschließendes X-Cart-Bereitschaftsprüfung anwenden
| Bereitschafts-Frage | Erforderliches Ergebnis |
|---|---|
| Ist die Quellherkunft bekannt? | Version, Editionskontext, Upgrade-Historie, Modulgeneration und Umgebung sind dokumentiert. |
| Ist die Katalogbedeutung vollständig? | Product Classes, Attribute, Variations, Categories, Memberships, Vendors und Medien sind abgebildet. |
| Sind Konten und Orders interpretierbar? | Rollen, Memberships, Adressen, Order-Snapshots, Status und externe Referenzen haben Verantwortlicher. |
| Sind Module und individuelle Daten klassifiziert? | Aktive und historische moduleigene Datensätze besitzen eine geplante Behandlung. |
| Sind Inhalte und Routes inventarisiert? | Öffentliche Pfade, Modul-Routes, Medien und Präsentationsbestandteile sind dokumentiert. |
| Ist das Quellpaket wiederherstellbar? | Datenbank und Dateien entsprechen demselben Shopzustand. |
| Ist das Sample-Manifest repräsentativ? | Core-, komplexe, Legacy-, moduleigene und externe Systemfälle sind enthalten. |
Kritische Unbekannte sollten als offene Entscheidungen mit Verantwortlicher bestehen bleiben. Schließen Sie die Vorbereitung nicht ab, solange Variation-Modell, Modul-Verantwortlicher, Vendor-Beziehung oder externer Identifikator unklassifiziert sind.
Fazit
Die Vorbereitung auf X-Cart hängt von der Herkunft des Quellsystems ab. Version, Modulgeneration, Product Classes, Attribute, Variations, Memberships, Vendors, Order-Erweiterungen, individuelle Module und externe Systeme bestimmen, welche Datensätze existieren und wie sie zusammenhängen.
Ein wiederherstellbares Quellpaket und ein Manifest mit repräsentativen Nachweisen ermöglichen es, die Migrationskonfiguration am tatsächlichen Shop auszurichten.
Häufige Fragen
Warum müssen X-Cart-Version und Modulgeneration dokumentiert werden?
X-Cart-Strukturen und Modulimplementierungen haben sich über Generationen verändert. Dasselbe Shop-Konzept kann über unterschiedliche Module, Entitäten oder APIs gespeichert werden. Deshalb bestimmen die aktive Version und der tatsächliche Modulsatz, welche Nachweise maßgeblich sind.
Sind X-Cart-Attribute und Product Variations dasselbe?
Nein. Attribute können Products beschreiben, kundenseitig eingegebene Werte erfassen oder an verkaufbaren Variations beteiligt sein. Nur Beziehungen, die eine separate SKU-, Bestands-, Preis-, Gewichts- oder Bildbedeutung definieren, sollten als Variation-Identität behandelt werden.
Was sollte für X-Cart Memberships vorbereitet werden?
Dokumentieren Sie Membership-Definitionen, Customer-Zuweisungen, Product- oder Category-Einschränkungen, Preiseffekte, Kontoregeln und repräsentative Orders. Eine Membership-Bezeichnung allein erhält ihre kommerzielle oder Zugriffs-Bedeutung nicht.
Sollten inaktive X-Cart-Module ignoriert werden?
Nicht automatisch. Ein inaktives Modul kann weiterhin historische Order-Datensätze, Customer-Felder oder externe Identifikatoren besitzen. Prüfen Sie, ob diese Daten noch benötigt werden, bevor das Modul als obsolet eingestuft wird.
Was gehört in das X-Cart-Sample-Manifest?
Nehmen Sie einfache und class-basierte Products, Attribute und Variations, Memberships oder Vendors sofern verwendet, komplexe Orders, wichtige Routes, moduleigene Datensätze und externe Systembeziehungen auf. Verwenden Sie exakte Quell-IDs und zugehörige Nachweise.
Warum werden sowohl Datenbank- als auch Dateibackups benötigt?
Die Datenbank enthält Core- und Moduldaten, während Dateien Module, Themes, Medien, Download-Assets, Konfiguration und individuellen Code enthalten können. Ein vollständiges Quellpaket benötigt beides aus demselben Shopzustand.