Wenn Wix als mögliche Zielplattform für die Daten und Geschäftsbeziehungen des Quellshops bewertet wird, ist die Bedeutung der Beziehungen wichtiger als die bloße Ähnlichkeit einzelner Felder. Wix verbindet Website-Erstellung, Commerce, CRM, CMS, Marketing und Anwendungsdaten innerhalb einer Site. Ein Product aus dem Quellshop kann zu einem Wix-Stores-Product mit Optionen, Auswahlwerten, Varianten, Medien, Categories, Markenbeziehungen und Beständen werden. Eine Person kann als Contact, Site Member, mit Orders verknüpfter Customer oder Teilnehmer einer anderen Wix-Business-Anwendung existieren. Ein CMS-Datensatz aus dem Quellsystem kann in eine Wix CMS Collection gehören, während ein Product, Blog Post, Booking, Event oder App-Datensatz einem anderen Wix-Datenverantwortlichen zugeordnet ist.
Wix besitzt außerdem eine aktive Grenze zwischen Katalogversionen. Eine Wix-Site kann Catalog V1 oder Catalog V3 verwenden, aber nicht beide gleichzeitig. Catalog V3 führt universelle Varianten, wiederverwendbare Customizations, separate Inventory Items je Variante und Location, hierarchische Categories, Brands, wiederverwendbare Info Sections und weitere Katalogentitäten ein. Die auf der Ziel-Site aktive Katalogversion ist deshalb Teil des Datenmodells und keine nebensächliche technische Einzelheit.
Die zentrale Aufgabe bei der Übertragung besteht darin, die Eltern-Kind- und systemübergreifenden Beziehungen hinter den Daten zu erhalten. Die Product-Identität muss mit der richtigen Variante, Category, dem richtigen Bestandsdatensatz, der Location, den Medien und externen Schlüsseln verbunden bleiben. Contact-Identität muss von Member-Zugriff und Marketingeinwilligung getrennt bleiben. Orders sollen Transaktionsnachweise erhalten, ohne zur Konfiguration des zukünftigen Checkouts zu werden. CMS Collections und App-Daten benötigen einen ausdrücklich definierten Eigentümer, statt in generische Seiteninhalte abgeflacht zu werden.
Die Wix-Katalogversion bestimmt die Datenzuständigkeit
Catalog V1 und Catalog V3 stellen nicht exakt dieselbe Datensatzstruktur bereit. Eine Site verwendet jeweils nur eine Katalogversion, daher muss die Übertragung dem Modell folgen, das auf der Ziel-Site aktiv ist. Catalog V3 ist um klarer getrennte Services für Products, Varianten, Inventory Items, Locations, Categories, Brands, Ribbons, Info Sections und wiederverwendbare Customizations aufgebaut.
Catalog V3 verwendet zudem universelle Varianten: Jedes Product besitzt mindestens eine Variante, einschließlich einer Standardvariante für Products ohne sichtbare Optionen. In diesem Modell können Preis, SKU, Bestand und weitere verkaufsrelevante Details auf Variantenebene verstanden werden, auch wenn Käufer lediglich ein einfaches Product sehen.
| Annahme im Quellshop | Bedeutung im Wix-Katalog | Folge für die Übertragung |
|---|---|---|
| Ein Product ohne Optionen hat keine Variante | Catalog V3 bildet trotzdem eine Standardvariante ab | Product- und verkaufsfähige Identität bleiben verbunden, auch wenn keine Auswahl sichtbar ist. |
| Jede Option ist nur beschreibendes Product-Datum | Optionen erzeugen Varianten; Modifiers erfassen Individualisierung, ohne Varianten zu erzeugen | Bestandsführende Auswahlwerte von Käufereingaben und optionaler Individualisierung trennen. |
| Eine Bestandsmenge gehört zum Product | Catalog-V3-Inventory-Items verbinden eine Variante mit einer Location | Hinter jeder Menge sowohl die verkaufsfähige Variante als auch den Location-Kontext erhalten. |
| Eine Collection entspricht einem Category-Baum | Katalogversion und Category-Modell von Wix bestimmen die Product-Organisation | Quellhierarchie auf die von der Ziel-Site unterstützten Category-Beziehungen abbilden. |
| Wix-Stores-Daten und Wix-CMS-Daten sind austauschbar | Wix-Stores-Katalogentitäten und Wix-CMS-Collection-Items haben unterschiedliche Eigentümer | CMS nur für Datensätze verwenden, die tatsächlich zu CMS Collections oder externen Datenstrukturen gehören. |
Eine Migration sollte deshalb nicht voraussetzen, dass eine für eine Wix-Katalogversion erstellte Feldzuordnung unverändert für eine andere gilt. Auch externe Integrationen benötigen die richtigen Entitäts-IDs und die richtige Kataloggranularität. Ein ERP, das Varianten kennt, kann nicht zuverlässig allein über eine übergeordnete Product-ID angebunden werden, wenn Catalog V3 Bestände je Variante und Location verwaltet.
Products, universelle Varianten, Optionen, Auswahlwerte und Modifiers
Ein Wix Product ist der übergeordnete Katalogdatensatz. In Catalog V3 hat jedes Product mindestens eine Variante. Products mit Optionen können Varianten aus Kombinationen ihrer Auswahlwerte erzeugen. Jede Variante kann eigene Bedeutungen für SKU, Preis, Medien und Bestand tragen. Customizations unterscheiden Optionen, die Varianten erzeugen, von Modifiers, die zusätzliche Käufereingaben erfassen, ohne Varianten- oder Bestandsidentität zu verändern.
Diese Unterscheidung ist für die Migration konfigurierbarer Products zentral. Eine Größe oder Farbe aus dem Quellshop, die SKU oder Bestand verändert, gehört gewöhnlich zu Options- und Variantendaten. Ein Gravurfeld, eine Geschenknachricht oder eine optionale Personalisierung ähnelt dagegen einem Modifier. Eine Quellanwendung kann beides in einem einzigen Konfigurator zusammenführen; bei der Migration muss deshalb die resultierende verkaufsfähige Identität von den Anweisungen getrennt werden, die der Käufer eingibt.
| Quellkonfiguration | Wix-Eigentümer | Bedeutung, die erhalten bleiben muss |
|---|---|---|
| Einfaches Product mit einer SKU | Product plus Standardvariante | Product-Inhalte auf Elternebene; verkaufsfähige SKU-, Preis- und Bestandsidentität auf Variantenebene. |
| Größen-/Farbkombinationen | Optionen, Auswahlwerte und Varianten | Jede kaufbare Kombination bleibt mit den richtigen Auswahlwerten, SKU, Preis, Medien und Bestand verbunden. |
| Gravurtext oder Geschenknachricht | Modifier oder App-eigenes Individualisierungsergebnis | Die Käufereingabe bleibt mit der gekauften Order-Position verbunden, ohne falsche Bestandsvarianten zu erzeugen. |
| Optionales Upgrade | Je nach Bestands- und Preisbedeutung Modifier, separates Product oder Variante | Der Eigentümer auf der Zielseite richtet sich danach, ob das Upgrade einen eigenständigen verkaufsfähigen Artikel bildet. |
| Bundle oder Kit | Product-Beziehung, App-eigenes Bundle oder externe Bestandsstruktur | Komponenten, Bestandsautorität, Preisbildung und resultierende Order-Positionsdaten bleiben nachvollziehbar. |
| Subscription-, Booking-, Event- oder Service-Angebot | Je nach Verhalten Wix-Stores-Product oder eine andere Wix-Business-Anwendung | Katalogidentität bleibt von wiederkehrender Abrechnung, Terminplanung, Teilnahme oder Berechtigung getrennt. |
Catalog-V3-Customizations können über mehrere Products hinweg wiederverwendet werden. Dadurch entsteht eine weitere Beziehungsgrenze: Die Customization-Definition kann gemeinsam genutzt werden, während die Product-Zuweisung und das daraus entstehende Varianten- oder Modifier-Verhalten Product-spezifisch bleiben. Das Löschen oder Ändern einer gemeinsamen Definition kann mehrere Products betreffen. Option-Templates aus dem Quellsystem sollten deshalb nur dann als wiederverwendbare Entitäten übertragen werden, wenn sie tatsächlich dieselbe geschäftliche Bedeutung teilen.
Auch Product-Medien benötigen eine klare Zuständigkeit. Medien auf Product-Elternebene können das gesamte Angebot beschreiben, während ein Bild für einen Auswahlwert oder eine Variante eine konkrete Kombination identifiziert. Werden alle Bilder in eine undifferenzierte Galerie verschoben, bleiben zwar die Dateien erhalten, aber die Beziehung kann verloren gehen, durch die Käufer die ausgewählte Variante erkennen.
Categories, Brands, Info Sections, Ribbons und Produktentdeckung
Die Katalogorganisation in Wix kann hierarchische Categories, Product-Zuweisungen, Brands, Ribbons, wiederverwendbare Info Sections, Suche, Site-Navigation und Seitendarstellung umfassen. Diese Datensätze erfüllen unterschiedliche Aufgaben.
Catalog-V3-Categories können Eltern-Kind-Bäume bilden und die Zuweisung eines Products zu mehreren Categories unterstützen, einschließlich einer Beziehung zur Haupt-Category. Brands bilden Hersteller- oder Markenidentität ab. Info Sections stellen wiederverwendbare umfangreiche Product-Informationen wie technische Angaben, Größentabellen, Pflegehinweise oder Garantiedetails bereit. Ribbons dienen als Werbe- oder Merchandising-Kennzeichnungen. Site-Seiten und Menüs bestimmen die öffentliche Navigation und Darstellung.
| Quellkonzept | Eigentümer im Wix-Zielmodell | Folge für die Übertragung |
|---|---|---|
| Dauerhafte Abteilungshierarchie | Category-Baum und Product-Category-Beziehungen | Dauerhafte Bedeutung für Browsing und Klassifizierung erhalten. |
| Hersteller oder Marke | Brand-Entität und Product-Zuweisung | Markenidentität getrennt von Categories und beschreibenden Spezifikationen halten. |
| Technische Spezifikationen | Je nach Wiederverwendung und Zuständigkeit Product-Felder, Info Sections, CMS-Daten oder externes PIM | Beschreibende Attribute nicht zu Varianten machen, sofern sie keine kaufbaren Kombinationen erzeugen. |
| Von mehreren Products genutzte Größentabelle oder Pflegeanleitung | Wiederverwendbare Info Section | Einen gemeinsamen Content-Eigentümer und die Product-Referenzen erhalten. |
| Sale-, New- oder Featured-Kennzeichnung | Ribbon oder Merchandising-Darstellung | Werbestatus von dauerhafter Product-Klassifizierung trennen. |
| Saisonale Collection | Je nach Zweck Category, Landing Page, Ribbon, Kampagne oder kuratierte Darstellung | Kampagnenbedeutung erhalten, ohne daraus einen dauerhaften Product-Typ zu machen. |
| Menüeintrag | Site-Navigationsbeziehung zu Category, Product-Seite, CMS Page oder externer URL | Navigation wird nicht zum Eigentümer der Product-Klassifizierung. |
Derselbe Quellwert kann je nach Verwendung unterschiedliche Eigentümer benötigen. „Organic“ könnte eine durchsuchbare Spezifikation, eine Product-Kennzeichnung, eine Category oder ein Zertifizierungsfeld aus einem externen PIM sein. Die Übertragung sollte dem Workflow folgen, der den Wert verwendet, und nicht lediglich der Bezeichnung im Quellsystem.
Varianten- und Location-Beziehungen bestimmen die Bestandsbedeutung
Catalog-V3-Inventory-Items repräsentieren eine bestimmte Variante an einer bestimmten Location. Der Bestandsdatensatz kann Menge, Verfügbarkeit, Preorder-Verhalten und weitere Bestandsbedeutung für diese Varianten-Location-Kombination führen. Jeder Shop besitzt zudem eine Standard-Location; zusätzliche Locations können Lagerhäuser, Filialen oder Fulfillment-Standorte darstellen.
Eine Quellplattform kann eine Menge je Product, eine Menge je Variante oder getrennte Mengen nach Lager und Verkaufskanal speichern. Diese Modelle sind nicht gleichwertig.
| Bestandsmuster im Quellsystem | Beziehung im Wix-Zielmodell |
|---|---|
| Eine Product-Menge ohne sichtbare Optionen | Standardvariante → vorgesehene Bestands-Location → Inventory Item. |
| Bestand auf Variantenebene | Jede verkaufsfähige Quellkombination → Wix-Variante → Inventory Item je Location. |
| Lagerspezifischer Bestand | Quelllager/-filiale → Wix-Location oder externer Lager-Eigentümer → Varianten-Location-Menge. |
| Unbegrenzte oder auf Bestellung gefertigte Verfügbarkeit | Variantenverfügbarkeit und Bedeutung der Bestandsführung statt einer willkürlich großen Menge. |
| Preorder-Bestand | Varianten-Location-Inventory-Item plus Preorder-Regeln, sofern die Zielplattform dieses Verhalten unterstützt. |
| Externe Bestandsautorität | Wix-Varianten-/Location-IDs plus ERP- oder Lagerschlüssel für die laufende Synchronisation. |
| Marketplace-Zuteilung | Variante → Kanal-/externe Listing-Beziehung → Bestandsverantwortlicher statt unkontrolliert duplizierter Mengen. |
In Catalog V3 sind die Erstellung eines Products und die Erstellung eines Inventory Items getrennte Vorgänge, sofern kein kombinierter Erstellungsablauf verwendet wird. Diese Trennung unterstreicht das Zuständigkeitsmodell: Ein Product kann ohne vollständigen Bestandsdatensatz existieren, und Bestand lässt sich ohne die Variante und Location, denen er gehört, nicht sinnvoll verstehen.
Wenn ein ERP oder Lagerverwaltungssystem weiterhin die maßgebliche Bestandsquelle bleibt, ist die anfängliche Bestandsmenge weniger dauerhaft als die Kennungen, die zukünftige Aktualisierungen korrekt zuordnen. Eine externe ID auf Product-Ebene reicht nicht aus, wenn das externe System jede Varianten-Location-Kombination separat speichert.
Contacts, Members, Customers und Marketingbeziehungen
Wix-CRM-Contacts und Site Members repräsentieren unterschiedliche Beziehungen. Ein Contact ist ein Personen- oder Organisationsdatensatz, der in CRM, Kommunikation, Orders und Business-Anwendungen verwendet wird. Ein Member ist ein Site-Benutzer mit Authentifizierung und möglicherweise Profil-, Rollen-, Berechtigungs- oder zugangsbeschränkten Content-Beziehungen. Ein Commerce-Customer kann mit einem Contact und Orders verbunden sein, ohne jedes Kontoverhalten des Quellshops zu reproduzieren.
Ein Customer-Konto im Quellshop kann Adressen, Order-Historie, Passwörter, Unternehmensrollen, Kundengruppen, Steuerbefreiungen, Loyalty-Punkte, Memberships, Subscriptions, Einwilligungen und anwendungsspezifische Attribute enthalten. Diese Werte sollten der Wix-Entität oder dem externen System zugewiesen werden, das ihre fortlaufende Nutzung verantwortet.
| Identitätsmuster im Quellsystem | Beziehungsentscheidung in Wix |
|---|---|
| Registrierter Endkunde | Contact-/Customer-Identität verbunden mit Adressen und Orders; Member-Beziehung nur, wenn Site-Zugriff vorgesehen ist. |
| Gastkäufer | Mit der Order verbundener Contact-Kontext, ohne ein Member-Konto zu erfinden. |
| Reiner Newsletter-Abonnent | Contact plus Kommunikations-Einwilligung/-Subscription, nicht automatisch Customer oder Member. |
| Site-Community- oder zugangsbeschränkter Content-Nutzer | Member plus Contact-Beziehung und relevante Rollen-, Berechtigungs- oder Zugriffsverantwortung. |
| B2B-Unternehmenskontakt | Contact plus Company-/CRM-/externe Kontobeziehung; nicht automatisch eine vollständige Organisationshierarchie. |
| Loyalty-Teilnehmer | Contact/Customer plus Wix- oder externes Loyalty-Ledger, das Punkte und Status verwaltet. |
| Doppelte Quellkonten | Nur zusammenführen, wenn E-Mail, Telefon, externe IDs, Adressen, Einwilligungen und Order-Zuordnung eine gemeinsame Identität stützen. |
Passwörter und Authentifizierungsstatus sollten nicht wie gewöhnliche Profilfelder behandelt werden. Selbst wenn ein Source Customer zu einem Wix Member wird, besitzen Anmeldedaten, Einladungsstatus, Rollen und Berechtigungen eigene Sicherheits- und Lebenszyklusbedeutung.
Auch Marketingeinwilligung bleibt unabhängig von der Kaufhistorie. Ein Contact, der einmal gekauft hat, ist nicht automatisch Subscriber, und ein Subscriber muss nie gekauft haben. Die Einwilligung bleibt nur korrekt erhalten, wenn die Kommunikationsbeziehung vom Contact-Datensatz selbst getrennt wird.
Orders erhalten Commerce-Historie und Anwendungskontext
Wix-eCommerce-Orders verwalten den Lebenszyklus nach dem Kauf. Eine Order kann gekaufte Positionen, Zahlungsdetails, Rechnungs- und Versandinformationen, Rabatte, Steuern, Liefer- oder Abholdaten, Fulfillment-Status, Rückerstattungen, Rechnungen und externe Referenzen enthalten. Draft Orders, Billing-Datensätze, Transactions, Invoices und Fulfillments besitzen verwandte, aber eigenständige Zuständigkeiten.
Die Product- oder Variantenposition in einer historischen Order ist eine Momentaufnahme der Transaktion. Sie sollte erhalten, was gekauft wurde, einschließlich ausgewählter Optionen oder Customizations, selbst wenn sich der aktuelle Katalog später ändert. Aktuelle Zahlungs-, Steuer-, Versand-, Benachrichtigungs-, Rechnungs- und Bestandseinstellungen bleiben Konfiguration für zukünftige Orders.
| Historischer Wert | Bedeutung in einer Wix Order |
|---|---|
| Order-Nummer des Quellsystems | Externe Referenz für Kundenservice und Abstimmung. |
| Product-/Variantenposition | Gekaufter Titel, Variante, SKU, Menge, Preis und ausgewählte Werte. |
| Modifier- oder Personalisierungsergebnis | Vom Käufer eingegebener oder von einer Anwendung erzeugter Wert, der mit der richtigen Order-Position verbunden bleibt. |
| Rabatt, Steuer und Lieferkosten | Erklärung der historischen Gesamtsumme und keine aktuelle Regelkonfiguration. |
| Zahlungs- und Erstattungsdaten | Finanzhistorie, die mit Order und verantwortlicher Transaction verbunden ist. |
| Versand, Lieferung, Abholung oder Service-Fulfillment | Historischer Fulfillment-Status und Tracking-Kontext. |
| Rechnungs- oder Buchhaltungsreferenz | Order-/Invoice-Beziehung plus externe Buchhaltungskennung. |
| Verkaufskanal- oder App-Referenz | Order-Herkunft und Zuständigkeit der externen Anwendung. |
Wix Orders können von mehreren Wix-Business-Lösungen und Integrationen erzeugt werden und nicht nur durch Wix Stores. Ein migrierter Quelldatensatz sollte deshalb erhalten, welche Anwendung oder welcher Kanal die Transaktion erzeugt hat, wenn diese Unterscheidung Reporting, Fulfillment oder Kundenservice beeinflusst.
Historische Orders sollten außerdem keine künstlichen aktuellen Products erzeugen. Eine Order-Position für ein eingestelltes Product, einen einmaligen Service oder eine App-erzeugte Gebühr kann als Momentaufnahme verständlich bleiben, ohne ein neues Product im aktiven Katalog anzulegen.
Wix CMS Collections, Data Items, Referenzen und externe Daten
Wix CMS speichert Data Items innerhalb von Collections. Data Items können typisierte Felder und Referenzen auf andere Items enthalten. Wix unterstützt zudem Verbindungen zu externen Datenbanken, die externe Collections über Wix-Datenschnittstellen verfügbar machen. Dadurch eignet sich CMS für strukturierte Inhalte, Verzeichnisse, individuelle Kataloge, Ressourcenbibliotheken und Anwendungsdaten. CMS ersetzt jedoch nicht Wix Stores, Contacts, Orders, Blog, Bookings, Events oder andere spezialisierte Eigentümer.
Eine Custom Table aus dem Quellsystem sollte nur dann zu einer Wix CMS Collection werden, wenn der Geschäftsdatensatz tatsächlich zu einem Content- oder individuellen Datenmodell gehört. Ein Product, das an Wix-Stores-Checkout, Varianten, Bestand und Orders teilnehmen muss, sollte ein Wix-Stores-Product bleiben. Ein Blog Post sollte Blog-Inhalt bleiben, wenn Veröffentlichungsverhalten relevant ist. Ein Booking sollte mit dem Booking-System verbunden bleiben, das Verfügbarkeit und Teilnahme verwaltet.
| Quelldatensatz | Eigentümer im Wix-Zielmodell |
|---|---|
| Bibliothek mit Product-Spezifikationen | Je nach Wiederverwendung und Autorität Info Sections, Product-Felder, CMS Collection oder externes PIM. |
| Redaktionelle Ressource oder Verzeichnis | CMS Collection und Data Items mit expliziten Referenzen und Beziehungen zu dynamischen Seiten. |
| Blog-Artikel | Wix Blog Post mit Veröffentlichungs-, Autoren-, Category-/Tag-, Medien- und URL-Bedeutung. |
| Individueller Product-Katalog ohne direkten Verkauf | CMS- oder externe Datenbank-Collection; Wix Stores nur, wenn Commerce-Verhalten erforderlich ist. |
| Event-, Booking-, Kurs- oder Membership-Datensatz | Relevante Wix-Business-Anwendung plus Contact-/Member- und Transaktionsbeziehungen. |
| Zeile einer externen Datenbank | Externe Collection-Beziehung mit stabilen IDs und Referenzfeldern. |
| Page-Builder-Inhalt | Site-Seiten-/Abschnittsdarstellung, die mit CMS- oder Commerce-Datensätzen verbunden ist und nicht selbst die maßgebliche Datenquelle darstellt. |
CMS-Referenzfelder erhalten Beziehungen zwischen Datensätzen, etwa wenn eine Ressource mit einem Autor, einer Category, einem Product oder einer Location verbunden ist. Werden diese Beziehungen in kopierten Text abgeflacht, können Datensätze nicht mehr unabhängig voneinander aktualisiert und abgefragt werden.
Site-Seiten, URLs, Medien, mehrsprachige Daten und SEO
Wix-Site-Inhalte können Seiten, dynamische Seiten, Blog Posts, CMS-gesteuerte Inhalte, Medien, Menüs, Product-Seiten, Category-Seiten, Weiterleitungen, SEO-Felder, Domains und mehrsprachige Varianten umfassen. Diese Datensätze bestimmen, wie Katalog- und Content-Daten dargestellt und gefunden werden, ersetzen aber nicht das zugrunde liegende Product, CMS Item, den Contact oder die Order.
Ein Page-Builder-Layout im Quellsystem kann Product-Referenzen, Text, Bilder, Formulare und Anwendungs-Widgets kombinieren. Das Zielmodell sollte wiederverwendbare Inhalte und Geschäftsdaten von dem visuellen Abschnitt trennen, der sie darstellt.
| Web-Asset im Quellsystem | Zuständigkeitsbeziehung in Wix |
|---|---|
| Product-Titel, Beschreibung, Medien, URL und SEO-Daten | Wix-Stores-Product und Darstellung auf der Product-Seite. |
| Category-Landing-Page | Category plus Seiten-/Navigationsbeziehung und unterstützende Inhalte. |
| CMS Page oder dynamische Content-Seite | Site-Seite/dynamische Seite plus CMS Collection und Data-Item-Referenzen. |
| Blog Post | Wix-Blog-Datensatz mit Autor, Veröffentlichung, Category/Tag, Medien und Routenbedeutung. |
| Menüeintrag | Navigationsbeziehung zu Seite, Category, Product, dynamischer Seite, Anker oder externer URL. |
| Mehrsprachiger Inhalt | Sprachspezifische Site-/Content-/Product-Felder und Referenzen statt duplizierter, unabhängiger Datensätze, sofern keine bewusste Trennung vorgesehen ist. |
| Quell-URL | Zielroute plus Weiterleitungsbeziehung, wenn sich der Pfad ändert. |
| Theme- oder Editor-Komponente | Darstellungskonfiguration mit Referenzen auf maßgebliche Content- oder Commerce-Entitäten. |
Die alte URL sollte auf einen bekannten Zieldatensatz zeigen. Eine Weiterleitung ist eine Beziehung zwischen Routen und kein Ersatz dafür, zu definieren, welches Wix Product, welche Category, Seite, welcher Blog Post oder welches dynamische Item das Quell-Asset ersetzt. Interne Links und Medienreferenzen sollten ebenfalls ihr vorgesehenes Ziel behalten, statt veraltete Quellpfade zu konservieren.
Apps, Velo, Service-Plugins und Zuständigkeit externer Systeme
Wix-Anwendungen, Velo-Code, Service-Plugins, Automatisierungen, Webhooks, externe Datenbanken und Drittsysteme können Daten besitzen, die nicht nativ zum Wix-Stores-Katalog gehören. Reviews, Subscriptions, Loyalty, Marketplaces, Buchhaltung, Fulfillment, erweiterte Suche, Product Feeds, CRM und individuelle Konfiguratoren können jeweils eigene Datensätze und Kennungen einführen.
Eine Zielanwendung mit ähnlicher Funktion beweist nicht, dass Quelldaten aus der entsprechenden Anwendung direkt abgebildet werden können. Die verantwortliche Entität, das Datenschema, Beziehungsschlüssel und der Lebenszyklus müssen verstanden werden.
| Individuelles oder externes Signal | Eigentümer im Zielmodell |
|---|---|
| ERP-Product- oder Varianten-ID | Product/Variante plus ERP-Beziehung auf der vom externen System erkannten Kataloggranularität. |
| Lagerschlüssel für Bestand | Varianten-Location-Inventory-Item plus Lagersystem. |
| CRM-Contact- oder Company-ID | Contact plus externe CRM-/Company-Beziehung. |
| Marketplace-Listing-ID | Product-/Varianten-/Kanalbeziehung und kein generisches Product-Feld. |
| Review-, Loyalty- oder Subscription-Datensatz | Wix-App oder externes System plus Referenzen auf Product, Contact, Member oder Order. |
| Zustand eines individuellen Konfigurators | App-/Velo-/CMS-Eigentümer plus Product/Variante und resultierende Order-Positionsausgabe. |
| Externer Datenbankdatensatz | Externe Collection plus Wix-Referenzfelder und dauerhafter Schlüssel des Fremdsystems. |
| Webhook- oder Service-Plugin-Einstellung | Zielkonfiguration, die Systeme verbindet, und kein Customer- oder Product-Datensatz. |
Dieses Zuständigkeitsmodell verhindert, dass unbrauchbare individuelle Daten lediglich erhalten werden. Ein Wert ist nur dann dauerhaft nutzbar, wenn Teams seinen Elterndatensatz, das maßgebliche System, seinen Lebenszyklus und den Verbraucher kennen. Generische Custom Fields ersetzen keine klar definierte Product-zu-App-, Contact-zu-CRM-, Order-zu-Marketplace- oder CMS-zu-externer-Datenbank-Beziehung.
Repräsentative Übertragungsketten für Wix
Beziehungsketten machen die Bedeutung auf der Zielplattform explizit, indem sie Elterndatensatz, abhängige Datensätze und gegebenenfalls den externen Eigentümer zeigen. Bei Wix sind sie besonders nützlich, weil Commerce, CRM, Members, CMS und Anwendungen gleichzeitig Daten zu demselben Geschäftsvorgang halten können. Eine vollständige Kette zeigt, welche Wix-Entität maßgeblich ist und welche Datensätze diese Daten lediglich referenzieren oder darstellen.
| Quellmuster | Beziehung im Wix-Zielmodell |
|---|---|
| Bekleidungs-Product mit Größen-/Farbbestand | Katalogversion → Product → Optionen/Auswahlwerte → Varianten → Variantenmedien/SKU → Inventory Items je Location. |
| Personalisiertes Geschenk | Product/Variante → Modifier oder App-eigene Eingabe → Individualisierung der Order-Position → Fulfillment-Referenz. |
| Bestand an mehreren Locations | Variante → Wix-Location → Inventory Item → externer Lagerschlüssel, wenn ein anderes System maßgeblich bleibt. |
| Customer mit zusätzlichem Zugriff auf geschützte Inhalte | Contact/Customer → Orders und Adressen; Member → Authentifizierung/Rolle/Zugriff; Einwilligung bleibt eine separate Kommunikationsbeziehung. |
| CMS-gesteuerte Ressource mit Product-Verknüpfung | CMS Collection → Data Items/Referenzfelder → Wix-Stores-Product-IDs → dynamische Seite/Navigation. |
| Marketplace-Verkauf | Order → Quell-/Kanalreferenz → Momentaufnahme von Product/Variante in der Position → Transaction-/Fulfillment-Historie → externe Marketplace-ID. |
| SEO-sensitive Category | Category-Baum/Product-Mitgliedschaft → Site-Seite oder Category-Route → Navigation → Ziel-URL → Weiterleitung von der Quell-URL. |
Diese Ketten erhalten die Wix-spezifische Zuständigkeit und berücksichtigen zugleich, dass eine Quellplattform Commerce-, Content-, Identitäts- und Anwendungsdaten in einem einzigen Datensatz oder einer Tabelle kombiniert haben kann.
Fazit
Die Übertragung in das Wix-Datenmodell beginnt mit der Katalogversion der Ziel-Site und reicht über Wix Stores, Bestands-Locations, CRM Contacts, Site Members, eCommerce Orders, CMS Collections, Seiten, Blog-Inhalte, Apps, Velo und externe Systeme. Diese Datensatzfamilien sind miteinander verbunden, aber nicht austauschbar.
Ein belastbares Wix-Zielmodell ordnet jeden Quellwert dem Product, der Variante, Customization, Category, Location, dem Inventory Item, Contact, Member, der Order, dem CMS Item, Content-Datensatz, der Anwendung oder dem externen System zu, das seine fortbestehende Bedeutung verantwortet. So bleiben Commerce- und Content-Beziehungen erhalten, ohne historische Daten mit zukünftiger Konfiguration zu verwechseln oder spezialisierte Anwendungsdaten in generische Felder zu pressen.
Häufige Fragen
Warum ist die Wix-Katalogversion für die Migration wichtig?
Eine Wix-Site verwendet entweder Catalog V1 oder Catalog V3, und die Entitätsbeziehungen unterscheiden sich. Catalog V3 arbeitet mit universellen Varianten und separaten Services für Bestand je Variante und Location, Categories, Brands, Customizations, Info Sections und weitere Katalogdatensätze.
Sind Wix-Product-Optionen und Modifiers dasselbe?
Nein. Optionen und Auswahlwerte erzeugen Varianten, die SKU-, Preis-, Medien- und Bestandsbedeutung tragen können. Modifiers erfassen Personalisierung oder optionale Eingaben, ohne eine separate Varianten- oder Bestandsidentität zu erzeugen.
Kann jeder Wix Contact zu einem Site Member werden?
Nein. Ein Contact ist ein CRM- und Geschäftsbeziehungsdatensatz. Ein Member besitzt Authentifizierung und gegebenenfalls Profil-, Rollen-, Berechtigungs- oder zugangsbeschränkte Bedeutung. Ein Käufer kann Contact/Customer bleiben, ohne ein Member-Konto zu erhalten.
Konfigurieren migrierte Wix Orders das zukünftige Checkout-Verhalten?
Nein. Orders erhalten gekaufte Positionen, Auswahlwerte, Zahlungs-/Erstattungshistorie, Adressen, Fulfillment, Rechnungen und externe Referenzen. Aktuelles Zahlungs-, Steuer-, Versand-, Benachrichtigungs- und Bestandsverhalten bleibt separate Konfiguration.
Wann sollten individuelle Quelldaten zu einer Wix CMS Collection werden?
CMS eignet sich, wenn die Daten zu einem strukturierten Content- oder individuellen Datensatzmodell gehören, das von Feldern, Referenzen, Abfragen und dynamischen Seiten profitiert. Products, Orders, Contacts, Blog Posts, Bookings, Events und andere spezialisierte Datensätze sollten bei ihren nativen Wix-Eigentümern bleiben, wenn deren Verhalten benötigt wird.
Wie sollten Wix-App-Daten und Daten externer Systeme abgebildet werden?
Der Wert sollte mit seinem übergeordneten Product, seiner Variante, dem Contact, Member, der Order, dem CMS Item oder einem anderen Geschäftsdatenobjekt verbunden bleiben und die externe Kennung der verantwortlichen Anwendung behalten. Eine generische Notiz oder ein unstrukturiertes Feld erhält nicht die Beziehung, die für zukünftige Synchronisation erforderlich ist.