Bei der Bewertung von X-Cart als mögliche Zielplattform bestimmt der Migrationsansatz, welcher Next-Cart Migrationsservice und welche unterstützten Maßnahmen für den Weg in dieses Ziel passen.
Der richtige Migrationsansatz für X-Cart hängt davon ab, welcher Anteil des Shops aus gewöhnlichen Commerce-Daten besteht und welcher Anteil von Konfiguration, Erweiterungen, Custom Fields, Product Variations, User Memberships, externen Identifikatoren oder zielseitiger Einrichtung abhängt. Eine einfache Schätzung anhand der Datensatzanzahl reicht nicht aus. Die Planung muss berücksichtigen, wie sich die Daten verhalten, nachdem sie die Zielplattform erreicht haben.
Standard Service, Managed Service, Add-ons und Custom Service sind keine austauschbaren Optionen. Sie lösen unterschiedliche Migrationsprobleme. Standard Service kann für unterstützte Datensätze funktionieren, die einem sauberen Datenpfad entsprechen. Managed Service verändert Ausführungsverantwortung und Koordination. Add-ons unterstützen klar abgegrenzte Filterung von Datensätzen, Transformation von Feldwerten oder Feldzuordnung innerhalb des unterstützten Verhaltens. Custom Service ist der richtige Prüfpfad, wenn nicht standardisierte Behandlung, individuelle Logik, nicht unterstützte Erweiterungsdaten, individuelle Transformationen oder die Erhaltung externer Systembeziehungen erforderlich sind.
Innerhalb der Next-Cart Migrationsservices sollte die X-Cart-Analyse klar zwischen unterstützten Datensätzen, Ausführungsverantwortung, abgegrenzten Add-ons, erweiterungseigenen Daten, Custom Fields und Zielkonfiguration unterscheiden.
Mit der Migrationslast beginnen, nicht mit der Shopgröße
Eine große X-Cart-Migration kann vergleichsweise geradlinig sein, wenn die Quelldaten sauber und die Zielstruktur vorbereitet sind. Eine kleinere Migration kann dagegen komplex sein, wenn Products von individueller Logik abhängen, Memberships Pricing oder Zugriff steuern, Quellerweiterungen wichtige Felder erzeugen oder historische Order-Daten für Accounting und Customer Support weiterhin nutzbar bleiben müssen.
Die Migrationslast sollte nach Struktur und nicht nur nach Volumen beurteilt werden. Product Variations, Classes und Attribute, Bildergalerien, Bestandsfelder, Benutzerrollen, Memberships, Order-Status, SEO-URLs, Erweiterungen und externe Identifikatoren beeinflussen den Ansatz. Diese Faktoren bestimmen, ob die Arbeit als Standardtransfer, Managed-Execution-Projekt, unterstützter Add-on-Anwendungsfall oder Custom-Service-Anforderung behandelt werden sollte.
| X-Cart-Migrationssignal | Was es anzeigt | Konsequenz für den Ansatz |
|---|---|---|
| Gewöhnliche Products, Categories, Customers und Orders | Core-Datensätze entsprechen üblichen Migrationserwartungen. | Standard Service kann geeignet sein, wenn Demo Migration die Qualität bestätigt. |
| Komplexer Katalog mit Variations, Attributen, Bildern und Bestandsunterschieden | Daten können weiterhin unterstützt sein, aber der Prüfaufwand ist höher. | Managed Service oder Add-ons können je nach Umfang und Zuordnungsbedarf sinnvoll sein. |
| Memberships, Profilfelder, Rollen oder segmentiertes kommerzielles Verhalten | Customer-Daten können Geschäftsregeln über reine Identität hinaus tragen. | Umfangsprüfung ist erforderlich; bei nicht unterstützten Strukturen kann Custom Service nötig sein. |
| Durch Erweiterungen erzeugte Product-, Customer-, Order- oder Shop-Oberfläche-Daten | Wichtige Funktionen sind möglicherweise keine nativen Zieldaten. | Häufig ist eine Custom-Service-Prüfung nötig; Advanced Data Mapping gilt nur, wenn ein unterstütztes Quellfeld einem kompatiblen Zielfeld zugeordnet werden soll. |
| Externe IDs aus ERP, PIM, WMS, Marketplace, Accounting oder Auftragsabwicklung | Datensätze müssen mit externen Betriebsabläufen verbunden bleiben. | Mapping oder Custom Service kann erforderlich sein, um Identifikatoren sinnvoll zu erhalten. |
| Datenänderungen nach Demo Migration erwartet | Das erste Migrationsergebnis ist möglicherweise nicht der endgültige Datensatz. | Optionen für spätere Migrationen und Revalidierungsplanung können erforderlich werden. |
Die sicherste Serviceentscheidung entspricht der tatsächlichen Migrationslast. Wer die leichteste Option wählt, kann eine Migration erhalten, die nach Anzahl vollständig wirkt, aber bei Product-Auswahl, Customer-Segmentierung, Erweiterungsfeldern oder Order-Historie scheitert.
Wann Standard Service ausreichen kann
Standard Service kann geeignet sein, wenn die Migration unterstützte Source- und Zielplattform-Strukturen verwendet und die erwarteten Datensätze in den Standard-Service-Umfang passen. Für X-Cart bedeutet das in der Regel, dass der Shop hauptsächlich unterstützte Products, Categories, Customers, Orders, Coupons, Reviews, CMS Pages, Blog Posts und andere gewöhnliche Datensätze nutzt, ohne individuelle Interpretation zu erfordern.
Standard Service funktioniert am besten, wenn der Händler die Zielumgebung vorbereiten, erforderliche Einrichtungsschritte durchführen, Demo Migration prüfen, Zuordnungserwartungen bestätigen und das Migrationsergebnis validieren kann. Der Service verspricht nicht, dass jedes Verhalten der Quelle zu nativem X-Cart-Verhalten wird. Er ist ein Servicepfad für unterstützten Migrationsumfang.
Ein starker Standard-Service-Kandidat verfügt normalerweise über:
- eindeutig unterstützte Source- und Zielplattformen;
- gewöhnliche Product-Datensätze ohne individuelle Configurator-Logik;
- Product-Auswahl, die sich über unterstützte Strukturen prüfen lässt;
- Categories ohne ungewöhnliche Zugriffs- oder Navigationsregeln;
- Customer- und Order-Datensätze ohne komplexe Rollen-, Vendor- oder Membership-Transformation;
- keine nicht unterstützten Erweiterungs- oder Custom-Module-Daten, die im Migrationsergebnis benötigt werden;
- getrennte zielseitige Einrichtung von Checkout, Zahlung, Versand, Steuern, Theme und Erweiterungen;
- genügend interne Kapazität, Demo Migration zu prüfen und Full Migration freizugeben.
Standard Service sollte dennoch über Demo Migration getestet werden. Die Katalog- und Benutzerstrukturen von X-Cart können dazu führen, dass scheinbar einfache Daten versteckte Variation-, Attribute-, Membership- oder Erweiterungsabhängigkeiten enthalten. Zeigt Demo Migration fehlende Felder, unklare Product-Auswahl oder Lücken in der Customer-Segmentierung, sollte der Ansatz vor Full Migration erneut bewertet werden.
Wann Managed Service die sicherere Ausführungswahl ist
Managed Service ist sinnvoll, wenn die Migration weiterhin innerhalb der Standardfunktionalität liegt, der Händler aber servicegeführte Ausführung und strukturiertere Koordination wünscht. Er verwandelt eine Standardmigration nicht in eine individuelle Migration. Sein Wert liegt in Ausführungsverantwortung, Guidance, Sequencing und einem stärker betreuten Weg durch Demo Migration und Full Migration.
Für X-Cart wird Managed Service attraktiv, wenn der Shop einen relevanten Katalog, viele zu prüfende Product-Beispiele, komplexe Customer- und Order-Historie, SEO-sensitive URLs oder interne Teams mit wenig Zeit für die operative Durchführung besitzt. Er kann außerdem helfen, Product Variations, Attribute, Bilder, Categories, Memberships und Order-Historie vor dem Produktivstart geordneter zu prüfen.
| Managed-Service-Signal | Warum es relevant ist | Wobei Managed Service hilft |
|---|---|---|
| Das Projekt ist standardisiert, aber operativ aufwendig | Der Händler benötigt eher Koordination als individuelle Funktionalität. | Durchführung, Zeitsteuerung und Review-Guidance. |
| Demo Migration erfordert sorgfältige Interpretation | Sample-Ergebnisse müssen geschäftlich über Katalog, Customers und Orders hinweg bewertet werden. | Strukturierteres Feedback und klarere Entscheidungspunkte vor Full Migration. |
| Der Katalog enthält viele Variations oder Attribute | Daten können unterstützt sein, aber ohne Plan schwer prüfbar werden. | Bessere Reihenfolge für Sample-Review und Validierungsprioritäten. |
| SEO und historische Orders sind wichtig | Bereitschaft zum Produktivstart hängt von mehr als Product-Anzahl ab. | Koordinierte Prüfung von URLs, Order-Lesbarkeit und hochwertigen Datensätzen. |
| Interne Ressourcen sind begrenzt | Shopteams haben möglicherweise nicht genug Zeit für die operative Migration. | Servicegeführte Ausführung innerhalb der vereinbarten Servicefunktionalität. |
Managed Service sollte nicht gewählt werden, um die Umfangsanalyse zu umgehen. Wenn der Shop Custom Fields benötigt, deren erforderliche Behandlung den unterstützten Mapping-Umfang überschreitet, individuelle Transformationen verlangt, Quellcode interpretiert werden muss oder nicht unterstützte Erweiterungsdaten migriert werden sollen, handelt es sich nicht nur um Ausführungsverantwortung. Dann gehört die Anforderung in eine Custom-Service-Prüfung.
Wo Add-ons eine unterstützte Migration verbessern können
Add-ons helfen, wenn der Migrationspfad grundsätzlich unterstützt wird, der Händler aber mehr Kontrolle über Datensatzfilterung mit feldbasierten Bedingungen je Datenkategorie, expression-basierte Feldwerttransformation oder Remapping von Quellfeldern benötigt. Sie sind kein Ersatz für Custom Service und dürfen nicht den Eindruck erwecken, dass nicht unterstützte Erweiterungsdaten, individueller Code oder individuelle Geschäftslogik automatisch migriert werden.
Bei X-Cart sind Add-ons sinnvoll, wenn der Händler den Umfang anhand unterstützter Feldbedingungen begrenzen, unterstützte Werte über Expressions transformieren oder unterstützte Felder anderen Zielpositionen zuordnen muss. Sie können eine Standardmigration präziser machen, wenn die Quelldaten unnötige Historie, inkonsistente Feldwerte oder bestimmte Anforderungen an die Feldplatzierung enthalten.
| Add-on-Kategorie | X-Cart-Anwendungsfall | Einzuhaltende Grenze |
|---|---|---|
| Data Filter | Unterstützte Feldbedingungen für Product, Customer, Order, CMS Page oder Blog Post anwenden, sodass nur passende Datensätze migriert werden. | Filterung steuert, welche Datensätze übertragen werden; sie gestaltet Product-Logik oder Membership-Verhalten nicht neu. |
| Data Transformation | Expressions verwenden, um unterstützte Labels, Status oder andere Feldwerte während der Migration zu transformieren. | Expressions bauen keine Regeln individueller Module oder Erweiterungsfunktionen nach. |
| Advanced Data Mapping | Unterstützte Quellfelder auf kompatible X-Cart-Zielfelder abbilden, wenn die Feldbedeutung klar ist. | Mapping bleibt innerhalb unterstützten Feldverhaltens; nicht unterstützte Strukturen benötigen Review. |
| Bedarf an Tailored Add-on oder Custom Add-on | Ein Standard Add-on muss verändert werden oder individuelle Add-on-Funktionalität ist erforderlich. | Wird über Custom Service geprüft und angeboten, nicht als Standard-Add-on-Umfang behandelt. |
Entscheidend ist, ob die Anforderung innerhalb des unterstützten Migrationsverhaltens bleibt. Wenn ja, kann ein Add-on helfen. Erfordert sie neue Logik, nicht unterstützte Datensätze, Transformation jenseits verfügbarer Expressions oder quellenspezifische Interpretation, sollte die Anforderung nicht künstlich in ein Add-on-Modell gepresst werden.
Wann Custom Service geprüft werden sollte
Custom Service sollte geprüft werden, wenn eine X-Cart-Migration nicht standardisierte Behandlung benötigt. Dazu gehören individuelle Quellstrukturen, nicht unterstützte Erweiterungsdaten, individuelle Transformationen, externe Systemidentifikatoren, individuelle Product-Logik, Quellcodeänderungen, modifizierte Datenbankfelder, ungewöhnliche Memberships, individuelle Benutzerrollen oder Anpassungen der Migrationslogik über Standardverhalten hinaus.
X-Carts Flexibilität macht diese Trennung besonders wichtig. Ein Shop kann in der Shop-Oberfläche wie ein normaler Katalog wirken und im Hintergrund von Custom Fields, Erweiterungen oder Integrationen abhängen. Wenn diese verborgene Struktur nach der Migration relevant bleibt, muss sie vor Full Migration identifiziert werden.
Starke Signale für Custom Service sind:
- eine individuelle Plattform als Quelle;
- ein stark modifizierter Quellshop;
- Custom Fields auf Products, Customers, Benutzern, Orders, Categories oder Checkout-Datensätzen, wenn die erforderliche Behandlung den unterstützten Mapping-Umfang überschreitet oder auf individuellem Quellverhalten beruht;
- individuelle Product Builder, Configurators, Fitment-Daten, Bundles oder Rechner;
- nicht unterstützte Erweiterungs- oder Moduldaten, die bedeutungsvoll erhalten bleiben müssen;
- externe Identifikatoren aus ERP, PIM, WMS, CRM, Accounting, Marketplace, Versand oder Auftragsabwicklung;
- Quellcodeänderungen, die Katalog, Checkout, Customer- oder Order-Verhalten beeinflussen;
- ungewöhnliche Customer Memberships, Rollen, Berechtigungen oder B2B-ähnliche Regeln;
- individuelle Order-Prozesse, Retourendatensätze, Subscription-Datensätze, Reward-Logik oder Loyalty-Daten;
- zielseitige Anforderungen, die eine individuelle Anpassung der Migrationslogik benötigen.
Custom Service sollte sorgfältig abgegrenzt werden. Manche Anforderungen betreffen Datenmigration, andere Zielkonfiguration und wieder andere Entwicklungs- oder Integrationsarbeit außerhalb der Migration. Eine klare Prüfung verhindert, dass Custom Service als pauschales Versprechen verstanden wird, das gesamte Betriebsmodell des Quellshops nachzubauen.
Wie Entity Points die X-Cart-Umfangsplanung beeinflussen
Entity Points sollten berücksichtigt werden, wenn berechtigte Products, Customers, Orders oder Blog Posts erstmals migriert werden. Bei X-Cart ist das besonders relevant für große Product-Kataloge, tiefe Customer-Historien, umfangreiche Order-Historie oder Blog Posts im vereinbarten Umfang.
Entity Points sind weder Qualitäts- noch Eignungsscore und allein keine Serviceempfehlung. Ein Shop mit wenigen Datensätzen kann dennoch Custom Service benötigen, wenn diese Datensätze von Custom Fields abhängen, deren notwendige Behandlung den unterstützten Mapping-Umfang oder Add-on-Verhalten überschreitet. Ein Shop mit mehr Datensätzen kann weiterhin einem unterstützten Pfad entsprechen, wenn Daten sauber und Zielstruktur vorbereitet sind.
Auch die Regel zur doppelten Nutzung muss erhalten bleiben. Datensätze, die innerhalb der gekauften Migration auf dem festen Pfad bereits gezählt wurden, verbrauchen nicht erneut Entity Points, nur weil später weitere Migrationsaktivität stattfindet. Neue berechtigte Datensätze können Entity Points verbrauchen, wenn sie erstmals migriert werden. Diese Unterscheidung ist wichtig bei Follow-up-Aktivitäten nach Demo Migration oder vor dem Produktivstart.
| Frage zur Entity-Points-Planung | Warum sie für X-Cart relevant ist |
|---|---|
| Welche Products, Customers, Orders oder Blog Posts sind im Umfang? | Diese berechtigten Datensätze können beim ersten Migrieren Entity Points verbrauchen. |
| Werden historische Orders benötigt oder nur aktuelle? | Die Tiefe der Order-Historie kann Datensatzvolumen und Validierungsaufwand verändern. |
| Werden nach Demo Migration neue Products oder Orders hinzugefügt? | Spätere Aktivität kann Follow-up-Planung und Revalidierung erfordern. |
| Sind wiederholte Datensätze auf demselben Migrationspfad bereits gezählt? | Sie sollten nicht allein wegen späterer Migrationsaktivität erneut gezählt werden. |
| Werden auch Custom Fields benötigt, deren Behandlung den unterstützten Mapping-Umfang überschreitet, oder Erweiterungsdatensätze? | Entity Points ersetzen keine Custom-Service-Prüfung für nicht unterstütztes oder individuelles Verhalten. |
Der beste Zweck von Entity Points in der X-Cart-Planung ist Umfangsklarheit. Sie rahmen das Volumen berechtigter Datensätze, entscheiden aber nicht, wie individuelle Daten, Erweiterungen, Memberships oder Integrationen behandelt werden müssen.
Optionen für spätere Migrationen planen
Optionen für spätere Migrationen sind sinnvoll, wenn X-Cart-Migrationsaktivität nach einem genehmigten Lauf fortgesetzt werden muss oder sich die Zielkonfiguration während der Vorbereitung des Produktivstarts ändert. Die Entscheidung sollte davon abhängen, was sich geändert hat: nur neue berechtigte Datensätze, die Migrationskonfiguration oder das erwartete Gesamtergebnis.
| Aktuelle Aktion | Verwenden, wenn | Fokus der X-Cart-Revalidierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Genehmigter Umfang und Konfiguration bleiben gültig und neue berechtigte Datensätze müssen übertragen werden. | Neue Products, Customers, Orders, Blog Posts, Variants, Memberships und Verknüpfungen mit bereits geprüften Datensätzen. |
| Continue the Migration with a New Configuration | Filterung, Mapping, ausgewählte Datensätze oder unterstützte Konfiguration müssen geändert werden. | Betroffene Product-Attribute, Customer-Gruppen, Memberships, Order-Felder, URLs, Content und konfigurierte Werte. |
| Perform a New Migration | Das gewünschte X-Cart-Ergebnis, die Zielbasis oder der akzeptierte Umfang haben sich wesentlich verändert. | Gesamten Katalog, Memberships, Customers, Orders, Content, URLs, Erweiterungen und externe Referenzen als eigenständiges Ergebnis neu validieren. |
Bei aktuellen X-Cart-Implementierungen kann die Revalidierung außerdem große Katalogintegrationen, Fitment-Daten, Bestands-Feeds, Distributor-Beziehungen, Multichannel-Daten, individuelle Entwicklung und externe Integrationen umfassen, wenn diese zum vereinbarten Umfang gehören. Es darf nicht angenommen werden, dass diese Bereiche automatisch gewöhnlichen Product- und Order-Datensätzen folgen.
Optionen für spätere Migrationen lösen nicht automatisch nicht unterstützte Erweiterungsdaten. Führt eine Follow-up-Anforderung neue Custom Fields, Quellcodeverhalten, externe Systemdaten oder individuelle Transformationen ein, sollte der Servicepfad vor der nächsten Aktion erneut geprüft werden.
Demo Migration sollte über den finalen Ansatz entscheiden
Demo Migration sollte der praktische Test des gewählten Ansatzes sein. Bei X-Cart muss das Sample zeigen, ob Product Variations, Attribute, Classes, Categories, Bilder, Bestand, Customers, Benutzer, Memberships, Orders, Coupons, Reviews, Content-Datensätze, SEO-Werte und erweiterungssensitive Daten mit ausreichender Sicherheit geprüft werden können.
Ein überzeugendes Demo-Migration-Ergebnis sollte mehrere Fragen beantworten:
- Werden Products mit den richtigen Kaufoptionen, Bildern, Preisen und Bestandssignalen dargestellt?
- Behalten Attribute und Classes ihre vorgesehene beschreibende oder filternde Bedeutung?
- Bleiben Customers, Benutzer, Adressen, Memberships und Profilfelder verständlich?
- Bewahrt die Order-Historie Positionen, Status, Steuern, Versand, Zahlungslabels, Coupons und Notizen?
- Unterstützen wichtige URLs, Metadaten und Content-Datensätze die Planung der SEO-Kontinuität?
- Bleiben Erweiterungs- oder Custom-Field-Anforderungen innerhalb des gewählten Ansatzes oder erfordern sie Eskalation?
Der finale Ansatz sollte erst gewählt werden, wenn für diese Fragen Nachweise vorliegen. Zeigt Demo Migration nicht unterstützte individuelle Daten, defekte Product-Logik, unvollständiges Membership-Verhalten, unklare Order-Datensätze oder ungelöste externe Identifikatoren, muss der Servicepfad vor Full Migration angepasst werden.
Entscheidungssignale für den X-Cart-Servicepfad
Der Servicepfad sollte aus Nachweisen und nicht allein aus dem Plattformnamen abgeleitet werden. X-Cart-Shops reichen von geradlinigen Katalogmigrationen bis zu stark angepassten Umgebungen mit Membership-Logik, Erweiterungen, externen Identifikatoren und hohen Anforderungen an historische Orders. Die praktische Frage lautet, ob das erforderliche Ergebnis unterstützt, konfigurierbar, klar abgegrenzt oder individuell ist.
| Entscheidungssignal | Wahrscheinliche Behandlungsrichtung |
|---|---|
| Native Katalog-, Customer-, Order- und Content-Datensätze mit begrenzter Variation-Komplexität | Standard Service kann realistisch sein, wenn der Händler die Zielplattform konfigurieren und validieren kann. |
| Großer Katalog, wichtige Memberships oder komplexe Sample-Prüfung | Managed Service kann Sequencing- und Validierungsrisiko reduzieren. |
| Unterstützte Datensätze benötigen Datensatzfilterung, Feldwerttransformation oder Anpassung der Feldzuordnung | Add-ons können helfen, sofern die Anforderung innerhalb unterstützten Verhaltens bleibt. |
| Erweiterungseigene Datensätze, Custom Fields außerhalb des unterstützten Mapping-Umfangs, individuelle Transformationen oder externe Systemidentifikatoren müssen erhalten werden | Custom-Service-Prüfung ist der sicherere Pfad, weil gewöhnliche Konfiguration die benötigte Funktion möglicherweise nicht abbildet. |
| Spätere Migrationsaktivität verändert bereits geprüfte Datensätze | Optionen für spätere Migrationen sollten mit fokussierter Revalidierung betroffener Entitäten und Funktionen der Shop-Oberfläche kombiniert werden. |
Fazit
Der richtige X-Cart-Migrationsansatz entsteht aus der Zuordnung der tatsächlichen Daten- und Strukturbelastung zum passenden Servicepfad. Standard Service kann funktionieren, wenn unterstützte Datensätze sauber passen. Managed Service hilft, wenn die Migration standardisiert bleibt, aber strukturierte Ausführung benötigt. Add-ons verbessern Datensatzfilterung, Feldwerttransformation oder Feldzuordnung innerhalb unterstützten Verhaltens. Custom Service sollte geprüft werden, wenn Custom Fields außerhalb des unterstützten Mapping-Umfangs, nicht unterstützte Erweiterungsdaten, individuelle Transformationen, externe Identifikatoren oder individuelle Anpassungen der Migrationslogik erforderlich sind.
Entity Points und Optionen für spätere Migrationen sollten diese Entscheidung unterstützen statt davon abzulenken. Optionen für spätere Migrationen helfen bei der Planung späterer Migrationsaktivität und Revalidierung. Demo Migration sollte alle diese Entscheidungen vor Full Migration praktisch bestätigen.
Häufige Fragen
Reicht Standard Service für eine X-Cart-Migration aus?
Standard Service kann ausreichen, wenn die Quellplattform unterstützt wird, die X-Cart-Zielumgebung vorbereitet ist und die erwarteten Datensätze in das unterstützte Migrationsverhalten passen. Hängt der Shop von Custom Fields, Erweiterungen, individuellen Modulen, externen Identifikatoren oder ungewöhnlicher Benutzer- und Membership-Logik ab, sollte das Projekt genauer geprüft werden.
Wann sollte Managed Service für X-Cart verwendet werden?
Managed Service ist sinnvoll, wenn die Migration innerhalb der Standardfunktionalität bleibt, der Händler aber servicegeführte Ausführung und strukturiertere Koordination wünscht. Er umfasst nicht automatisch individuelle Entwicklung, nicht unterstützte Datenbehandlung oder Anpassung individueller Migrationslogik.
Können Add-ons individuelle X-Cart-Anforderungen lösen?
Add-ons können bei Datensatzfilterung, Feldwerttransformation oder Feldzuordnung helfen. Sie sollten nicht als Lösung für nicht unterstützte Erweiterungsdaten, individuellen Code, individuelle Transformationen oder quellenspezifische Geschäftslogik betrachtet werden, die Custom Service benötigt.
Wann sind Optionen für spätere Migrationen für X-Cart sinnvoll?
Sie sind sinnvoll, wenn sich Quelldaten weiter verändern, die Zielkonfiguration vor dem Produktivstart geändert wird oder Follow-up-Migrationsaktivität erwartet wird. Jede spätere Aktivität sollte mit einer Revalidierung betroffener Products, Customers, Orders, URLs und konfigurierter Funktionen verbunden werden.
Beinhaltet ein Next-Cart Migrationsservice die Bereitstellung von X-Cart-Erweiterungen, Themes oder externen Integrationen?
Nicht automatisch. Der Service umfasst den genehmigten Daten- und individuellen Migrationsumfang. Installation von Erweiterungen, Theme-Arbeiten, Zahlungs- oder Versandeinrichtung, Fitment-Implementierung, Bestands-Feeds und externe Integrationsbereitstellung bleiben getrennt, sofern sie nicht ausdrücklich eingeschlossen sind.