Bei der Bewertung von Wix 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.
Wenn Wix als Zielplattform ausgewählt wird, hängt der richtige Migrationsansatz davon ab, was die zukünftige Wix-Site tatsächlich betreiben soll, und nicht nur von der Anzahl der zu übertragenden Datensätze. Ein kleiner Product-Katalog kann mehr Planung erfordern, wenn er von Product-Optionen, variantenbezogenem Bestand, CMS-Daten, Memberships, individuellen Formularen, externen Systemen, Velo/API-Logik oder App-eigenen Datensätzen abhängt. Ein größerer Katalog kann dagegen einen unkomplizierten Pfad verwenden, wenn die Daten unterstützt werden, die Struktur klar ist und der Händler das Ergebnis auf der Zielplattform verlässlich validieren kann.
Für Wix sollte die Wahl des Service-Pfads migrierte Datensätze von Wix-Konfiguration und Site-Umsetzung trennen. Products, Customers, Orders, CMS Pages, Blog Posts, Medien und unterstützte Metadaten können zum Migrationsumfang gehören. Checkout-Einstellungen, Zahlungsanbieter, Versand, Steuern, Domain-Verknüpfung, Site-Design, App-Konfiguration, Member-Zugriff, CMS-Berechtigungen, individueller Code und externe Integrationen können dagegen zielseitige Arbeit, Add-ons, Custom Service oder manuelle Umsetzung benötigen. Der beste Ansatz ist der leichteste Pfad, der das beabsichtigte Wix-Betriebsergebnis zuverlässig schützt.
Innerhalb der Next-Cart Migrationsservices sollten die Wix-Nachweise unterstützte Datensätze, Ausführungsverantwortung, klar begrenzte Add-ons, Velo- oder App-eigene Daten und Wix-seitige Umsetzung voneinander unterscheiden.
Was der Migrationsansatz für Wix festlegt
Ein Wix-Migrationsansatz definiert Umfang, Ausführungsverantwortung, Support-Level, Sonderbehandlung und Validierungstiefe. Er sollte beantworten, welche Datensätze migriert werden sollen, welche Wix-Einstellungen separat konfiguriert werden müssen, welche besonderen Anforderungen Add-ons benötigen und welche nicht unterstützten oder individuellen Anforderungen eine Prüfung durch Custom Service erfordern.
Der Ansatz sollte anhand von Nachweisen gewählt werden und nicht anhand pauschaler Plattformannahmen. Wix ist gehostet und benutzerfreundlich, doch dadurch wird nicht jede Migration einfach. Eine inhaltsreiche Site, ein variantenreicher Shop, ein Membership-basiertes Geschäftsmodell, ein individuell programmierter Workflow oder ein App-gesteuerter Katalog können eine sorgfältigere Service-Planung erfordern als eine konventionelle Übertragung von Products, Customers und Orders.
| Arbeitsbereich | Wix-Beispiel | Bedeutung für den Service-Pfad |
|---|---|---|
| Unterstützte migrierte Daten | Products, Collections, Customers, Orders, CMS Pages, Blog Posts, Bilder und unterstützte Metadaten. | Je nach Komplexität und benötigter Ausführungsunterstützung können Standard Service oder Managed Service passen. |
| Unterstützte Datenanpassungen | Datentypspezifische Bedingungen anwenden, Feldwerte über Ausdrücke transformieren oder unterstützte Quellfelder anderen Ziel-Feldern zuordnen. | Kann mit Data Filter, Advanced Data Mapping oder Data Transformation passen, wenn die Anforderungen innerhalb des unterstützten Verhaltens bleiben. |
| Individuelle oder nicht unterstützte Daten | App-eigene Datensätze, Custom Fields mit nicht standardmäßiger Interpretation außerhalb unterstützten Mappings, externe IDs, Velo/API-Logik, komplexe CMS Collections oder individuelle Transformationen. | Erfordert Prüfung durch Custom Service. |
| Wix-Zielkonfiguration | Zahlungen, Checkout, Versand, Steuern, Abholung, Lieferung, Rabatte, App-Einrichtung, Domain, Site-Design und Member-Einstellungen. | Muss in Wix konfiguriert und getestet werden und darf nicht aus dem Migrationsergebnis abgeleitet werden. |
Diese Unterscheidung verhindert zwei häufige Fehler. Der erste besteht darin, Wix zu knapp einzuplanen, nur weil es eine gehostete Plattform ist. Der zweite besteht darin, jede Site-Builder- oder App-Anforderung vorschnell zu Custom Service zu eskalieren, obwohl tatsächlich Wix-Zielkonfiguration oder ein begrenzter Data Filter, Advanced Data Mapping oder Data Transformation ausreicht.
Wann Standard Service ausreichen kann
Standard Service kann geeignet sein, wenn der Händler unterstützte Wix-Daten mit gewöhnlicher Struktur migrieren möchte und Vorbereitung, Ausführung und Validierung selbst steuern kann. Besonders gut passt dieser Pfad, wenn Products übersichtlich sind, Collections nicht stark von individueller Navigationslogik abhängen, Customers und Orders standardisiert sind, Inhalte begrenzt oder unterstützt sind und Wix-Site-Konfiguration vom Händler oder Site-Team übernommen werden kann.
Auch Standard Service kann ein starkes Wix-Ergebnis liefern, wenn die Erwartungen realistisch sind. Der Händler sollte verstehen, dass die Migration unterstützte Datensätze übertragen kann, während Site-Design, aktives Checkout-Verhalten, Domains, Zahlungssetup, Versandregeln, Steuerkonfiguration, Member-Zugriff und App-Konfiguration direkt in Wix erledigt werden müssen.
| Signal für Standard Service | Wix-spezifischer Grund |
|---|---|
| Products besitzen einfache Optionen oder klare Variantenstrukturen. | Unterstützte Katalogdatensätze können ohne individuelle Transformation geprüft werden. |
| Collections sind übersichtliche Produktgruppen. | Produktsuche hängt nicht von einer komplexen Rekonstruktion von Categories in Seiten und Navigation ab. |
| Bestand liegt auf Product-Ebene oder eindeutig auf Variantenebene vor. | Der Händler kann Bestandsbedeutung ohne komplexe externe Systemabhängigkeiten validieren. |
| Customers und Orders werden hauptsächlich für Nachschlagen und Servicehistorie benötigt. | Historische Datensätze erfordern kein fortgeschrittenes Account-, Member-, Loyalty- oder App-Verhalten. |
| CMS Pages und Blog Posts sind begrenzt oder leicht zu prüfen. | Content-Migration dominiert das Launch-Risiko nicht. |
| Site-Design und Checkout-Konfiguration werden direkt in Wix vorgenommen. | Migrationsumfang bleibt klar von der Zielumsetzung getrennt. |
Standard Service wird schwächer, wenn der Händler keine klaren Stichproben bereitstellen kann, nicht weiß, welche Wix-Funktionen das Verhalten nach dem Launch besitzen sollen, oder erwartet, dass individuelle Quellfunktionen automatisch übertragen werden.
Wann Managed Service sicherer sein kann
Managed Service kann sicherer sein, wenn die Daten weitgehend unterstützt werden, aber der Ausführungspfad stärkere Koordination benötigt. Wix-Migrationen können viele Prüfpunkte umfassen: Katalogstichproben, Variantenverhalten, Bestand, Customers, Orders, Inhalte, URLs, Weiterleitungen, App-Abhängigkeiten, Zielkonfiguration und Launch-Timing. Selbst wenn keine individuelle Transformation erforderlich ist, kann der Händler Unterstützung dabei benötigen, Migrationsschritte und Ergebnisprüfung zu koordinieren.
Managed Service ist besonders nützlich, wenn der Händler eine von Next-Cart geführte Ausführung wünscht und zugleich die Verantwortung für endgültige Prüfung und Entscheidungen zur Wix-Konfiguration behält. Der Service kann operativen Druck reduzieren, macht aber nicht unterstützte Datensätze nicht plötzlich unterstützt und ersetzt nicht die erforderliche Wix-Konfiguration.
| Eignung für Managed Service | Wix-Szenario |
|---|---|
| Unterstützter Umfang mit vielen Prüfbereichen | Products, Collections, Customers, Orders, CMS Pages, Blog Posts, URLs und Bilder benötigen strukturierte Prüfung. |
| Sensitives Launch-Timing | Der Quellshop bleibt aktiv, während die Wix-Site vorbereitet wird. |
| Content und SEO sind geschäftskritisch | URLs, Weiterleitungen, Landing Pages, Blog Posts, CMS Pages und interne Links benötigen sorgfältige Reihenfolge. |
| Begrenzte interne Kapazität | Der Händler kann nicht jeden Migrationsschritt und jede Prüfaufgabe sicher allein steuern. |
| Demo Migration soll Entscheidungen steuern | Stichproben müssen vor der Full Migration koordiniert interpretiert werden. |
Managed Service sollte gewählt werden, wenn Koordination und Ausführungssicherheit entscheidend sind. Liegt die eigentliche Anforderung jedoch in App-eigenen Datensätzen, Custom Fields außerhalb unterstützten Mappings, Velo/API-Logik, externen Kennungen oder nicht unterstütztem Quellverhalten, kann weiterhin Custom Service erforderlich sein.
Wann Add-ons die richtige Wahl sind
Add-ons sind sinnvoll, wenn der Händler klar begrenzte Änderungen innerhalb des unterstützten Migrationsverhaltens benötigt. Sie können Datensätze anhand feldbasierter Bedingungen je Datentyp filtern, Feldwerte über Ausdrücke transformieren oder unterstützte Standard-Quellfelder anderen kompatiblen unterstützten Zielfeldern zuordnen, wobei die Werte unverändert bleiben. Sie sind kein Ersatz für die Migration nicht unterstützter Daten oder die Rekonstruktion individueller Geschäftslogik.
Bei Wix sind Add-ons besonders hilfreich, wenn klar definierte und unterstützte Anforderungen vorliegen, zum Beispiel der Ausschluss von Datensätzen nach festen Bedingungen, die Transformation unterstützter Werte über Ausdrücke oder die Änderung eines unterstützten Feldziels.
| Add-on-Anforderung | Wix-Beispiel | Grenzprüfung |
|---|---|---|
| Data Filter | Unterstützte Feldbedingungen für Products, Orders, Customers, Blog Posts oder Content anwenden, sodass nur passende Datensätze migriert werden. | Die Filterung darf keine Datensätze entfernen, die für Support, SEO oder Launch-Validierung benötigt werden. |
| Data Transformation | Ausdrücke verwenden, um unterstützte Feldwerte während der Migration nach Wix zu transformieren. | Ausdruck und resultierende Werte müssen klar begrenzt und unterstützt bleiben. |
| Advanced Data Mapping | Unterstützte Standard-Quellfelder anderen unterstützten Wix-Zielfeldern für Product, Customer, Order, Content oder Metadaten zuordnen, wobei die Werte unverändert bleiben. | Mapping darf kein nicht unterstütztes Wix-Verhalten oder individuelle App-Logik erzeugen. |
| Tailored Add-on oder Custom Add-on | Eine Standard Add-on-Funktion benötigt projektspezifische Anpassung oder eine individuelle Add-on-Funktion ist erforderlich. | Diese Arbeit wird über Custom Service geprüft und angeboten und nicht als Umfang eines Standard Add-on behandelt. |
Eine gute Add-on-Anforderung ist konkret. „Wix soll sich wie der alte Shop verhalten“ ist zu unbestimmt. Eine brauchbare Anforderung nennt Datentypbedingung, Transformationsausdruck oder Quell- und Zielfeld und legt zusätzlich fest, wie das Ergebnis in Wix validiert wird.
Wann Custom Service in Betracht gezogen werden sollte
Custom Service sollte geprüft werden, wenn die Wix-Migrationsanforderung über unterstütztes Migrationsverhalten hinausgeht. Auslöser ist nicht allein die Shop-Größe. Entscheidend ist der Bedarf an individueller Bewertung, nicht unterstützten Datensätzen, App-eigenen Daten, Custom Fields mit nicht standardmäßiger Interpretation außerhalb unterstützten Mappings, externen Kennungen, individueller Transformation, Behandlung einer individuellen Plattform, Velo/API-Logik oder Anpassung individueller Migrationslogik.
Individuelle Wix-Anforderungen entstehen häufig, wenn Verhalten des Quellshops nicht in gewöhnlichen Commerce-Daten gespeichert ist. Beispiele sind Produktkonfiguratoren, Subscription- oder Membership-Logik, Booking- oder Event-Historie, individuelle Customer-Felder, CRM- oder Loyalty-IDs, externe Bestandsreferenzen, Marketplace-Datensätze, CMS Collections, dynamische Seiten, individuelle Datenbankstrukturen, Velo-ähnlicher Code oder private Integrationen.
| Auslöser für Custom Service | Wix-spezifische Bedeutung |
|---|---|
| App-eigene Product-, Customer-, Order- oder Content-Datensätze | Die Standardmigration enthält Daten oder Verhalten der App möglicherweise nicht. |
| Custom Fields oder externe Kennungen, deren erforderliche Behandlung unterstütztes Mapping oder Transformation überschreitet | Die Werte können individuelle Interpretation, ein nicht standardmäßiges Ziel oder Kontinuität zu einem externen System benötigen, die Standard Add-ons nicht bereitstellen. |
| Velo/API- oder quellcodeabhängiges Verhalten | Die Anforderung kann eine Prüfung individueller Logik oder Planung zielseitiger Umsetzung benötigen. |
| Komplexe CMS Collections oder externe Datenbanken | Content- und Datenbeziehungen passen möglicherweise nicht in die gewöhnliche Migration von CMS Pages oder Blog Posts. |
| Produktkonfiguratoren, Formulare, Memberships, Bookings oder Pricing-Plan-Verhalten | Das Verkaufsmodell kann Wix Apps, Zielkonfiguration oder individuelle Behandlung erfordern. |
| Nicht standardmäßige Checkout-, Versand-, Steuer-, Fulfillment- oder Zahlungslogik | Aktives Verhalten kann Wix-Konfiguration, Service-Plugin-Planung oder bewusst akzeptiertes Redesign benötigen. |
Custom Service sollte anhand repräsentativer Beispiele eingegrenzt werden. Händler sollten Beispieldatensätze, gegebenenfalls Screenshots oder Exporte aus der Quelle, Erwartungen an das Ziel und Validierungsregeln bereitstellen. Ohne Beispiele wird die individuelle Prüfung zu abstrakt, um das Wix-Ergebnis zuverlässig zu schützen.
Custom Service umfasst Wix-App-Implementierung, Velo-Entwicklung, Aufbau von CMS oder dynamischen Seiten, Zahlungs- und Versandeinrichtung, Theme- oder Seitendesign oder Deployment externer Integrationen nicht automatisch, sofern diese Verantwortlichkeiten nicht ausdrücklich in den vereinbarten Umfang aufgenommen wurden.
Was Demo Migration entscheiden sollte
Demo Migration sollte prüfen, ob der gewählte Ansatz die Wix-spezifische Bedeutung erhalten kann. Sie ist nicht lediglich eine Vorschau der Datensatzanzahl. Für Wix sollte Demo Migration beantworten, ob Products, Collections, Varianten, Bestand, Customers, Orders, Inhalte, URLs und Anforderungen an Sonderbehandlung über den richtigen Pfad verarbeitet werden.
Ein starker Wix-Demo-Migration-Stichprobensatz umfasst gewöhnliche und schwierige Fälle. Ziel ist, den Ansatz zu belegen und nicht nur die einfachsten Datensätze freizugeben.
| Stichprobenbereich | Entscheidung, die er unterstützen soll |
|---|---|
| Einfaches Product | Ob die grundlegende Wix-Katalogübertragung sauber funktioniert. |
| Product mit Optionen/Varianten | Ob Auswahlwerte, Varianten-SKUs, Preise, Gewichte, Bilder und Bestand wie erwartet funktionieren. |
| Collection-/Category-Stichprobe | Ob die Bedeutung der Produktentdeckung im Quellshop in Wix Collections, Seiten, Menüs oder Weiterleitungen überführt werden kann. |
| Customer mit Orders | Ob Käuferidentität und historischer Order-Kontext weiterhin nützlich bleiben. |
| Gastkäufer oder doppeltes Profil | Ob Identitätsannahmen Bereinigung oder Akzeptanzregeln benötigen. |
| Erstattete oder rabattierte Order | Ob Ausnahmen in historischer Order-Historie lesbar bleiben. |
| CMS Page, Blog Post oder medienintensiver Content | Ob Entscheidungen zu Content-Migration, Neuaufbau oder Weiterleitung klar sind. |
| App-, individueller oder externer Datensatz | Ob die Anforderung zu Add-ons, Custom Service, Zielkonfiguration oder Ausschluss gehört. |
Zeigt Demo Migration, dass wichtige Wix-Datensätze ihre Bedeutung verlieren, sollte der Ansatz vor Full Migration angepasst werden. Die richtige Reaktion ist nicht, mit einem schwachen Pfad fortzufahren und zu hoffen, dass der vollständige Datenbestand strukturelle Probleme löst.
Entity Points und Wix-Umfangsplanung
Entity Points helfen, das geeignete Migrationsvolumen einzuschätzen, messen die Wix-Komplexität jedoch nicht allein. Bei Wix können berechtigte Product-, Customer-, Order- und Blog-Posts-Datensätze beim ersten Migrationsvorgang Entity Points verbrauchen, während bereits auf demselben Pfad gezählte Datensätze nur einmal zählen. Komplexität durch CMS, Members, Apps und Velo wird separat bewertet.
Entity Points sollten bei Wix gemeinsam mit der Datenbedeutung betrachtet werden. Eine kleine Wix-Migration kann Custom Service benötigen, wenn sie App-eigene Daten, CMS Collections, Custom Fields außerhalb unterstützten Mappings, externe Kennungen oder Velo/API-abhängiges Verhalten enthält. Eine größere Migration kann weiterhin für Standard Service oder Managed Service geeignet sein, wenn die unterstützten Datensätze klar sind und der Händler das Ergebnis validieren kann.
| Umfangssignal | Was es einschätzen hilft | Was es nicht beweist |
|---|---|---|
| Product-Anzahl | Katalogvolumen und mögliche Nutzung von Entity Points. | Ob Optionen, Auswahlwerte, Varianten, Bilder, Collections und Bestand in Wix nutzbar sind. |
| Customer-Anzahl | Volumen der Käuferdatensätze. | Ob Contacts, Members, Subscribers, App-Teilnehmer und externe IDs ihre Bedeutung behalten. |
| Order-Anzahl | Volumen der historischen Orders. | Ob Zahlungs-, Erstattungs-, Fulfillment-, Rabatt- und externe Referenzkontexte lesbar sind. |
| Blog-Posts-Anzahl | Content-Volumen, sofern relevant. | Ob CMS Pages, URLs, Weiterleitungen, Medien und Site-Struktur launchbereit sind. |
Entity Points unterstützen die Planung, ersetzen aber nicht die Bewertung des Service-Pfads. Der gewählte Ansatz hängt weiterhin von unterstütztem Verhalten, Zielkonfiguration, individuellen Anforderungen, Ausführungsverantwortung und Validierungsnachweisen ab.
Optionen für spätere Migrationen und Wix-Launch-Timing
Optionen für spätere Migrationen werden relevant, wenn sich die Quellumgebung weiter verändert, während die Wix-Site vorbereitet wird. Die richtige Aktion hängt davon ab, ob lediglich neue Datensätze migriert werden müssen, eine unterstützte Konfiguration geändert wurde oder das beabsichtigte Zielergebnis neu definiert wurde.
| Aktuelle Aktion | Wann sie zu Wix passt | Erforderliche erneute Validierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Neue berechtigte Datensätze wurden hinzugefügt und die freigegebenen Filter, Mappings, Datentypauswahl und Konfiguration bleiben geeignet. | Neu migrierte Products, Customers, Orders und Blog Posts sowie Wix-Stores-Regressionsstichproben prüfen. |
| Continue the Migration with a New Configuration | Unterstützte Mappings, Filter, Datentypauswahl oder Konfiguration wurden nach Demo Migration geändert. | Betroffene Products, Optionen, Varianten, Collections, Customers, Orders, Content und URL-Ausgaben erneut prüfen. |
| Perform a New Migration | Wix-Ziel-Site oder beabsichtigtes Migrationsergebnis haben sich so stark geändert, dass die vorherige Ausgabe ersetzt werden sollte, während der gekaufte Pfad Quellplattform → Zielplattform unverändert bleibt. Ein anderer Pfad benötigt einen separaten gekauften Migrationsservice. | Das erneuerte Zielergebnis über Wix Stores, Content, URLs und akzeptierte individuelle oder App-Grenzen hinweg validieren. |
Optionen für spätere Migrationen ersetzen weder Wix-Site-Konfiguration noch App-Setup, Velo-Entwicklung, Aufbau von CMS Collections, Umsetzung dynamischer Seiten, aktive Zahlungs- und Versandeinrichtung oder Deployment von Integrationen. Sie sollten mit einem definierten Launch-Timing- und Revalidierungsplan ausgewählt werden.
Signale, dass der gewählte Wix-Ansatz zu leicht ist
Der gewählte Ansatz ist zu leicht, wenn Wix als einfache Importdestination behandelt und die Site-Commerce-Komplexität ignoriert wird. Warnsignale zeigen sich gewöhnlich in der Stichprobenprüfung und nicht in Datensatzanzahlen.
| Warnsignal | Wahrscheinliche Reaktion |
|---|---|
| Product-Optionen, Auswahlwerte, Varianten und Bestand lassen sich nicht sicher validieren. | Katalogumfang überarbeiten oder stärkere Ausführungs-/Individualprüfung erwägen. |
| Von Source Categories wird erwartet, dass sie automatisch Menüs, Seiten, Filter und SEO-Pfade wiederherstellen. | Collection-Migration von Site-Struktur und Weiterleitungsplanung trennen. |
| Customer-Datensätze umfassen Members, Contacts, Subscribers, Loyalty, Bookings oder App-Teilnahme. | Identitätstypen klassifizieren und unterstützte gegenüber individuellen Pfaden prüfen. |
| Von historischen Orders wird erwartet, dass sie den aktiven Wix-Checkout konfigurieren. | Migrierte Historie von Zahlungs-, Versand-, Steuer- und Order-Setting-Konfiguration trennen. |
| CMS Pages, Blog Posts, dynamische Seiten oder individuelle Data Collections sind für den Launch zentral. | Content-Migration, Neuaufbau, Weiterleitungen, CMS-Konfiguration oder Prüfung durch Custom Service vorsehen. |
| App-eigene Felder, Velo/API-Logik oder externe IDs sind geschäftskritisch. | Nicht auf generischen Migrationsumfang vertrauen; je nach Bedarf Add-ons oder Custom Service bewerten. |
| Der Händler kann nicht festlegen, wer Wix-Konfiguration und Migrationsergebnis validiert. | Managed Service kann bei der Koordination helfen, Akzeptanzkriterien müssen dennoch definiert sein. |
Diese Signale sollten vor Full Migration bearbeitet werden, da sie sich bei nahendem Launch-Termin meist schwieriger lösen lassen.
Den praktischen Wix-Pfad wählen
Der praktische Wix-Pfad ist der leichteste Service-Pfad, der das zukünftige Site-Commerce-Ergebnis zuverlässig schützen kann. Standard Service kann für unterstützte, unkomplizierte Daten ausreichen, wenn der Händler Zielkonfiguration und Validierung selbst steuern kann. Managed Service ist sicherer, wenn die Daten unterstützt werden, aber Koordination von Ausführung und Review wichtig ist. Add-ons helfen bei unterstützter Datensatzfilterung, Transformation von Feldwerten oder Feldzuordnung. Custom Service ist erforderlich, wenn individuelle, nicht unterstützte, App-eigene, externe oder maßgeschneiderte Transformationsanforderungen das Migrationsergebnis beeinflussen.
Ein ausgereifter Ansatz lässt sich in vier Aussagen zusammenfassen:
- welche Wix-Datensätze migriert werden sollen;
- welche Wix-Einstellungen und Site-Elemente separat konfiguriert oder neu aufgebaut werden müssen;
- welche Add-ons oder Anforderungen an Custom Service zum Umfang gehören;
- welche Demo-Migration-Stichproben vor Full Migration bestehen müssen.
Sind diese Aussagen nicht klar, sollte der Service-Pfad nicht als final gelten. Die Qualität der Wix-Migration hängt davon ab, den gewählten Ansatz an die tatsächliche Site-Commerce-Umgebung anzupassen, die der Händler nach dem Launch betreiben möchte.
Fazit
Die Wahl des richtigen Wix-Migrationsansatzes erfordert mehr als eine Schätzung des Datensatzvolumens. Der Ansatz muss Wix-Stores-Katalogstruktur, Optionen, Auswahlwerte, Varianten, Bestand, Customers, Contacts, Members, Orders, CMS Pages, Blog Posts, URLs, Apps, Velo/API-Logik, externe Systeme, zielseitige Einrichtung, Entity Points, Optionen für spätere Migrationen und Verantwortlichkeit für die Validierung berücksichtigen.
Der richtige Pfad ist nicht immer der komplexeste. Es ist der Pfad, der unterstützten Migrationsumfang klar von Wix-Konfiguration trennt, erkennt, wann Add-ons ausreichen, echte individuelle Anforderungen zur Prüfung durch Custom Service eskaliert und Demo Migration nutzt, um nachzuweisen, dass das Wix-Zielergebnis tatsächlichen Verkauf, Site-Erlebnis und betriebliche Prüfung unterstützt.
Häufige Fragen
Wann reicht Standard Service für eine Wix-Migration aus?
Standard Service kann ausreichen, wenn der Händler unterstützte Wix-Datensätze mit gewöhnlicher Struktur benötigt, Wix-Konfiguration direkt verwalten kann und Products, Collections, Customers, Orders, Content und URLs ohne umfangreiche Koordination oder individuelle Behandlung validieren kann.
Wann sollte Managed Service für Wix erwogen werden?
Managed Service ist sinnvoll, wenn die Migration innerhalb unterstützter Funktionen bleibt, der Händler aber stärkere Ausführungsunterstützung, Koordination, Stichprobenprüfung, Launch-Window-Planung oder Hilfe bei der Steuerung der Migrationsschritte vor Full Migration benötigt.
Wie unterscheiden sich Add-ons und Custom Service bei Wix?
Add-ons unterstützen klar begrenzte Datensatzfilterung, Feldwerttransformation oder Feldzuordnung innerhalb unterstützten Migrationsverhaltens. Custom Service ist für nicht unterstützte App-Daten, Custom Fields mit nicht standardmäßiger Interpretation außerhalb unterstützten Mappings, externe Kennungen, Velo/API-Logik, individuelle Transformation, Behandlung einer individuellen Plattform oder Anpassung individueller Migrationslogik vorgesehen.
Was sollte Demo Migration für Wix vor Full Migration nachweisen?
Demo Migration sollte belegen, dass repräsentative Wix-Datensätze wie erwartet funktionieren: Products, Varianten, Collections, Bestand, Customers, Orders, CMS Pages, Blog Posts, URLs und alle App-/individuellen Stichproben, die den gewählten Service-Pfad beeinflussen.
Welche Migrationsaktion sollte für Wix-Folgearbeiten verwendet werden?
Verwenden Sie Continue the Migration with the Last Used Configuration, wenn lediglich neue berechtigte Datensätze unter der freigegebenen Konfiguration ergänzt werden müssen. Verwenden Sie Continue the Migration with a New Configuration, wenn unterstützte Filter, Mappings, Datentypauswahl oder Konfiguration geändert wurden. Verwenden Sie Perform a New Migration, wenn sich das beabsichtigte Wix-Ergebnis oder die Ziel-Site-Konfiguration wesentlich geändert hat, während der gekaufte Migrationspfad gleich bleibt. Muss der Pfad Quellplattform → Zielplattform geändert werden, ist ein separat gekaufter Migrationsservice erforderlich.