Bei der Bewertung von X-Cart als mögliche Zielplattform zeigt die Fehleranalyse, welche wiederkehrenden Migrationsfehler bei diesem Ziel auftreten können und wie sie vermieden werden.
Wenn X-Cart als mögliche Zielplattform bewertet wird, betrifft die Migration häufig ein Shop-Modell, das durch Product-Klassen, Varianten, Memberships, APIs, Marketplace-Beziehungen, spezialisierte Search-Funktionen oder branchenspezifische Erweiterungen ergänzt wurde. Standardmäßige Datensatzmengen können nicht beweisen, dass diese Beziehungen weiterhin nutzbar sind. Die folgenden Fehlerbilder konzentrieren sich deshalb auf Situationen, in denen ein grundsätzlich korrekt migriertes Product, ein Customer oder eine Order von dem Attribut-, Vendor-, Erweiterungs-, Asset-, Kennungs- oder Suchkontext getrennt wird, der dem Datensatz seine operative Bedeutung gibt.
Fehler 1: Product-Attribute, Klassen und Varianten verwechseln
Was schiefläuft
X-Cart kann Product-spezifische Attribute, Attribute auf Klassenebene, auswählbare Werte und Beziehungen unterscheiden, aus denen Varianten entstehen. Werden diese Strukturen zusammengeführt, können doppelte Products entstehen, Attribute der falschen Product-Familie zugeordnet oder beschreibende Werte erhalten werden, während die verkaufbare Variante verloren geht, die SKU, Preis, Gewicht oder Bestand besitzt.
Frühe Warnsignale
Derselbe Attributname verhält sich bei verschiedenen Products unterschiedlich, Klassenzuordnungen fehlen oder Variantenkombinationen existieren ohne stabile Kennungen.
| Struktur | Geschäftliche Rolle | Fehler bei Zusammenführung |
|---|---|---|
| Product-Klassenattribut | Gemeinsames Schema für eine Product-Familie | Inkonsistente Attribute und Filter |
| Product-spezifisches Attribut | Wert, der nur für ein Product gilt | Unbeabsichtigte globale Übernahme |
| Variantenbasis/-wert | Definiert eine verkaufbare Kombination | Eigentümerschaft von SKU, Preis oder Bestand geht verloren |
Vorbeugung
Klassifizieren Sie Attribute nach Geltungsbereich und Funktion. Erhalten Sie Product-Klassenbeziehungen, wenn sie ein gemeinsames Schema tragen. Trennen Sie variantenerzeugende Werte von rein beschreibenden Feldern. Ordnen Sie SKU, Preis, Gewicht, Bild und Bestand der verkaufbaren Variantenebene zu, wenn die Quelle auf dieser Ebene arbeitet.
Empfehlungsbeispiel
Bei Bekleidung kann Material als beschreibendes Klassenattribut für die gesamte Product-Familie erhalten bleiben, während Größe und Farbe Varianten mit eigener SKU und eigenem Bestand bilden. Erzeugen Sie nicht aus jedem beschreibenden Wert eine Variante.
Pass-Bedingung
Products übernehmen das vorgesehene Klassenschema, Product-spezifische Werte bleiben lokal, Variantenkombinationen sind vollständig und jede verkaufbare Auswahl führt zur richtigen SKU, zum richtigen Preis und zur richtigen Verfügbarkeit.
Fehler 2: Membership- und Customer-spezifischen kommerziellen Kontext verlieren
Was schiefläuft
X-Cart-Memberships und Profilbeziehungen können Preise, Zugriff, Steuern, Zahlung, Versand oder Katalogsichtbarkeit beeinflussen. Werden Customer-Konten und Membership-Bezeichnungen ohne die damit verbundene Funktion kopiert, entstehen Profile, die zwar klassifiziert wirken, aber nur Standardbehandlung erhalten.
Frühe Warnsignale
Membership-Werte sind vorhanden, aber Sonderpreise oder Zugriffsregeln fehlen, oder mehrere Profile wurden ausschließlich anhand der E-Mail-Adresse zusammengeführt.
| Beziehung | Möglicher Verlust | Auswirkung auf Customers |
|---|---|---|
| Membership-Zuordnung | Kommerzielle Regeln greifen nicht mehr | Falscher Preis oder Zugriff |
| Profil-/Adressstruktur | Rechnungs- und Versandkontext wird zusammengeführt | Mehrdeutigkeit bei Orders und Steuern |
| Custom-Profilfeld | Integrations- oder Freigabewert geht verloren | Operativer Prozess scheitert |
Vorbeugung
Mappen Sie Customer-Identität, Profile, Adressen, Memberships und Custom Fields getrennt. Dokumentieren Sie die Wirkung, die jede Membership steuert. Führen Sie Duplikate nur nach einer freigegebenen Identitätsregel zusammen. Erhalten Sie externe Customer-IDs, wenn verbundene Systeme sie verwenden, statt E-Mail grundsätzlich als ausreichend anzunehmen.
Empfehlungsbeispiel
Bei einer Handels-Membership müssen sowohl die Customer-Membership als auch die Zielverantwortung für Handelspreise und eingeschränkte Products erhalten bleiben. Bestätigen Sie, dass normale Retail-Customers diese Behandlung nicht übernehmen.
Pass-Bedingung
Repräsentative Customers behalten das richtige Profil, die richtigen Adressen, Memberships und den kommerziellen Kontext; beabsichtigte Unterschiede im Ziel werden dokumentiert und nicht hinter einer kopierten Membership-Bezeichnung verborgen.
Fehler 3: Annehmen, dass Erweiterungsdatensätze ohne die Erweiterung ihre Bedeutung behalten
Was schiefläuft
X-Cart-Erweiterungen können Product-Daten, Marketplace-Beziehungen, Zahlungs- oder Versandlogik, Fitment, Search, Profilfelder und Integrationsdatensätze hinzufügen. Werden ihre Tabellen ohne kompatible Erweiterung kopiert, entstehen verwaiste Daten. Wird dagegen ein aktives Erweiterungsfeld ausgelassen, kann ein kritischer Prozess ausfallen, obwohl Standarddatensätze korrekt migriert wurden.
Frühe Warnsignale
Eine Anforderung wird nur über den Namen einer Erweiterung beschrieben, Custom-Datensätze haben keinen Verbraucher im Ziel oder eine aktive Integration hängt von Feldern außerhalb der Standardobjekte ab.
| Ergebnis der Erweiterung | Entscheidung | Nachweis |
|---|---|---|
| Erzeugt persistente Daten | Auf fortgeführte Erweiterung oder Zielmodell mappen | Zielkomponente kann die Daten lesen |
| Verändert Checkout oder Auftragsabwicklung | Funktion separat neu konfigurieren | End-to-End-Transaktion funktioniert |
| Fügt Search-/Fitment-Daten hinzu | Strukturierte Beziehung erhalten | Repräsentative Abfrage liefert die richtigen Products |
Vorbeugung
Inventarisieren Sie Erweiterungen nach geschäftlicher Wirkung, erzeugten Daten und aktuellem Verbraucher. Erhalten Sie nur aktive oder für Nachweise relevante Datensätze. Trennen Sie Datenmigration von Installation, Lizenzierung, Konfiguration und individueller Implementierung einer Erweiterung. Nicht mehr benötigte Erweiterungsdaten sollten bewusst stillgelegt werden.
Empfehlungsbeispiel
Wenn eine Automotive-Fitment-Erweiterung Products mit Jahr/Marke/Modell-Datensätzen verbindet, erhalten Sie diese strukturierte Beziehung im fortgeführten Fitment-System, anstatt nur einen Anzeigetext in die Product-Beschreibung zu kopieren.
Pass-Bedingung
Jede geschäftskritische Wirkung einer Erweiterung besitzt einen eindeutigen Zielverantwortlichen, die benötigten Daten bleiben für diesen Verbraucher nutzbar und kein Shop- oder Betriebsverhalten wird allein deshalb als fortbestehend angenommen, weil eine Tabelle kopiert wurde.
Fehler 4: Marketplace- oder Vendor-Zuordnung zusammenführen
Was schiefläuft
Einige X-Cart-Installationen verwenden Marketplace- oder Vendor-Beziehungen, die Product-Eigentümerschaft, Provisionen, Orders, Auftragsabwicklung oder administrativen Zugriff beeinflussen. Werden Products und Orders ohne Vendor-Kontext kopiert, kann der falsche Verkäufer zugeordnet, private Information offengelegt oder Abrechnung und Supportverantwortung nicht mehr rekonstruiert werden.
Frühe Warnsignale
Products besitzen Vendor-IDs, Orders enthalten verkäuferspezifische Positionen oder operative Teams unterscheiden zwischen Marketplace-Betreiber, Verkäufer und verantwortlicher Partei für die Auftragsabwicklung.
| Marketplace-Objekt | Eigentumsfrage | Folge bei Verlust |
|---|---|---|
| Product | Welcher Vendor besitzt oder erfüllt es? | Katalog- und Bestandsverantwortung ist falsch |
| Order-Position | Welcher Verkäufer erhält die Transaktion? | Abrechnungs- und Supportkontext verschwindet |
| Vendor-Profil | Welche Benutzer und Berechtigungen gehören dazu? | Administrativer Zugriff wird unsicher |
Vorbeugung
Modellieren Sie Vendor-Identität, Product-Eigentümerschaft, Eigentümerschaft von Order-Positionen und externe Abrechnungsreferenzen ausdrücklich. Leiten Sie den Vendor nicht aus Product-Text oder E-Mail ab. Wenn die Zielplattform ein anderes Marketplace-Modell verwendet, definieren Sie die übersetzte Beziehung und erhalten Sie historische Nachweise, selbst wenn die Live-Abrechnungslogik neu aufgebaut wird.
Empfehlungsbeispiel
Eine gemischte Order enthält Products von zwei Vendors. Erhalten Sie für jede Position die Vendor-Beziehung und die ursprüngliche Order-Referenz, damit Betriebsteams Auftragsabwicklung und Abrechnungshistorie nachvollziehen können.
Pass-Bedingung
Products, Order-Positionen, Vendor-Konten und operative Referenzen lassen sich dem richtigen Verkäuferkontext zuordnen und kein Vendor erhält unbeabsichtigten Zugriff auf Datensätze eines anderen Verkäufers.
Fehler 5: Order-Köpfe erhalten, aber Positions- und Statusbedeutung verlieren
Was schiefläuft
X-Cart-Orders können Variantendetails, Memberships, Rabatte, Steuern, Versand, Zahlungskontext, Historien und von Erweiterungen erzeugte Daten enthalten. Eine Migration nur auf Kopfebene erzeugt eine auffindbare Order, die Returns, Abgleich oder Kundensupport nicht ausreichend unterstützt.
Frühe Warnsignale
Orders zeigen Gesamtsummen, aber ausgewählte Attribute, Finanzpositionen, Historienkommentare oder Verkäufer-/Auftragsabwicklungskontext fehlen.
| Order-Detail | Fehler | Folge |
|---|---|---|
| Varianten-/Attributwerte | Gekauftes Element ist nicht eindeutig | Return- und Ersatzentscheidungen scheitern |
| Finanzielle Bestandteile | Gesamtsumme lässt sich nicht erklären | Finance und Support verlieren Vertrauen in die Historie |
| Status-/Historienbedeutung | Prozess wird zusammengeführt | Mitarbeitende interpretieren Auftragsabwicklung oder Stornierung falsch |
Vorbeugung
Erhalten Sie Product- und Variantenidentität auf Positionsebene, finanzielle Bestandteile, Source-Referenzen und bedeutungsvolle Historie. Mappen Sie Status nach operativer Bedeutung und nicht nur nach Bezeichnung. Trennen Sie historische Nachweise von der aktiven Prozesskonfiguration im Ziel.
Empfehlungsbeispiel
Bei einer teilweise erstatteten Order mit Variante und Membership-Rabatt sollten gekaufte Attribute, Rabatt, Erstattungsbetrag, Statushistorie und ursprüngliche Referenz erhalten bleiben, statt nur eine Endsumme anzuzeigen.
Pass-Bedingung
Mitarbeitende können erkennen, was gekauft wurde, Summe und Anpassung erklären, den historischen Status verstehen und die Order mit den von Customers oder Integrationen verwendeten Referenzen finden.
Fehler 6: Übersetzungen und Shop-Kontext verlieren
Was schiefläuft
X-Cart-Datensätze und APIs können übersetzte Namen, Beschreibungen und andere lokalspezifische Werte bereitstellen. Wird eine Sprache als universeller Wert gewählt, können regionale Inhalte überschrieben werden. Werden dagegen alle Übersetzungen ohne Routen- und Shop-Kontext kopiert, können doppelte oder unvollständige Seiten entstehen.
Frühe Warnsignale
Products haben ungleichmäßige Übersetzungsabdeckung, Inhalte enthalten Links zur Source-Domain oder die Standardsprache ersetzt fehlende Locale-Werte unbemerkt.
| Lokalisierungsproblem | Sichtbarer Fehler | Kontrolle |
|---|---|---|
| Fehlende Übersetzung | Leerwert oder unbeabsichtigter Fallback | Freigegebene Fallback- oder Veröffentlichungsregel definieren |
| Übersetzter Slug/Inhalt stimmt nicht überein | Falsche Route oder Sprachseite | Locale-spezifisches Ziel mappen |
| Eingebettetes Medium/Link | Abhängigkeit von der Quellshop bleibt bestehen | Auf Ziel-Asset oder Zielroute umstellen |
Vorbeugung
Prüfen Sie die Übersetzungsvollständigkeit nach Datensatztyp und Locale. Erhalten Sie Locale-spezifische Werte getrennt. Normalisieren Sie Encoding und HTML. Definieren Sie Fallback-Verhalten bewusst. Mappen Sie Links, Medien und SEO-Felder im selben Locale- und Shop-Kontext.
Empfehlungsbeispiel
Ein Product hat englische und deutsche Namen, aber nur eine englische Langbeschreibung. Veröffentlichen Sie den freigegebenen deutschen Fallback oder lassen Sie die unvollständige Locale unveröffentlicht; zeigen Sie nicht stillschweigend englischen Inhalt unter einer deutschen Route.
Pass-Bedingung
Jede veröffentlichte Locale zeigt die vorgesehenen Inhalte, Routen und Medien lösen korrekt auf und fehlende Werte folgen einer erklärten Fallback- oder Veröffentlichungsregel.
Fehler 7: Beziehungen zwischen Medien, Dateien und Bildern beschädigen
Was schiefläuft
Product-Bilder, Galerien, Downloads und von Erweiterungen verwaltete Dateien können als Pfade oder verbundene Datensätze statt als eingebettete Werte gespeichert sein. Werden nur Dateinamen kopiert, ohne Assets zu übertragen oder Product-/Variantenbeziehungen zu erhalten, entstehen defekte Medien, doppelte Galerien oder Dateien am falschen verkaufbaren Element.
Frühe Warnsignale
Medienpfade verweisen auf Source-Verzeichnisse, Bilder werden von Varianten ohne definierten Eigentümer gemeinsam genutzt oder Dateien liegen außerhalb des normalen Exports.
| Asset | Zu erhaltende Beziehung | Fehler |
|---|---|---|
| Haupt- und Galeriebild | Product und Anzeigereihenfolge | Falsches Hauptbild oder Duplikate |
| Variantenbild | Verkaufbare Variante | Customer sieht die falsche Auswahl |
| Download/Datei | Product oder Berechtigungsregel | Asset fehlt oder ist zu weit zugänglich |
Vorbeugung
Erstellen Sie ein Asset-Manifest mit Source-Speicherort, Datensatzeigentümer, Zielpfad, nach Möglichkeit Prüfsumme sowie öffentlichem/privatem Status. Überführen Sie Assets in zielseitig verwalteten Speicher. Erhalten Sie Galeriereihenfolge und Variantenzuordnung. Entfernen Sie veraltete oder doppelte Dateien bewusst.
Empfehlungsbeispiel
Ein Product nutzt eine gemeinsame Galerie plus farbspezifische Variantenbilder. Belassen Sie die gemeinsamen Bilder am Parent Product und ordnen Sie jedes Farbbild der richtigen Variante zu, statt alle Bilder auf jede Variante zu kopieren.
Pass-Bedingung
Priorisierte Products zeigen vollständige, korrekt sortierte Medien, Varianten zeigen die richtigen Assets, private Dateien bleiben geschützt und kein kundenbezogenes Asset hängt von der stillgelegten Source-Umgebung ab.
Fehler 8: Externe Kennungen verwerfen, die Integrationen benötigen
Was schiefläuft
X-Cart-Installationen können ERP-, Lieferanten-, Marketplace-, Automotive- oder Lagerkennungen an Products, Varianten, Customers, Orders oder Erweiterungsdatensätzen speichern. Werden sichtbare Daten ohne diese Schlüssel kopiert, brechen Updates und Abgleiche. Wird eine Variantenkennung am Parent Product gespeichert, können mehrere verkaufbare Datensätze miteinander kollidieren.
Frühe Warnsignale
Integrationsverantwortliche fragen Felder ab, die im Standard-Admin nicht sichtbar sind, oder Datensätze werden anhand anderer IDs als SKU, E-Mail und zielseitig erzeugter ID abgeglichen.
| Kennung | Eigentümer | Zielanforderung |
|---|---|---|
| Varianten-/Fitment-Schlüssel | Verkaufbare oder Kompatibilitätsbeziehung | Auf der exakten Datensatzebene erhalten |
| Customer-/ERP-Schlüssel | Customer-Profil | Eindeutiges, durchsuchbares Integrationsfeld |
| Marketplace-Referenz einer Order | Historische Order oder Verkäuferposition | Für Abgleich erhalten |
Vorbeugung
Definieren Sie einen Kennungsvertrag mit Quellfeld, Zielverantwortlichem, Eindeutigkeit, Format und konsumierendem Prozess. Erhalten Sie nur aktive oder für Nachweise relevante Schlüssel. Testen Sie Suche und Aktualisierung über die fortgeführte API oder Integration.
Empfehlungsbeispiel
Ein Lager nutzt einen variantenspezifischen Schlüssel, um Mengen zu aktualisieren. Erhalten Sie diesen Schlüssel an der Zielvariante oder Bestandsbeziehung und nicht nur am Parent Product.
Pass-Bedingung
Jeder benötigte externe Schlüssel ist dort eindeutig, wo Eindeutigkeit erwartet wird, dem richtigen Datensatz zugeordnet, auffindbar und nachweislich für seinen fortgeführten Verbraucher nutzbar.
Fehler 9: API-Exporte als vollständiges Shop-Modell behandeln
Was schiefläuft
Verfügbarkeit und Schemas der X-Cart-APIs können je nach Plattformversion und installierten Erweiterungen variieren. Ein Standardendpoint kann Products, Customers und Orders bereitstellen, aber von Erweiterungen verwaltete Daten, private Felder oder Beziehungen auslassen, die nur über einen anderen Endpoint oder die Datenbankstruktur verfügbar sind. Eine einzelne API-Antwort als vollständiges Source-Modell zu behandeln, erzeugt stille Lücken.
Frühe Warnsignale
Exportmengen weichen von Admin-Zahlen ab, Pagination ist unvollständig, Erweiterungsfelder erscheinen nie oder das API-Schema unterscheidet sich zwischen Umgebungen.
| API-Signal | Risiko | Kontrolle |
|---|---|---|
| Pagination/Standardlimits | Nur erste Datensätze werden abgerufen | Summen und Seitenabdeckung abgleichen |
| Versionsspezifisches Schema | Felder oder Endpoints unterscheiden sich | Source-Version und Vertrag dokumentieren |
| Von Erweiterung verwaltetes Objekt | Standardendpoint lässt Beziehung aus | Unterstützten Erweiterungsendpoint oder dokumentierte Extraktion verwenden |
Vorbeugung
Dokumentieren Sie Source-API-Version, Authentifizierung, Pagination, Objektabdeckung und Erweiterungsabhängigkeiten. Gleichen Sie API-Summen mit Admin- oder Datenbanknachweisen ab. Bewahren Sie Roh-Exporte für Reproduzierbarkeit auf. Leiten Sie aus fehlenden Werten nicht ab, dass sie ungenutzt sind, bevor der verantwortliche Prozess geprüft wurde.
Empfehlungsbeispiel
Ein Standard-Product-Endpoint liefert Basis-Products, aber keine Automotive-Fitment-Beziehungen. Extrahieren Sie das Fitment-Objekt über seine unterstützte Quelle, statt anzunehmen, dass der Product-Export vollständig ist.
Pass-Bedingung
Für alle im Umfang enthaltenen Objektfamilien und Beziehungen existiert ein verifizierter Extraktionspfad, Pagination ist vollständig, Mengen sind abgeglichen und bekannte API-Auslassungen besitzen eine ausdrücklich definierte alternative Behandlung.
Fehler 10: URLs erhalten, aber Search- und Fitment-Absicht verlieren
Was schiefläuft
X-Cart-Shops können von Product- und Category-URLs, Search-Konfiguration, CloudSearch oder Erweiterungsindizes sowie spezialisierten Fitment-Beziehungen abhängen. Nur Slugs und Products zu migrieren kann Routen erhalten und gleichzeitig die Suchlogik schwächen, die Käufer zum richtigen Product führt.
Frühe Warnsignale
Priorisierte Suchanfragen liefern zu breite oder leere Ergebnisse, Fitment-Werte erscheinen nur in Beschreibungen oder mehrere historische Routen führen zu doppelten Product-Zielen.
| Discovery-Ebene | Fehler | Vorbeugung |
|---|---|---|
| Öffentliche URL | Historische Route löst nicht mehr auf | Kanonisches Ziel mappen und Redirect einrichten |
| Search-Index/-Konfiguration | Products existieren, sind aber nicht auffindbar | Index und Feldverantwortung neu aufbauen |
| Fitment/Kompatibilität | Strukturierte Beziehung wird zu Text | Abfragbare Kompatibilitätsdaten erhalten |
Vorbeugung
Trennen Sie Routenidentität, durchsuchbare Felder und strukturierte Kompatibilitätsbeziehungen. Erstellen Sie ein Register priorisierter URLs. Definieren Sie, welche Felder die Zielsuchfunktion speisen. Erhalten Sie Fitment als abfragbare Daten, wenn es Kaufentscheidungen steuert, statt es in Fließtext zu reduzieren.
Empfehlungsbeispiel
Bei einem Automotive-Product sollte die Jahr/Marke/Modell-Kompatibilität beim zuständigen Fitment-Modell im Ziel erhalten bleiben, das Product über die relevante Search auffindbar sein und die historische Product-Route auf das kanonische Ziel weiterleiten.
Pass-Bedingung
Priorisierte Routen lösen korrekt auf, repräsentative Suchanfragen liefern die vorgesehenen Products und Käufer mit Kompatibilitätsanforderungen können ein gültiges Product über strukturierte Zielfunktionen identifizieren.
Übergreifende Prioritäten zur Fehlervermeidung
Die wiederkehrenden X-Cart-Risiken lassen sich über drei verbundene Prüfpfade kontrollieren.
| Präventionspriorität | Was sie schützt | Nachweis vor Freigabe |
|---|---|---|
| Kommerzielle Beziehungen erhalten | Attribute, Varianten, Memberships, Customer-spezifische Behandlung, Vendors und Marketplace-Eigentümerschaft | Repräsentative Products und Customers behalten Auswahl, Sichtbarkeit, Preise und Eigentümerschaftskontext. |
| Bedeutung von Erweiterungen und externen Systemen erhalten | Erweiterungsdatensätze, Custom Fields, APIs und Integrationskennungen | Jeder Nicht-Core-Wert hat einen bestätigten Eigentümer, eine Zielabbildung und einen Verbraucher. |
| Historische und Shop-Kontinuität validieren | Orders, Übersetzungen, Medien, Dateien, URLs, Search und Fitment-Absicht | Mitarbeitende können Historie interpretieren, Shop-Inhalte lösen im richtigen Kontext auf und hochwertige Routen bleiben nutzbar. |
Fazit
Eine belastbare X-Cart-Migration erhält die Beziehungen, durch die der Katalog auffindbar, kaufbar, supportfähig und integrierbar bleibt. Product-Klassen und Varianten bleiben getrennt, Memberships und Vendor-Kontext behalten ihre Bedeutung, Orders bewahren erklärende Details und Abhängigkeiten von Erweiterungen, APIs, Medien und externen IDs werden klaren, wartbaren Zielverantwortlichen zugewiesen.
Häufige Fragen
Warum sollten X-Cart-Product-Klassen und Varianten getrennt geprüft werden?
Product-Klassen können ein gemeinsames Attributschema definieren, während Varianten verkaufbare Kombinationen darstellen. Eine Vermischung kann falsche Attribute, SKUs, Preise oder Bestandszuordnungen erzeugen.
Wie sollten Customer-Memberships erhalten werden?
Migrieren Sie die Beziehung zwischen Customer und Membership und definieren Sie separat die Zielverantwortung für Preise, Sichtbarkeit, Steuern oder Zugriffe, durch die die Membership geschäftliche Bedeutung erhält.
Werden X-Cart-Erweiterungen zusammen mit Standarddaten migriert?
Nein. Von Erweiterungen erzeugte Datensätze und Funktionen benötigen einen kompatiblen oder ersetzenden Zielverantwortlichen. Das Kopieren einer Tabelle allein erhält keine Funktionalität.
Was sollte mit Vendor-Beziehungen geschehen?
Erhalten Sie Vendor-Identität, Product-Eigentümerschaft, Eigentümerschaft von Order-Positionen und relevante operative Referenzen, damit Marketplace-Historie und Verantwortlichkeiten nachvollziehbar bleiben.
Kann die X-Cart-API als vollständiges Source-Modell behandelt werden?
Nicht automatisch. Die Abdeckung kann je nach Version und Erweiterung variieren. Gleichen Sie Endpoint-Ergebnisse mit Admin- oder Datenbanknachweisen ab und dokumentieren Sie alternative Extraktionspfade für ausgelassene Beziehungen.
Wie sollten Fitment- oder spezialisierte Search-Daten migriert werden?
Erhalten Sie sie als strukturierte, abfragbare Kompatibilitätsdaten im fortgeführten Search- oder Fitment-Verantwortungsbereich, statt sie in Product-Beschreibungen zu reduzieren.