Wenn Wix 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 Wix als Zielplattform ausgewählt werden soll, muss die Vorbereitung Commerce-Datensätze, Site-Inhalte, Member-Identität, CRM-Daten, CMS Collections, Anwendungen und individuellen Code voneinander trennen, bevor ein Migrationslauf beginnt. Wix Stores, Wix Contacts, Wix Members, Wix CMS, Wix Blog und das breitere Wix-App-Ökosystem können gemeinsam auf einer Site eingesetzt werden, besitzen aber nicht dieselben Datensätze.
Ein brauchbares Vorbereitungspaket hält für jeden wichtigen Bereich vier Dinge fest: die erforderliche Maßnahme, den verantwortlichen Owner, die bereitzustellenden Nachweise und die Bedingung, unter der der Bereich als bereit gilt. Dadurch wird verhindert, dass ein Product-Datensatz mit einer vollständig umgesetzten Storefront verwechselt, ein Contact als Member behandelt oder eine CMS Collection fälschlich als Eigentümer von App-Daten angesehen wird.
Wix-Site und Commerce-Betriebsmodell festlegen
Definieren Sie, welche Wix-Produkte und Site-Ebenen im Zielshop betrieben werden sollen.
| Vorbereitungsbereich | Festzuhaltende Entscheidung | Verantwortlich | Nachweis der Bereitschaft |
|---|---|---|---|
| Wix Stores | Ob Products, Checkout, Orders, Bestand und Fulfillment zentrale Bestandteile des Ziels sind | Commerce-Verantwortlicher | Zusammenfassung des Shop-Betriebsmodells |
| Wix-Site-Struktur | Welche Seiten, Menüs, dynamischen Seiten, Member-Bereiche und regionalen Routen benötigt werden | Site-Verantwortlicher | Seiten- und Navigationsplan |
| Wix Contacts und Members | Welche Identitäten Contacts, Customers, Members, Subscribers oder App-Teilnehmer sind | Customer-Verantwortlicher | Matrix zur Identitätsklassifizierung |
| Wix CMS | Welche individuellen Collections, Referenzen, Berechtigungen und dynamischen Seiten weiterhin erforderlich sind | Content-/Datenverantwortlicher | Inventar der Collections und Beziehungen |
| Wix Apps | Welche Datensätze Wix Blog, Bookings, Pricing Plans, Reviews, Events oder anderen Anwendungen gehören | App-Verantwortliche | Abhängigkeitsregister je App |
| Externe Systeme | Welche ERP-, PIM-, WMS-, CRM-, Marketplace-, Steuer-, Versand- oder Analytics-Systeme weiterhin maßgeblich bleiben | Technischer Verantwortlicher | System-of-Record-Übersicht |
Das Betriebsmodell ist bereit, wenn jede wichtige Datensatzfamilie einen vorgesehenen Wix- oder externen Eigentümer besitzt und das Site-Team versteht, welche Anforderungen zu Migrationsdaten und welche zur Wix-Site-Konfiguration gehören.
Zugriff, Quellarchive und Verantwortlichkeit für Änderungen vorbereiten
Sammeln Sie:
- Administratorzugriff auf Quellplattform und Wix-Site;
- erforderliche Berechtigungen für Wix Stores, Contacts, Members, CMS, Blog, Anwendungen, Domains und SEO;
- datierte Exporte oder Backups für Products, Customers, Orders, Inhalte, Medien, Categories, URLs, Reviews und individuelle Daten;
- App-Exporte und API-Dokumentation, sofern verfügbar;
- externe Kennungen, die ERP-, CRM-, Lager-, Marketplace- oder Fulfillment-Systeme verwenden;
- einen Verantwortlichen für Änderungen an Products, Customers, Orders, Inhalten und Bestand während des Migrationsfensters.
| Nachweis | Warum er wichtig ist | Bereitschaftsbedingung |
|---|---|---|
| Zugriffsprotokoll | Bestätigt, dass die erforderlichen Bereiche in Quelle und Wix geprüft werden können | Berechtigungen stehen den verantwortlichen Personen zur Verfügung |
| Datiertes Quellarchiv | Bewahrt einen wiederherstellbaren Referenzstand | Dateien lassen sich öffnen und enthalten Exportdaten |
| Medienarchiv | Schützt Product-, Seiten-, Blog-Post- und CMS-Medien | Dateien und Quellbeziehungen können identifiziert werden |
| App-Inventar | Macht Datensätze außerhalb gewöhnlicher Katalog- und Content-Exporte sichtbar | Jede aktive App besitzt einen Owner und eine Nachweisquelle |
| Register externer IDs | Schützt Synchronisation und Abstimmung | Jeder Schlüssel ist der richtigen Entitätsebene zugewiesen |
| Änderungsprotokoll | Erfasst Quelländerungen nach dem Referenzarchiv | Änderungen an Products, Orders, Customers, Inhalten und Bestand besitzen verantwortliche Owner |
Kann eine Quellanwendung keinen Export bereitstellen, dokumentieren Sie die Einschränkung und den verantwortlichen Owner, statt die Daten als nicht vorhanden zu behandeln.
Products, Optionen, Varianten, Modifiers und Medien vorbereiten
Wix Catalog V3 bildet jedes Product über mindestens eine Variante ab. Product-Optionen erzeugen Varianten, während Modifiers zusätzliche Informationen erfassen, ohne Varianten zu erzeugen. Bereiten Sie repräsentative Product-Familien vor, an denen sich diese Unterschiede zeigen.
Einzubeziehen sind:
- einfache Products mit einer Standardvariante;
- Products mit mehreren Optionskombinationen;
- variantenbezogene SKU-, Barcode-, Preis-, Kosten-, Gewichts-, Medien- und Bestandswerte;
- Modifiers wie Geschenknachrichten, Personalisierung oder zusätzliche Auswahlwerte;
- digitale Products und gegebenenfalls variantenspezifische digitale Dateien;
- Products mit Brands, Ribbons, Info Sections, Categories und wiederverwendbaren Customizations;
- Bundles, Subscriptions, Bookings oder App-eigenes Product-Verhalten;
- ERP-, PIM-, Marketplace-, Lieferanten- und Fulfillment-Kennungen.
| Verhalten im Quellsystem | Vorbereitungsentscheidung | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Eine Auswahl erzeugt eine verkaufsfähige Kombination | Optionsauswahl und Variantenzuständigkeit definieren | Eltern-/Kind-IDs, SKU, Preis, Gewicht, Medien und Bestand | Jede Kombination besitzt genau eine vorgesehene Wix-Variante |
| Eine Auswahl erfasst Käufereingaben | Modifier- oder App-Zuständigkeit definieren | Eingabetyp, zulässige Werte, Preiswirkung und Beispiel einer Order-Position | Der Wert wird nicht fälschlich als bestandsführend klassifiziert |
| Product enthält strukturierte beschreibende Daten | Product-Feld, Info Section, Brand, Category, CMS oder App als Eigentümer festlegen | Feldschema und fortbestehender Verbraucher | Jedes Feld besitzt einen benannten Wix- oder externen Eigentümer |
| Product-Verhalten ist App-eigen | Fortbestehende oder ersetzende App identifizieren | Verwandte Product-Datensätze und Konfigurationsnachweise | Erforderliche App-Daten sind im Abhängigkeitsregister enthalten |
| Product verwendet externe Stammdaten | System of Record und Schlüssel definieren | ERP-/PIM-IDs und Abfragebeispiele | Jede Kennung bleibt mit der richtigen Variante oder dem richtigen Product verbunden |
Der Katalogbereich ist bereit, wenn für jedes wichtige Product-Muster eine definierte Product-Varianten-Options-Modifier-Struktur vorliegt und die Quellnachweise wiederverwendbare Product-Daten von Käufereingaben oder App-eigenen Datensätzen unterscheiden.
Bestands-Locations und Verfügbarkeitsregeln vorbereiten
In Wix Catalog V3 wird Bestand auf Varianten-Location-Ebene verfolgt. Jedes Inventory Item verbindet eine Variante mit einer Bestands-Location und kann Mengen- oder In-Stock-Tracking sowie gegebenenfalls Preorder-Einstellungen verwenden.
Bereiten Sie vor:
- die Liste der Lager, Shops, Fulfillment-Center und virtuellen Bestands-Locations;
- die Standard-Wix-Bestands-Location;
- Product- und Variantenkennungen, die jede Bestandsquelle verwendet;
- Beispiele für Mengen-, In-Stock-, unbegrenzte, Preorder- und nicht verfügbare Zustände;
- Zuordnungen von Quell- zu Wix-Locations;
- das zukünftige System of Record für den Bestand;
- Anfangsmengen und den Zeitstempel oder Quell-Snapshot, den sie darstellen.
| Bestandsfall | Verantwortlich | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Bestand an einer Location | Bestandsverantwortlicher | Bericht über Variantenmengen | Jede Menge wird genau einer Wix-Variante an der Standard-Location zugeordnet |
| Bestand an mehreren Locations | Operations-Verantwortlicher | Varianten-Location-Matrix | Jede Quell-Location besitzt ein vorgesehenes Wix- oder externes Ziel |
| ERP- oder WMS-geführter Bestand | Integrationsverantwortlicher | Systemschlüssel und Synchronisationsbeispiel | Wix-Anfangswerte und zukünftige Autorität sind dokumentiert |
| Preorder-Product | Merchandising-Verantwortlicher | Preorder-Regeln je Variante und Location | Preorder-Kapazität und Zuständigkeit für Verfügbarkeit sind klar |
| In-Stock-Tracking ohne Menge | Katalogverantwortlicher | Repräsentative Products und Quellstatuswerte | Verfügbarkeitszustände werden nicht mit numerischen Mengen verwechselt |
Location-spezifischer Bestand sollte nicht summiert werden, sofern das Ziel nicht bewusst einen gemeinsamen Bestandspool verwendet. Die Bereitschaftsbedingung ist eine kontrollierte Zuordnung von verkaufsfähiger Quellidentität und Location zum vorgesehenen Wix Inventory Item.
Contacts, Members, Customers und Marketingkontext vorbereiten
Wix Contacts und Wix Members sind verbunden, aber eigenständig. Contacts können Identität, Labels, Subscription-Status und erweiterte Felder enthalten. Members besitzen Member-IDs, Kontostatus, Profilsichtbarkeit und Beziehungen zur Members Area. Commerce-Customers und App-Teilnehmer können zusätzlichen Kontext ergänzen.
Bereiten Sie vor:
- registrierte Käufer, Gastkäufer, Subscribers, Contacts, Members und App-Teilnehmer;
- Beispiele mit doppelten E-Mail-Adressen und Telefonnummern;
- Contact-Labels, Custom Fields, Subscription-Status und Einwilligungsnachweise;
- Anforderungen an Member-Status, Privatsphäre, Profil, Badge und Custom Fields;
- Adressen und historische Order-Beziehungen;
- Zuständigkeit für Loyalty, Bookings, Pricing Plans, Community oder CRM;
- externe Contact-, Customer- und Member-Kennungen.
| Identitätstyp | Verantwortlich für die Vorbereitung | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Käufer oder Gast | Customer Operations | Customer- und Order-Beispiele | Historischer Commerce-Kontext ist mit dem vorgesehenen Contact- oder Customer-Datensatz verbunden |
| Contact | CRM-Verantwortlicher | Labels, Felder, Subscription-Status und Einwilligungsquelle | Contact-Bedeutung ist unabhängig von Membership dokumentiert |
| Site Member | Members-Area-Verantwortlicher | Member-ID, Contact-ID, Status, Profil und Zugriffserwartungen | Member- und Contact-Identität werden nicht als austauschbare IDs behandelt |
| App-Teilnehmer | App-Verantwortlicher | Booking-, Plan-, Loyalty-, Review- oder Community-Datensätze | Die Anwendungsbeziehung besitzt einen fortbestehenden Eigentümer |
| Externer CRM-Datensatz | Integrationsverantwortlicher | CRM-ID und Matching-Regel | Der dauerhafte Schlüssel ist mit der richtigen Wix-Identität verbunden |
Authentifizierung sollte getrennt von Identität vorbereitet werden. Wenn Quellpasswörter nicht wiederverwendet werden können, dokumentieren Sie den verantwortlichen Owner und die erforderliche Customer-Kommunikation, ohne Passwortübertragbarkeit als gewöhnliche Customer-Daten zu behandeln.
Historische Orders und Transaktionskontext vorbereiten
Wählen Sie Orders aus, an denen sich Product- und Variantenidentität, Modifiers, Rabatte, Steuern, Billing, Versand, Zahlung, Transactions, Fulfillment, Rückerstattungen und externe Referenzen prüfen lassen.
Einzubeziehen sind:
- gewöhnliche, stornierte, erstattete und teilweise erfüllte Orders;
- Orders mit Varianten-Products und Modifiers;
- Orders von Gästen und registrierten Customers;
- mehrere Versand- oder Fulfillment-Datensätze;
- Orders aus für Wix relevanten Anwendungen oder externen Kanälen;
- Marketplace-, Buchhaltungs-, ERP-, WMS-, CRM- oder Support-Referenzen.
| Historischer Bereich | Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Gekaufte Positionen | Beispiele für Product, Variante, Modifier, Menge und Preis | Die gekaufte Konfiguration lässt sich anhand des Quellpakets erklären |
| Customer-Kontext | Gast-/registrierte Identität und Adressen | Die vorgesehene Contact-, Customer- oder Member-Beziehung ist dokumentiert |
| Zahlungs- und Erstattungskontext | Beispiele für Methode, Transaction, Refund und Gesamtsumme | Historische Referenzen sind von der aktuellen Wix-Zahlungskonfiguration getrennt |
| Fulfillment-Kontext | Beispiele für Versand, Tracking, Status und Positionszuordnung | Vergangenes Fulfillment lässt sich verstehen, ohne aktiven Versand zu konfigurieren |
| Externe Abstammung | Order-IDs aus verbundenen Systemen | Abstimmungsschlüssel bleiben auf der richtigen Order-Ebene erhalten |
Historische Orders bewahren vergangenen Commerce. Aktuelle Wix-Einstellungen für Checkout, Zahlung, Fulfillment, Benachrichtigungen und Bestandsaktualisierung bleiben separate Vorbereitung unter Verantwortung der zuständigen Site- und Operations-Teams.
CMS Collections, Seiten, Blog Posts, Medien und URLs vorbereiten
Wix CMS kann individuelle Collections, Data Items, Referenzfelder, Berechtigungen, Indizes, Beziehungen zu dynamischen Seiten und externe Datenbankverbindungen enthalten. Wix-App-Collections können Daten spiegeln, die Wix-Anwendungen gehören. Bereiten Sie diese Ebenen getrennt vor.
Sammeln Sie:
- CMS-Collection-Schemas, Felder, Referenzen, Berechtigungen und Indizes;
- repräsentative Data Items und Eltern-Kind-Referenzen;
- dynamische Seiten und die Collection-Felder, die in ihren Routen verwendet werden;
- CMS Pages, Wix Blog Posts, Product- und Category-Inhalte sowie App-eigene Inhalte;
- Inventare für Bilder, Videos, Dateien und Alt-Texte;
- hochwertige URLs, Metadaten, interne Links, Menüs, Weiterleitungen und Domain-Pläne;
- Zuständigkeit für externe Datenbanken und Verbindungsabhängigkeiten.
| Content-Bereich | Verantwortlich | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| CMS Collection | Daten-/Content-Verantwortlicher | Schema, Felder, Referenzen, Berechtigungen und Sample Items | Jede Collection besitzt einen Geschäftszweck und eine Route oder einen Verbraucher |
| Wix-App-Collection | App-Verantwortlicher | App-Name, Quelldatensätze und Read/Write-Erwartungen | App-eigene Daten werden nicht als gewöhnliche Custom Collection behandelt |
| CMS Page oder Blog Post | Redaktioneller Verantwortlicher | Inhalt, Autoren-/Datums-Kontext, Medien, Metadaten und Quell-URL | Jeder Datensatz besitzt einen vorgesehenen Wix-Content-Eigentümer und eine Route |
| Dynamische Seite | Site-Verantwortlicher | Collection, Slug-Feld, Referenzfelder und Seitenzuordnung | Die Seite lässt sich anhand dokumentierter Beziehungen neu aufbauen |
| Prioritäre URL | SEO-Verantwortlicher | Quellpfad, Ziel, Weiterleitung und Entscheidung zur Einstellung | Jeder hochwertige Pfad besitzt ein freigegebenes Ergebnis |
Wix-URL-Weiterleitungen unterliegen plattformspezifischen Einschränkungen. Nicht unterstützte Quellmuster sollten deshalb vor dem Migrationslauf im Routenregister identifiziert werden und nicht erst, nachdem Quellpfade außer Betrieb genommen wurden.
Apps, Velo-Logik, APIs und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für jede Wix-App, Quell-App, API, jeden Webhook, jede Automatisierung, Velo-Funktion, jedes Service-Plugin, jede externe Datenbank und jede verbundene Business-Plattform.
Halten Sie für jede Abhängigkeit fest:
- Geschäftszweck;
- betroffene Products, Varianten, Contacts, Members, Orders, CMS Items oder Inhalte;
- maßgebliches System und externe IDs;
- Verfügbarkeit von Export oder API;
- Verantwortlicher für Konfiguration und Zugangsdaten;
- fortbestehendes Ziel, Ersatz- oder Stilllegungsentscheidung;
- erforderliche Quellnachweise, bevor der Ziel-Workflow konfiguriert wird.
Prioritäre Abhängigkeiten sind ERP-, PIM-, WMS-, CRM-, Steuer-, Versand-, Marketplace-, Loyalty-, Subscription-, Booking-, Event-, Pricing-Plan-, Membership-, Review-, Such-, Analytics- und Marketingplattformen.
Das Register ist bereit, wenn jedes aktive Custom Field oder jeder Anwendungsdatensatz einen benannten Eigentümer, eine übergeordnete Entität, einen fortbestehenden Verbraucher und einen dauerhaften Schlüssel besitzt.
Repräsentative Migrationsstichproben auswählen
| Stichprobe | Zweck der Vorbereitung |
|---|---|
| Einfaches Product | Gewöhnliches Product- und Standardvariantenmuster festlegen |
| Product mit mehreren Optionen und Varianten | Zuständigkeit für Option, SKU, Medien, Preis und Variante sichtbar machen |
| Product mit Modifiers | Käufereingaben und Order-Positionsbeziehungen sichtbar machen |
| Multi-Location-Inventory-Item | Varianten-Location-Zuständigkeit und Bestandsautorität sichtbar machen |
| Contact mit Member-Verknüpfung | Unterschiedliche Contact- und Member-IDs sowie Profilkontext sichtbar machen |
| Komplexe historische Order | Varianten, Modifiers, Zahlung, Erstattung, Fulfillment und externe IDs sichtbar machen |
| CMS Collection mit Referenzen | Schema, Eltern-Kind-Verknüpfungen, Berechtigungen und dynamische Seiten sichtbar machen |
| Prioritäre Content-Route | Zuständigkeit für CMS, Blog, Medien, URL und Weiterleitung sichtbar machen |
| App-eigener oder externer Datensatz | Fortbestehende Anwendung und stabile Elternkennungen sichtbar machen |
Halten Sie für jede Stichprobe Quell-ID, gegebenenfalls Quell-URL, geschäftlichen Grund, vorgesehenen Wix-Eigentümer, bekannte Ausschlüsse, externe Schlüssel und verantwortlichen Prüfer fest.
Wix-Bereitschaftsprüfung abschließen
| Bereitschaftsfrage | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Sind Zugriff und Quellarchive wiederherstellbar? | Zugriffsprotokoll und datierte Exporte/Backups | Erforderliche Datensätze können unabhängig vom Live-Quellsystem geprüft werden |
| Ist das Wix-Betriebsmodell definiert? | Zuständigkeitsmodell für Site, Stores, Contacts, Members, CMS und Apps | Jede wichtige Datensatzfamilie besitzt genau einen vorgesehenen Eigentümer |
| Sind Product- und Bestandsstrukturen vorbereitet? | Product-/Varianten-/Modifier- und Varianten-Location-Matrizen | Für jedes wichtige verkaufsfähige Muster ist eine Darstellung definiert |
| Sind Identitätsbeziehungen vorbereitet? | Contact-/Member-/Customer-Klassifizierung und Matching-Regeln | IDs, Einwilligung, Zugriff und App-Beziehungen sind dokumentiert |
| Sind Orders- und Content-Nachweise vollständig? | Historisches Order-Paket und Content-/URL-Register | Transaktionen und Routen lassen sich anhand von Quellnachweisen erklären |
| Sind Apps und externe Systeme inventarisiert? | Abhängigkeitsregister | Jede kritische Abhängigkeit besitzt einen fortbestehenden Eigentümer |
| Sind repräsentative Migrationsstichproben ausgewählt? | Stichprobenregister | Katalog-, Bestands-, Identitäts-, Order-, CMS- und Integrationskomplexität ist abgedeckt |
| Sind offene Punkte kontrolliert? | Entscheidungsprotokoll | Jeder offene Punkt hat einen Owner und ein Fälligkeitsdatum |
Die Prüfung ist abgeschlossen, wenn keine kritische Product-, Bestands-, Contact-, Member-, Order-, CMS-, URL-, App- oder externe Systementscheidung von einer undokumentierten Annahme abhängt.
Fazit
Die Vorbereitung auf Wix sollte ein Site-and-Commerce-Nachweispaket erzeugen, das Wix Stores, Contacts, Members, CMS, Blog, Anwendungen und externe Systeme klar voneinander trennt. Products müssen mit ihren tatsächlichen Varianten und Modifiers verbunden sein, Bestand muss Variante und Location korrekt zugeordnet werden, Identitätsdatensätze müssen ihre unterschiedlichen Rollen behalten und CMS- oder App-Daten müssen benannte Eigentümer besitzen.
Sind diese Entscheidungen vor dem repräsentativen Migrationstest dokumentiert, kann der Stichprobensatz die vorgesehene Wix-Architektur sichtbar machen, ohne Site-Design, Account-Zugriff oder aktive Konfiguration fälschlich als Migrationsdaten zu behandeln.
Häufige Fragen
Was sollte für eine Wix-Migration zuerst vorbereitet werden?
Beginnen Sie mit dem Wix-Zuständigkeitsmodell. Definieren Sie, welche Datensätze Wix Stores, Contacts, Members, CMS, Blog, anderen Wix-Apps und externen Systemen gehören, bevor detaillierte Exporte vorbereitet werden.
Warum müssen Wix-Product-Optionen und Modifiers getrennt vorbereitet werden?
Optionen erzeugen Varianten, Modifiers erfassen dagegen zusätzliche Informationen, ohne Varianten zu erzeugen. Werden beide vermischt, können falsche SKUs entstehen oder vom Käufer eingegebene Werte aus historischen Order-Positionen verloren gehen.
Wie sollte Multi-Location-Bestand vorbereitet werden?
Erstellen Sie eine Varianten-Location-Matrix mit Quellmengen, Tracking-Methoden, Preorder-Regeln, Location-IDs und dem zukünftigen System of Record. Reduzieren Sie die Daten nur dann auf eine einzelne Menge des übergeordneten Products, wenn die Zusammenführung bewusst vorgesehen ist.
Sind Wix Contacts und Members derselbe Datensatz?
Nein. Members sind typischerweise mit Contacts verknüpft, aber Member-ID und Contact-ID sind eigenständig und die Datensätze erfüllen unterschiedliche Aufgaben für Konto, Profil, Privatsphäre und CRM.
Was sollte für Wix CMS Collections vorbereitet werden?
Dokumentieren Sie Zweck, Schema, Felder, Referenzen, Berechtigungen, Indizes, repräsentative Items, dynamische Seiten, externe Datenbankverbindungen und den fortbestehenden Eigentümer jeder Collection.
Wann ist die Wix-Vorbereitung abgeschlossen?
Sie ist abgeschlossen, wenn Zugriff, Products, Bestands-Locations, Contacts, Members, Orders, Inhalte, CMS Collections, Routen, Apps, externe Systeme, Stichproben und offene Entscheidungen jeweils verantwortliche Owner und wiederherstellbare Nachweise besitzen.