Wenn Wix als mögliche Zielplattform für die Daten, Beziehungen und geschäftliche Bedeutung des Quellshops bewertet wird, entstehen besondere Risiken aus dem Zusammenspiel von Commerce, Site Builder, CMS-Daten, Customer-Beziehungen, Members, Anwendungen und programmierbarem Verhalten innerhalb einer verwalteten Plattform. Migrationsrisiken entstehen, wenn Datenbanktabellen, Themes, Checkout-Skripte, Product-Erweiterungen oder Anwendungsdatensätze des Quellshops fälschlich als gewöhnliche Wix-Stores-Daten behandelt werden.
Die aktuelle Wix-Katalogarchitektur schafft eine weitere wichtige Grenze: Catalog V3 verwendet universelle Varianten, trennt Optionen von Modifiers und verwaltet Bestand je Variante und Location. Orders gehören zu einem breiteren eCommerce-Bereich mit getrennten Verantwortlichkeiten für Billing, Transactions, Invoices, Fulfillment und Settings. CMS Collections und Referenzfelder können individuelle Site-Anwendungen unterstützen, ersetzen aber nicht automatisch Product-, Customer-, Order- oder App-eigene Entitäten.
Jede Risikokette sollte deshalb Annahme, Wix-Einschränkung, Migrationsfolge, betriebliche Auswirkung, Gegenmaßnahme und Kontrollsignal ausdrücklich sichtbar machen.
Grenzen zwischen gehosteter Site, Commerce, CMS und Anwendungen
Wix stellt keine generische Zieldatenbank bereit, in die jede Quelltabelle kopiert werden kann. Daten müssen Wix Stores, eCommerce Orders, Contacts, Members, CMS Collections, einer Wix-Anwendung, Velo-Code, einem Service-Plugin oder einem externen System gehören. Site-Design und das Verhalten dynamischer Seiten bilden zusätzliche Ebenen.
| Annahme im Quellsystem | Wix-Einschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Quelltabellen können direkt reproduziert werden. | Wix verwendet definierte Business-Ressourcen, CMS-Schemas, Anwendungen und APIs. | Individuelle Datensätze werden in Felder abgeflacht oder dem falschen Bereich zugewiesen. | Mitarbeitende verlieren Workflow-Status, Reporting-Kontext oder externe Verknüpfungen. | Jede nicht standardmäßige Entität vor dem Mapping nach Eigentümer und Lebenszyklus klassifizieren. | Jeder benötigte Datensatz besitzt genau einen unterstützten Wix- oder externen Eigentümer. |
| Theme- und Page-Builder-Daten werden zusammen mit Datensätzen migriert. | Wix-Site-Seiten, Abschnitte, dynamische Seiten, Templates und mobile Darstellung sind Zielumsetzung. | Inhalte existieren ohne das Layout oder die Interaktionen, durch die sie nutzbar waren. | Wichtige Customer Journeys wirken unvollständig, obwohl Commerce-Daten vorhanden sind. | Dauerhafte Inhalte und Referenzen von der Darstellungsumsetzung trennen. | Jede wichtige Seite besitzt klare Zuständigkeit für Inhalt, Route und Verhalten. |
| Checkout-Skripte sind gewöhnliche Order-Felder. | Aktives Checkout-Verhalten hängt von Wix-Einstellungen, Erweiterungen, Service-Plugins, Apps und unterstützten Codepfaden ab. | Gebühren, Freigaberegeln, individuelle Eingaben oder Provider-Verhalten gehen verloren. | Neue Orders können erforderlichen Geschäftsregeln nicht folgen. | Historische Daten getrennt darstellen und zukünftiges Verhalten einem fortbestehenden Eigentümer zuweisen. | Die erforderliche Geschäftsregel hat einen ausdrücklich benannten Wix- oder externen Umsetzungsverantwortlichen. |
| App-Datensätze gehören zum Wix-Stores-Kern. | Bookings, Events, Restaurants, Pricing Plans, Loyalty, Subscriptions und weitere Apps besitzen eigene Entitäten. | Spezialisierte Datensätze werden in Contacts, Products oder Order-Notizen abgeflacht. | Zeitpläne, Berechtigungen, Guthaben oder Teilnehmerhistorie werden unbrauchbar. | Elternreferenzen erhalten und den spezialisierten Datensatz in seinen tatsächlichen Bereich übertragen. | Die fortbestehende Anwendung erkennt den vorgesehenen Contact, das Product und die Transaktion. |
Diese Grenze ist die Ursache vieler Wix-Risiken und sollte geklärt werden, bevor einzelne Felder als Migrationsumfang behandelt werden.
Risiko durch Catalog V1, Catalog V3 und Product-Abstammung
Wix Catalog V3 ist nicht lediglich ein neuer Endpunktname. Er verwendet universelle Varianten: Jedes Product besitzt mindestens eine Variante, auch ohne sichtbare Optionen. Optionen erzeugen Varianten und beeinflussen Bestand. Modifiers erfassen zusätzliche Informationen, ohne Varianten zu erzeugen. Inventory Items werden separat verwaltet und können eine Variante an einer Location repräsentieren.
Quellshops und ältere Wix-Integrationen können noch auf Annahmen aus Catalog V1 beruhen. Das Migrationsrisiko steigt, wenn alte oder fremde Datensätze abgebildet werden, ohne festzulegen, welche Kataloggeneration und Product-Granularität der Zielshop verwendet.
| Annahme | Katalogeinschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Ein Product ohne Optionen hat keine Variante. | Catalog V3 verwendet eine universelle Standardvariante. | Product-bezogene Kennungen und Bestand werden inkonsistent gegenüber variantengebundenen Systemen abgebildet. | Bestands- und Integrationsupdates finden die vorgesehene verkaufsfähige Einheit nicht. | Für jedes Product, einschließlich einfacher Products, eine Zielvariantenidentität definieren. | Jedes Product besitzt eine stabile verkaufsfähige Variante, die Integrationen erkennen. |
| Datensätze aus Catalog V1 und V3 sind austauschbar. | V3 verändert Grenzen für Product, Variante, Customization, Bestand und zugehörige Services. | IDs oder Beziehungen werden im falschen Modell wiederverwendet. | Katalogsynchronisation erzeugt Duplikate oder verpasst Variantenänderungen. | Quell-Kataloglinie und Zielentitätsmodell für V3 dokumentieren. | Jedes Quell-Product und jede Variante wird im Zielkatalog genau einmal aufgelöst. |
| Product-Erstellung erzeugt automatisch alle Bestandsbeziehungen. | Product- und Inventory-Item-Erstellung können getrennte Vorgänge sein. | Products existieren ohne die vorgesehenen verfolgten Bestandsdatensätze. | Artikel wirken verkaufsfähig, folgen aber nicht dem vorgesehenen Location-basierten Bestand. | Product-/Variantenidentität und Inventory Items als verbundene, aber getrennte Datensätze behandeln. | Jede verfolgte Variante besitzt die vorgesehene Location-Bestandsbeziehung. |
| Product-Daten einer alten App sind native Katalogdaten. | Apps können Products über eigene Entitäten erweitern oder referenzieren. | App-eigenes Verhalten wird als nicht erklärtes Product-Feld kopiert. | Mitarbeitende sehen Werte, die kein Wix-Workflow pflegt. | Anwendungsentitäten und Katalog-Products getrennt halten und Schlüssel erhalten. | Die Anwendung kann das Product oder die Variante auflösen, die sie erweitert. |
Betroffen sind Katalogverantwortliche, Integrationsteams und alle Systeme, die Product- oder Varianten-IDs verwenden. Die Gegenmaßnahme ist ein Abstammungsmodell und keine generische Feldkonvertierung.
Risiko bei Optionen, Modifiers, Varianten und Personalisierung
Catalog-V3-Customizations unterscheiden Optionen von Modifiers. Optionen erzeugen Kombinationen mit unterschiedlichen SKUs, Preisen und Beständen. Modifiers erfassen Text- oder Auswahlwerte, ohne Variantenidentität oder Bestand zu verändern. Quellkataloge speichern Größe, Farbe, Gravur, Verpackung, Service-Upgrades, Garantien und Spezifikationen häufig in derselben Optionstabelle.
| Quellmuster | Wix-Einschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Größe oder Farbe wird als beschreibendes Metadatum behandelt. | Kaufbare Auswahlwerte sollten Varianten bilden, wenn sie SKU, Preis oder Bestand bestimmen. | Das Product zeigt den Wert, kann die gekaufte Kombination aber nicht korrekt verwalten. | Bestand und Fulfillment verwenden den falschen Artikel. | Option-Auswahl-Varianten-Beziehung erhalten. | Die ausgewählte Option führt zur vorgesehenen Variante und zum richtigen Inventory Item. |
| Gravur oder Freitext wird zu einer Option. | Optionen erzeugen Varianten; Modifiers erfassen Eingaben, ohne Bestand zu ändern. | Der Katalog erzeugt bedeutungslose Kombinationen für jeden Personalisierungspfad. | Product-Verwaltung und Bestand werden unübersichtlich. | Nicht bestandsrelevante Eingaben einem Modifier-ähnlichen Eigentümer zuweisen. | Customer-Eingaben erscheinen in der Transaktion, ohne eine Variante zu erzeugen. |
| Kostenpflichtige Extras werden automatisch Varianten. | Manche Extras verändern den Preis, aber nicht die Bestandsidentität und können einem Modifier oder einer App gehören. | Falsche Varianten fragmentieren Reporting und Verfügbarkeit. | Mitarbeitende können das Basis-Product nicht von einem optionalen Service unterscheiden. | Festlegen, ob das Extra einem Modifier, einer App, einem Bundle oder einem externen Workflow gehört. | Order-Details zeigen das Extra, während der Basisbestand konsistent bleibt. |
| Bundle-Komponenten werden als Product-Text gespeichert. | Komponentenbestand und Fulfillment benötigen eine eigene Beziehung. | Das Angebot ist sichtbar, aber Komponentenverfügbarkeit kann nicht berechnet werden. | Überverkäufe und Picking-Fehler entstehen. | Komponentenlogik einer kompatiblen App oder einem externen System zuweisen. | Das bestandsverantwortliche System kann jede Komponente identifizieren. |
| Spezifikationen werden zu Variantendimensionen. | Info Sections, Brands, Categories und andere Katalogfelder können Products beschreiben, ohne Kombinationen zu erzeugen. | Variantenanzahl wächst unnötig und Käufer sehen irrelevante Auswahlwerte. | Katalogpflege wird komplex und fehleranfällig. | Nicht auswählbare Informationen außerhalb von Optionsdimensionen halten. | Spezifikationen bleiben wiederverwendbar oder beschreibend, ohne Variantenidentität zu verändern. |
Das Risiko ist beherrscht, wenn für jede Käufereingabe klar ist, ob sie verkaufsfähige Identität, Bestand, Preis, Fulfillment oder den historischen Order-Kontext beeinflusst.
Risiko bei Varianten- und Location-basiertem Bestand
Wix Inventory Items können Bestand für eine konkrete Variante an einer konkreten Location verfolgen. Locations können Shops, Lager oder Fulfillment-Center darstellen. Dadurch entsteht ein granulareres Risikomodell als bei einer einzigen Product-Menge.
| Annahme | Bestandseinschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Eine Quellmenge kann direkt auf das Product kopiert werden. | Bestand gehört zu Varianten-Location-Beziehungen. | Die Menge wird von verkaufsfähiger Einheit und Fulfillment-Location getrennt. | Customers sehen falsche Verfügbarkeit und Mitarbeitende erfüllen aus dem falschen Bestandspool. | Jeden Quell-Bestandsverantwortlichen einer Zielvariante und Location zuordnen. | Location- und Variantensummen entsprechen dem erklärten Betriebsmodell. |
| Alle Products sollten verfolgten Bestand besitzen. | Services, digitale Güter, unbegrenzte Artikel und extern gesteuerte Verfügbarkeit können andere Regeln verwenden. | Nicht bestandsgeführte Angebote werden unverfügbar oder irreführende Mengen erscheinen. | Gültige Verkäufe werden blockiert oder nicht unterstützte Products bleiben sichtbar. | Verfolgte, unbegrenzte, Preorder- und extern gesteuerte Fälle getrennt klassifizieren. | Jede Bestandsklasse erzeugt das vorgesehene Verkaufsverhalten. |
| Sichtbare Product-Erstellung beweist vollständigen Bestand. | Inventory Items können separat erstellt und zugeordnet werden müssen. | Products existieren mit fehlenden Bestandsdatensätzen. | Mitarbeitende nehmen wegen des sichtbaren Katalogs fälschlich an, der Bestand sei migriert. | Inventory-Item-Beziehungen in das Katalogmodell aufnehmen. | Jede verfolgte Variante besitzt ein identifizierbares Inventory Item an der vorgesehenen Location. |
| Eine Momentaufnahme reicht für einen ERP-gesteuerten Katalog. | Externe Systeme veröffentlichen nach der Migration weiterhin Bestände. | Anfangsbestände sind korrekt, spätere Updates schlagen jedoch fehl oder werden falsch zugeordnet. | Kanalbestände driften schnell auseinander. | Product-, Varianten-, Location- und externe Systemschlüssel erhalten. | Ein fortlaufendes Update erreicht den vorgesehenen Varianten-Location-Datensatz. |
| Historische Orders sollen Bestandsbewegungen erneut abspielen. | Historische Transaktionen und Anfangsbestand haben unterschiedliche Aufgaben. | Die Menge wird ein zweites Mal reduziert. | Der Shop startet mit falschem verfügbarem Bestand. | Anfangsbestand unabhängig von importierter Order-Historie festlegen. | Historische Orders verändern den freigegebenen Anfangsbestand nicht. |
Bestandsrisiken wirken sich schnell auf Umsatz aus, doch die strukturelle Kontrolle bleibt eindeutig: Wix und jeder externe Bestandsverantwortliche müssen dieselbe Varianten- und Location-Identität verwenden.
Contacts, Members, Customers und App-Teilnehmer
Wix Contacts können Personen repräsentieren, die mit der Site interagieren, während Members Konto- und Zugriffsbeziehungen hinzufügen. Commerce-Customers, Formularabsender, Subscribers, Booking-Kunden, Event-Teilnehmer, Pricing-Plan-Inhaber, Loyalty-Teilnehmer und Anwendungsprofile können sich überschneiden, ohne dieselbe Entität zu sein.
| Annahme im Quellsystem | Wix-Einschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Jeder Customer sollte zu einem Member werden. | Contact-Identität und Member-Zugriff sind getrennte Beziehungen. | Gastkäufer erhalten falsche Login-Erwartungen oder membergeschützter Zugriff geht verloren. | Account-Support und geschützte Inhalte werden inkonsistent. | Käuferhistorie und Member-Berechtigung getrennt erhalten. | Nur vorgesehene Nutzer erhalten Member-Zugriff, und Orders bleiben mit dem richtigen Contact verbunden. |
| Eine E-Mail-Adresse beweist eine einzige Person. | Quellduplikate, gemeinsam genutzte E-Mail-Adressen, geänderte Adressen und externe IDs können unterschiedliche Historien darstellen. | Contacts werden falsch zusammengeführt oder eine Person wird mehrfach angelegt. | Marketing, Support und Order-Historie werden unzuverlässig. | Quell-IDs, Order-Verknüpfungen, E-Mail, Telefon und externe Schlüssel in einer dokumentierten Identitätshierarchie verwenden. | Hochwertige und mehrdeutige Personen werden dem vorgesehenen Contact zugeordnet. |
| Subscriber-Einwilligung ist gewöhnliches Contact-Datum. | Kommunikationsberechtigung hat Zweck und Herkunft getrennt von der Identität. | Importierte Contacts könnten ohne gültige Grundlage als marketingfähig behandelt werden. | Compliance und Zielgruppensteuerung werden geschwächt. | Nur unterstützte Präferenzinformationen mit klarer Bedeutung erhalten. | Marketing-Workflows unterscheiden Identität von Kommunikationsberechtigung. |
| App-Teilnehmer gehören in Contact-Custom-Fields. | Bookings, Events, Pricing Plans, Loyalty und andere Apps besitzen spezialisierte Datensätze. | Zeitplan-, Berechtigungs-, Fortschritts- oder Guthabendaten werden abgeflacht. | Kundenservice kann die aktive Beziehung nicht mehr verstehen. | Contact-Verknüpfung erhalten und spezialisierte Entität unter ihrem tatsächlichen Eigentümer migrieren oder archivieren. | Die fortbestehende App erkennt den vorgesehenen Contact und Teilnahmedatensatz. |
| Externe CRM-IDs können ersetzt werden. | CRM- und Supportsysteme können den bestehenden Schlüssel als maßgeblich behandeln. | Aktualisierungen erzeugen doppelte Contacts oder landen am falschen Datensatz. | Segmentierung und Support-Historie teilen sich auf. | Dauerhafte externe Kennungen auf der vom CRM verwendeten Contact- oder Organisationsgranularität erhalten. | Eine CRM-Abfrage liefert den vorgesehenen Wix Contact. |
Die Kontrolle besteht aus einem mehrschichtigen Identitätsmodell: Contact-, Member-, Customer-, Teilnehmer- und externe Kontobeziehungen bleiben verbunden, ohne zusammengelegt zu werden.
Orders, Billing, Transactions, Fulfillment und Settings
Wix-eCommerce-Orders verwalten den Lebenszyklus nach dem Kauf und verbinden gekaufte Positionen, Zahlungsdetails, Versandinformationen und Fulfillment-Status. Wix trennt außerdem Order Billing, Order Transactions, Invoices, Payment Requests, Fulfillments und Order Settings. Eine historische Migration sollte Nachweise aus diesen Bereichen erhalten, ohne alten Datensätzen aktuelle operative Autorität zu geben.
| Risikokette | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|
| Ein einzelner Quellstatus wird als vollständiger Order-Status kopiert. | Zahlungs-, Fulfillment-, Storno-, Rechnungs- und Erstattungsbedeutung wird komprimiert. | Mitarbeitende können nicht erkennen, ob Geld oder Waren noch ausstehen. | Lesbare historische Zustände über die relevanten Order-Beziehungen hinweg erhalten. | Komplexe Orders lassen sich ohne Zugriff auf das Quellsystem vollständig nachvollziehen. |
| Order-Positionen verknüpfen nur mit übergeordneten Products. | Gekaufte Variante, Modifier oder App-eigene Konfiguration geht verloren. | Support und Fulfillment können nicht erkennen, was gekauft wurde. | Momentaufnahmen der Positionen und zuverlässige Product-/Varianten-/Customization-Referenzen erhalten. | Die Position zeigt die vorgesehene verkaufsfähige Identität und Käufereingabe. |
| Historische Zahlungsdaten werden als aktuelle Autorität behandelt. | Zahlungsdetails und Transactions dokumentieren die Vergangenheit; aktuelle Provider und Einstellungen sind getrennt. | Teams erwarten, dass alte Zugangsdaten oder Tokens neuen Commerce verarbeiten. | Sichere Transaktionsreferenzen erhalten und aktuelles Zahlungsverhalten unabhängig konfigurieren. | Historische Zahlungen sind nachvollziehbar, ohne Zugangsdaten offenzulegen oder falsch zu verwenden. |
| Versandetiketten stellen aktuelles Fulfillment wieder her. | Fulfillments, Lieferkonfiguration, Carrier und Locations haben eigene aktuelle Zuständigkeiten. | Neue Orders folgen unvollständigen Routen. | Historische Versandnachweise erhalten und aktives Fulfillment separat definieren. | Historische und aktive Fulfillment-Verantwortlichkeiten sind unterscheidbar. |
| Importierte Orders lösen aktuelle Bestandsupdates aus. | Order-Historie und anfängliche Inventory Items haben verschiedene Zwecke. | Bestand wird erneut reduziert oder falsch synchronisiert. | Historischen Order-Import von der Autorität über Anfangsbestand trennen. | Bestand bleibt stabil, nachdem historische Datensätze eingeführt wurden. |
Betroffen sind Kundenservice, Finance, Operations und Integrationsteams. Die Gegenmaßnahme besteht darin, historische Nachweise zu erhalten und gleichzeitig aktuelle Wix-Einstellungen als maßgeblich zu behandeln.
Risiko bei CMS Collections, dynamischen Seiten und Referenzfeldern
Wix CMS Collections können strukturierte Data Items und Referenzfelder speichern. Sie können dynamische Seiten, Verzeichnisse, Ressourcen, individuelle Storefront-Inhalte und Anwendungsworkflows betreiben und außerdem externe Datenbanken anbinden. Diese Flexibilität birgt das Risiko, dass individuelle Quelltabellen in CMS verschoben werden, ohne Schema, Referenzen, Berechtigungen, Code oder Seitenverhalten zu erhalten.
| Annahme im Quellsystem | CMS-Einschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Eine Quelltabelle kann automatisch zu einer CMS Collection werden. | Collection-Felder, Item-Schemas, Berechtigungen, Referenzen, Indizes sowie konsumierende Seiten oder Code sind getrennte Bestandteile. | Zeilen werden übertragen, während Beziehungen und Bearbeitungsverhalten verschwinden. | Dynamische Seiten zeigen unvollständige Daten oder können verknüpfte Datensätze nicht auflösen. | Collection-Schema, Referenzfelder, Berechtigungen und Verbraucher als ein Modell definieren. | Repräsentative Items lösen jede erforderliche Referenz- und Seitenbeziehung korrekt auf. |
| Numerische Quell-IDs können als Referenzen kopiert werden. | CMS-Referenzen müssen auf Identitäten der Ziel-Data-Items zeigen. | Alte IDs werden zu bedeutungslosen Literalwerten. | Verwandte Datensätze und dynamische Seiten werden getrennt. | Quellbeziehungen in Ziel-Referenzfelder überführen. | Jede Eltern-Kind- oder Many-to-Many-Beziehung wird in Wix CMS aufgelöst. |
| Die Aktualisierung eines Items erhält nicht angegebene Werte automatisch. | Einige Update-Vorgänge ersetzen Item-Inhalte, wenn Felder ausgelassen werden. | Teilweise Synchronisierung löscht unbeabsichtigt Daten. | Externe Systeme überschreiben Felder, für die sie nicht verantwortlich sind. | Feldzuständigkeit und sichere Update-Methodik für fortlaufende Integrationen definieren. | Aktualisierungen verändern nur Felder, die dem veröffentlichenden System gehören. |
| CMS-Daten spiegeln jeden Schreibvorgang überall sofort wider. | Datenabfragen können in relevanten Workflows eventual consistency aufweisen. | Automatisierungen oder Frontend-Abfragen reagieren auf einen veralteten Zustand. | Doppelte Aktionen oder vorübergehende Inkonsistenzen entstehen. | Integrationen für Propagationszeiten auslegen und maßgebliche Events/Zustände verwenden. | Zeitkritische Workflows verlassen sich nicht auf sofortige Read-after-write-Annahmen. |
| CMS kann Product-, Order- oder App-Domänen ersetzen. | CMS ist flexibler Speicher, bildet aber Wix-Stores- oder Anwendungsverhalten nicht nach. | Zentrale Commerce- oder Teilnehmerdatensätze werden in ein unverwaltetes Schattenmodell dupliziert. | Mitarbeitende pflegen widersprüchliche Wahrheitsquellen. | CMS nur verwenden, wenn es tatsächlich der Ziel-Eigentümer ist, nicht als generische Ausweichtabelle. | Jede Entität besitzt genau ein erklärtes System of Record. |
CMS-Risiko ist kontrolliert, wenn Schema, Referenzen, Berechtigungen, Routen und der konsumierende Code als eine gemeinsame Abhängigkeitskette behandelt werden.
Risiko bei Site-Seiten, URLs, mehrsprachigen Inhalten und SEO
Die Wix-Site-Struktur kann statische Seiten, dynamische Seiten, Product- und Category-Routen, Blog Posts, Menüs, Medien, Formulare, mehrsprachige Versionen, Domains, SEO-Metadaten und Weiterleitungen umfassen. Routen und Page-Builder-Strukturen des Quellshops lassen sich nicht zwingend direkt übertragen.
| Abhängigkeit im Quellsystem | Wix-Einschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Product- oder Category-Datensätze stellen Navigation wieder her. | Wix Categories, Menüs, Seiten und dynamische Routen sind verbunden, aber getrennt. | Katalogdatensätze existieren ohne den vorgesehenen Browsing-Pfad. | Käufer können wichtige Products nicht finden. | Navigation und Landing-Verantwortung unabhängig von Category-Mitgliedschaft zuweisen. | Prioritäre Buyer Journeys erreichen das vorgesehene Product- oder Category-Ziel. |
| Quell-URLs können automatisch unverändert bleiben. | Routen hängen von Wix-Seiten-, Katalog-, Mehrsprachigkeits- und Domainstrukturen ab. | Hochwertige Pfade ändern sich ohne Kontinuität. | Suchtraffic, Backlinks und Bookmarks schlagen fehl. | Kanonische Ziele und Weiterleitungsbeziehungen für prioritäre URLs definieren. | Prioritäre alte Pfade führen zu nutzbaren Zielressourcen. |
| Page-Builder-Daten sind portabler Content. | Wix-Abschnitte, Komponenten, dynamische Seiten, Apps und Code bestimmen die Darstellung. | Text wird übertragen, aber Formulare, Abfragen, Interaktionen und Layoutbeziehungen verschwinden. | Content- und Conversion-Journeys werden unvollständig. | Dauerhafte Inhalte und Medien von Zieldarstellung und Verhalten trennen. | Jede wichtige Seite besitzt funktionierende Zuständigkeit für Inhalt, Route und Interaktion. |
| Sprache ist nur ein Feld im Quelldatensatz. | Mehrsprachige Inhalte können koordinierte Routen, Seiten, CMS Items, Menüs und Katalogwerte erfordern. | Übersetzungen existieren, sind aber nicht mit dem vorgesehenen Spracherlebnis verbunden. | Nutzer sehen falsche Sprache oder doppelte Inhalte. | Übersetzungsidentität und Routenkontext über die relevanten Eigentümer hinweg erhalten. | Sprachpfade und zugehörige Inhalte sind für prioritäre Journeys konsistent. |
| Medienübertragung erhält eingebettete Referenzen automatisch. | Content, Product-Medien, CMS Items und Anwendungen können Assets unterschiedlich referenzieren. | Dateien existieren, während Seiten oder Products noch auf alte Pfade zeigen. | Defekte Bilder und Downloads beeinträchtigen Vertrauen. | Attachment- und eingebettete Link-Beziehungen zusammen mit dem verantwortlichen Datensatz übertragen. | Repräsentative Routen zeigen die vorgesehenen Assets ohne Abhängigkeit von der Quelldomain. |
Das Kontrollsignal ist die Kontinuität der Buyer- und Content-Journey und nicht eine übereinstimmende Anzahl von Seiten oder Mediendateien.
Apps, Velo, Service-Plugins und externe Systeme
Velo-Code, Wix-Anwendungen, Service-Plugins, Webhooks und externe Systeme können Preise berechnen, Eingaben validieren, CMS Collections abfragen, Memberships verwalten, Products synchronisieren, Bestand veröffentlichen oder Fulfillment verändern. Ihre Datensätze und Logik gehören nicht automatisch zum Kern von Wix Stores.
| Abhängigkeitsannahme | Wix-Einschränkung | Folge für die Migration | Betriebliche Auswirkung | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|---|
| Ähnliche Apps besitzen kompatible Datensätze. | Jede App definiert eigene Entitäten, Berechtigungen, Kennungen und Lebenszyklen. | Daten werden ohne funktionierenden Anwendungseigentümer in generische Felder verschoben. | Guthaben, Zeitpläne, Memberships oder Historie gehen verloren. | Die tatsächliche Quellentität der vorgesehenen Wix-App oder dem externen Eigentümer zuordnen. | Die fortbestehende Anwendung erkennt ihren übergeordneten Contact, ihr Product oder ihre Order. |
| Velo-Code kann als Daten kopiert werden. | Code hängt von Wix APIs, CMS-Schemas, Events, Berechtigungen und Secrets ab. | Skripte kommen ohne gültige Abhängigkeiten oder Zielzuständigkeit an. | Geschäftsregeln schlagen unbemerkt fehl oder erzeugen inkonsistente Daten. | Nur das erforderliche Verhalten gegen das Zielschema und unterstützte APIs neu umsetzen. | Das Verhalten hat einen benannten Eigentümer und keine unerklärte Quellabhängigkeit. |
| Externe IDs können neu erzeugt werden. | ERP, CRM, PIM, WMS, Marketplace- und Buchhaltungssysteme können stabile Schlüssel verwenden. | Synchronisierung verbindet sich mit Duplikaten oder falschen Datensätzen. | Bestands-, Customer- und Order-Prozesse driften auseinander. | Kennungen auf derselben Entitätsgranularität erhalten, die das maßgebliche System verwendet. | Eine Roundtrip-Abfrage im externen System führt zu genau einem vorgesehenen Wix-Datensatz. |
| Ein Custom Field stellt eine Automatisierung wieder her. | Felder speichern Werte; Automatisierungen und Service-Plugins führen Verhalten aus. | Daten überleben, aber die Regel, die sie verwendet, fehlt. | Mitarbeitende sehen veraltete oder irreführende Werte. | Wertzuständigkeit und Verhaltenszuständigkeit getrennt zuweisen. | Der fortbestehende Prozess aktualisiert und interpretiert das Feld korrekt. |
| API-Verfügbarkeit garantiert Modellgleichheit. | APIs stellen definierte Ressourcen und Konsistenzverhalten bereit, nicht beliebige Quellsemantik. | Umfang wird anhand der Verbindungsmöglichkeit statt kompatibler Zuständigkeit definiert. | Fehlende Beziehungen werden erst nach der Umsetzung sichtbar. | Entitäts- und Lebenszykluskompatibilität prüfen, bevor auf eine API gesetzt wird. | Jede fortbestehende Integration besitzt ein definiertes Quell- und Zielentitätsmodell. |
Dieser Bereich betrifft Entwickler, Anwendungsadministratoren und Business Owner. Die strukturelle Gegenmaßnahme ist ein Abhängigkeitsmodell der Anwendungen mit stabilen Eltern-IDs und ausdrücklich definierter Verhaltenszuständigkeit.
Matrix für Risikozuständigkeit und Kontrollen
| Risikobereich | Primärverantwortung | Geschäftliche Auswirkung ohne Kontrolle | Gegenmaßnahme | Kontrollsignal |
|---|---|---|---|---|
| Katalogabstammung | Katalog- und Integrationsverantwortung | Doppelte oder falsch identifizierte Products und Varianten | V1/V3-Quelllinie und universelle Variantenidentität definieren. | Jeder verkaufsfähige Quellartikel wird in Catalog V3 genau einmal aufgelöst. |
| Optionen und Modifiers | Katalog- und Fulfillment-Verantwortung | Falsche Varianten oder verlorene Personalisierung | Auswahlwerte nach ihrer Wirkung auf Identität, Bestand und Order-Daten klassifizieren. | Käufereingaben erzeugen die vorgesehene Variante oder den vorgesehenen Modifier-Datensatz. |
| Bestand | Bestandsverantwortung | Überverkäufe und Location-Fehlzuordnung | Varianten-Location-Granularität und externe Bestandsautorität schützen. | Anfangs- und fortlaufende Mengen erreichen das vorgesehene Inventory Item. |
| Contacts und Members | Customer-Operations-Verantwortung | Falsche Zusammenführungen, Zugriffsfehler und beschädigte App-Historie | Geschichtete Beziehungen für Identität, Zugriff, Einwilligung und Anwendungen erhalten. | Hochwertige und mehrdeutige Identitäten werden korrekt aufgelöst. |
| Orders | Kundenservice und Finance | Unlesbare Historie oder unsichere operative Annahmen | Historische Momentaufnahmen und zugehörige Transaction-/Fulfillment-Nachweise erhalten. | Komplexe alte Orders lassen sich vollständig erklären. |
| CMS und Site | Site- und Content-Verantwortung | Defekte dynamische Seiten, Routen und Referenzen | Schema, Referenzfelder, Seiten, Berechtigungen und URLs gemeinsam definieren. | Prioritäre dynamische und statische Journeys funktionieren korrekt. |
| Anwendungen und Velo | Anwendungs- oder Engineering-Verantwortung | Verlorenes Verhalten und defekte Integrationen | Verhalten gegen Zielentitäten und stabile IDs neu aufbauen. | Fortbestehende Workflows erkennen und aktualisieren die vorgesehenen Datensätze. |
Die Matrix weist Kontrollverantwortung zu, damit Umsetzung und Nachweisprüfung den erklärten Beziehungen folgen, statt während der Ausführung neue Zuständigkeiten zu erfinden.
Fazit
Wix-Migrationseinschränkungen entstehen aus dem Zusammenspiel einer verwalteten Site-Builder-Plattform, Catalog V3, universellen Varianten, Varianten-Location-Inventory-Items, Contacts, Members, Orders, CMS Collections, Anwendungen, Velo und externen Systemen. Die schwersten Risiken entstehen, wenn diese Bereiche als eine einzige Datenbank behandelt oder Annahmen aus Catalog V1 und V3 vermischt werden.
Eine kontrollierte Migration schützt die Product-Abstammung, trennt Optionen von Modifiers, ordnet Bestand der richtigen Variante und Location zu, hält Contact-Identität von Member- und App-Beziehungen getrennt, erhält historische Orders ohne ihnen aktuelle Autorität zu geben und behandelt CMS-, Site- und Anwendungsverhalten als ausdrücklich definierte Zuständigkeitsbereiche. So werden aus allgemeinen Warnungen plattformspezifische Ursache-Wirkungs-Ketten.
Häufige Fragen
Warum ist Catalog V1 gegenüber Catalog V3 ein Migrationsrisiko?
Catalog V3 verwendet universelle Varianten und trennt Products, Customizations, Inventory Items, Locations und weitere Katalogservices klarer. Werden Annahmen oder Kennungen aus V1 ohne Abstammungsmodell wiederverwendet, können doppelte Products, fehlender Bestand oder defekte Integrationen entstehen.
Welches Risiko entsteht, wenn Wix Modifiers als Product-Optionen behandelt werden?
Optionen erzeugen Varianten und beeinflussen SKU-, Preis- und Bestandsidentität. Modifiers erfassen zusätzliche Informationen, ohne Varianten zu erzeugen. Eine Verwechslung kann falsche Bestandskombinationen erzeugen oder die tatsächliche Variantenidentität des gekauften Artikels entfernen.
Warum kann ein Wix Product ohne vollständiges Bestandsverhalten existieren?
Product- und Inventory-Item-Beziehungen können getrennt erstellt werden, und verfolgter Bestand ist varianten- und locationspezifisch. Ein sichtbares Product beweist nicht, dass jede verfolgte Variante dem vorgesehenen Inventory Item und der richtigen Location zugeordnet ist.
Sind Wix Contacts, Members und Customers dieselbe Entität?
Nein. Ein Contact stellt Identität und CRM-Kontext bereit, ein Member ergänzt Konto- oder Zugriffsbeziehungen, Commerce erzeugt Customer- und Order-Kontext und Wix-Apps können separate Teilnehmer- oder Berechtigungsdatensätze besitzen. Diese Beziehungen sollten verbunden bleiben, ohne zusammengelegt zu werden.
Können historische Orders beweisen, dass der aktuelle Wix-Checkout und das Fulfillment startbereit sind?
Nein. Historische Orders erhalten gekaufte Positionen, Zahlungsdetails, Versandinformationen und Fulfillment-Status. Aktive Provider, Order Settings, Bestandsupdates, Benachrichtigungen, Lieferregeln und Fulfillment-Services bleiben aktuelle Konfiguration.
Wann sollten individuelle Quelldaten Wix CMS statt einer Wix-App oder eines externen Systems verwenden?
CMS sollte verwendet werden, wenn die Collection tatsächlich der Eigentümer strukturierter Site-Daten ist und Schema, Referenzen, Berechtigungen, Seiten und Update-Verhalten definiert sind. Spezialisierte Commerce-, Membership-, Termin- oder Transaktionsdatensätze sollten bei der App oder dem externen System bleiben, das ihren Lebenszyklus verantwortet.