Wenn Wix als mögliche Zielplattform für die Daten, Beziehungen und geschäftliche Bedeutung des Ausgangsshops bewertet wird, entstehen Migrationsfehler häufig dann, wenn Wix Stores, CMS, Site Members, Apps, mehrsprachiger Content, Velo-Logik und Automatisierungen wie eine einzige austauschbare Datenebene behandelt werden. Diese Systeme können zusammengehörige Informationen anzeigen und dennoch unterschiedliche Zuständigkeiten, Berechtigungen und Abläufe besitzen.
Zur Vorbeugung muss für jeden Datensatz und jede Funktionsweise klar sein, wer sie verantwortet. Diese Zuständigkeitsgrenzen müssen ausdrücklich sichtbar sein, und für jedes Fehlermuster ist eine praktische Bestehensbedingung festzulegen. Das Ziel ist eine nutzbare Wix-Website mit funktionsfähigem Store, nicht lediglich ein gefülltes Dashboard.
Fehler 1: Wix wie einen generischen gehosteten Store behandeln
Was schiefgeht
Die Migration wird geplant, als wäre Wix lediglich ein Ziel für Products, Customers und Orders. Das Team prüft, ob Datensätze vorhanden sind, testet jedoch nicht, wie sich die migrierten Daten innerhalb der Site-Builder- und Commerce-Umgebung von Wix verhalten. Products erscheinen zwar im Katalog, aber Seitendarstellung, Collections, Website-Navigation, Checkout-Konfiguration, Contacts, Members, CMS-Content, Medien, URLs und Apps sind unzureichend eingeplant.
Dadurch entsteht ein falsches Gefühl von Launch-Bereitschaft. Die Zielwebsite kann migrierte Datensätze enthalten, während Kunden wichtige Products nicht finden, Optionen nicht korrekt auswählen, wichtige Content-Seiten nicht erreichen, den Checkout nicht abschließen oder alte URLs nicht zur neuen Wix-Website führen.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Der Migrationsumfang nennt nur Products, Customers und Orders. | Website-Struktur, Content, URLs, Apps und Konfiguration von Wix können in der Launch-Planung fehlen. |
| Products werden ausschließlich im Dashboard geprüft. | Storefront-Darstellung und Auffindbarkeit für Käufer können weiterhin fehlschlagen. |
| Website-Design, Menüs, Domains und Redirects werden bis zum Ende aufgeschoben. | Kundenpfade hängen von mehr als nur migrierten Datensätzen ab. |
| Apps, Formulare, Members, CMS-Collections oder Velo-Logik werden nicht inventarisiert. | Geschäftskritische Funktionen können außerhalb der zentralen Wix-Stores-Datensätze liegen. |
Vorbeugung
Planen Sie Wix als Zielplattform für Website und Commerce. Prüfen Sie Katalogdatensätze, Product-Seiten, Collection-Darstellung, Navigationspfade, CMS Pages, Blog Posts, Medien, die Bedeutung von Customers und Members, historische Orders, URLs, Redirects, Domains und App-Abhängigkeiten als miteinander verbundene Betriebsbereiche.
Trennen Sie übertragene Datensätze von Funktionen, die vom Händler, durch Wix-Konfiguration, Entwickler, App-Anbieter oder externe Systeme verantwortet werden. Diese Abgrenzung verhindert, dass Lücken in der Zielkonfiguration fälschlich als Fehler der Datenübertragung bewertet werden.
Empfehlungsbeispiel
Ein Händler, der von Shopify zu Wix wechselt, sollte einen einfachen Product, einen variantenreichen Product, eine Product Collection, eine stark besuchte Product-Seite, einen Blog Post, eine CMS Page, eine Gast-Order, einen wiederkehrenden Customer, einen Member-bezogenen Datensatz und einen wichtigen Redirect als zusammenhängenden Stichprobensatz prüfen.
Bestehensbedingung
Die Wix-Zielwebsite unterstützt die vereinbarten Verkaufs-, Content-, Customer-, Order-History- und Betriebsabläufe. Verbleibende Lücken haben klar benannte Verantwortliche: Datensatzkorrektur, Wix-Konfiguration, individuelle Implementierung, Arbeit an externen Systemen, manuelle Rekonstruktion oder bewusst akzeptierter Ausschluss.
Fehler 2: Products, Optionen, Choices und Varianten zu vereinfachen
Was schiefgeht
Der Ausgangskatalog wird als Sammlung einfacher Wix Products migriert, ohne die Bedeutung von Optionen, Choices, Varianten, variantenspezifischen SKUs, Preisen, Beständen, Bildern, Gewichten, Personalisierungen oder quellplattformspezifischen Product-Regeln zu erhalten. Die Product-Anzahl kann korrekt wirken, während Kunden und Mitarbeiter wichtigen Kontext für Kaufentscheidungen verlieren.
Dieser Fehler tritt häufig auf, wenn der alte Store Product-Optionen, konfigurierbare Products, Custom Options, Bundles, Product Extras, Personalisierungsfelder, Product Builder oder app-gesteuerte Auswahlmöglichkeiten nutzt. Wix Products können Optionen, Choices und Varianten unterstützen, dennoch muss die Bedeutung der Ausgangsdaten sorgfältig interpretiert werden.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Product-Optionen werden nicht von Varianten getrennt. | Die Auswahl kann angezeigt werden, während SKU, Preis, Bestand oder Order-Details falsch werden. |
| Variantenspezifischer Bestand wird nicht stichprobenartig geprüft. | Bestand kann nur auf Ebene des übergeordneten Products korrekt erscheinen. |
| Product-Medien werden nur anhand der Dateianzahl geprüft. | Bilder können im falschen Product- oder Choice-Kontext erscheinen. |
| Bundle-, Anpassungs- oder kostenpflichtiges Optionsverhalten wird als gewöhnliche Product-Daten beschrieben. | Die Anforderung kann individuelle Implementierung, App-Konfiguration, Velo/API-Arbeit oder manuellen Neuaufbau benötigen. |
Vorbeugung
Stellen Sie vor der Umstellung einen repräsentativen Product-Satz zusammen. Er sollte einfache Products, variantenreiche Products, Products mit unterschiedlichen Variantenpreisen, Products mit unterschiedlichen Varianten-SKUs, bestandskritische Varianten, medienreiche Products, Products in wichtigen Collections sowie Products umfassen, deren Funktionsweise durch Apps oder individuelle Logik gesteuert wird.
Klassifizieren Sie schwieriges Product-Verhalten der Ausgangsplattform, bevor der Umfang akzeptiert wird. Explizite Product-Felder können sich für direkte Zuordnung eignen. App-eigene Product-Logik, individuelle Konfiguratoren, maßgeschneiderte Transformationen oder extern gesteuertes Katalogverhalten erfordern Wix-seitige Konfiguration, individuelle Implementierung, einen Verantwortlichen für das externe System oder einen bewussten Ausschluss.
Empfehlungsbeispiel
Ein Product der Ausgangsplattform besitzt Farb- und Größenvarianten, optionsspezifische Bilder, unterschiedliche SKU-Werte und getrennte Bestandsmengen. Die Wix-Stichprobe sollte nicht nur bestätigen, dass der Product vorhanden ist, sondern auch, dass jede Variante die vorgesehene SKU-, Preis-, Bild-, Bestands- und Order-Line-Bedeutung erhält.
Bestehensbedingung
Repräsentative Wix Products lassen sich finden, anzeigen, auswählen, in den Warenkorb legen und in der Order History prüfen, wobei Option, Choice, Variante, SKU, Preis, Bild und Bestandsbedeutung wie vorgesehen erhalten bleiben.
Fehler 3: Collections mit der vollständigen Website-Navigation gleichzusetzen
Was schiefgeht
Alte Categories, Collections, Menüs, Filter, Landingpages und Merchandising-Gruppen werden wie dasselbe Objekt behandelt. Die Migration kann Wix Collections erstellen, während Kunden dennoch Navigationspfade, Menülogik, SEO-Landingpages oder Beziehungen zu Kampagnenseiten verlieren.
Wix Collections sind wichtig, um Products zu gruppieren. Die vollständige Website-Erfahrung hängt jedoch zusätzlich von Seiten, Menüs, dynamischen Bereichen, Product-Galerien, internen Links, Suchverhalten, Redirects und Seitengestaltung ab. Die Migration von Collections allein stellt das frühere Discovery-Modell des Storefronts nicht wieder her.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Category-Migration wird mit Navigationsmigration gleichgesetzt. | Kunden erreichen nach dem Launch möglicherweise nicht die richtigen Products. |
| Alte Landingpages fehlen in der URL-Prüfung. | Hochwertige Traffic-Pfade können verloren gehen. |
| Product-Gruppen werden geprüft, ohne Menüs oder Links zu kontrollieren. | Wix Collections können vorhanden, aber vom Kundenpfad abgekoppelt sein. |
| Filter- oder Merchandising-Regeln sollen unverändert übernommen werden. | Das Verhalten der Ausgangsplattform kann Wix-Konfiguration, App-Logik oder manuelle Seitenarbeit erfordern. |
Vorbeugung
Trennen Sie Collection-Daten von Entscheidungen zur Website-Navigation. Prüfen Sie Product-zu-Collection-Zuordnungen, Product-Gallery-Darstellung, Menülinks, interne Links, Landingpages, Redirects, Suchverhalten und stark frequentierte Pfade als eigenständige Verantwortungsbereiche für den Wix-Launch.
Ein belastbarer Präventionsplan ordnet die Rollen alter Categories und Collections konkreten Wix-Ergebnissen zu: Product-Gruppierung, Menüeintrag, Landingpage, Redirect-Ziel, Content-Seite, dynamische CMS-Seite oder bewusst stillgelegte Seite.
Empfehlungsbeispiel
Eine Source Category namens „Summer Essentials“ kann gleichzeitig Product-Gruppe, Kampagnenlink auf der Startseite, SEO-Landingpage und Ziel einer E-Mail-Kampagne gewesen sein. In Wix kann dafür eine Collection, eine Landingpage, Menüplatzierung, Redirect-Zuordnung und Monitoring der Kennzahlen nach dem Launch erforderlich sein.
Bestehensbedingung
Wichtige Pfade zur Product-Auffindbarkeit werden neu erstellt, weitergeleitet, bewusst stillgelegt oder einer Wix-seitigen Konfiguration zugewiesen. Collections werden als Product-Gruppen geprüft, die Navigation als kundenorientierte Website-Struktur.
Fehler 4: Historische Orders als Beleg für die Checkout-Bereitschaft zu verwenden
Was schiefgeht
Die Migration historischer Orders wird als Nachweis dafür verwendet, dass der Wix-Checkout bereit ist. Migrierte Orders können frühere Products, Payment Labels, Versanddetails, Refunds, Discounts, Taxes, Fulfillment-Status, Notizen und Customer-Beziehungen erhalten, konfigurieren aber keine zukünftigen Zahlungsanbieter, Checkout-Felder, Versandregeln, Steuern, Discounts, Benachrichtigungen, Fulfillment-Abläufe oder Order-Einstellungen.
Dadurch entsteht ein Launch-Risiko: Mitarbeiter können alte Orders lesen, während der Ziel-Store neue Orders möglicherweise nicht korrekt verarbeiten kann.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Historische Order-Stichproben werden als Checkout-Test verwendet. | Vergangene Order-Daten beweisen nicht, dass der zukünftige Wix-Kaufablauf funktioniert. |
| Payment Labels werden mit der Konfiguration des Zahlungsanbieters verwechselt. | Die Zahlungskonfiguration muss in Wix eingerichtet und getestet werden. |
| Versand- und Steuerwerte werden nur in alten Orders geprüft. | Die künftige Berechnung kann weiterhin unvollständig sein. |
| Individuelle Checkout-Regeln werden nicht identifiziert. | Quellspezifische Gebühren-, Validierungs- oder Versandlogik kann Apps, Service Plugins, Velo/API-Arbeit oder individuelle Implementierung benötigen. |
Vorbeugung
Prüfen Sie historische Orders und den Live-Checkout getrennt. Bei historischen Orders sollten Order-Identität, Positionen, Summen, Discounts, Taxes, Versand, Payment Labels, Refunds, Fulfillment-Kontext, Notizen und Customer-Verknüpfungen kontrolliert werden. Beim Live-Checkout müssen der konfigurierte Wix-Kaufpfad sowie Zahlung, Versand, Steuern, Discounts, Fulfillment und Benachrichtigungen getestet werden.
Falls der Ausgangs-Store individuelle Checkout-Logik nutzt, dokumentieren Sie, ob das Verhalten durch Wix-Konfiguration, App-Setup, Service-Plugin-Implementierung, individuelle Implementierung oder Ausschluss abgedeckt wird.
Empfehlungsbeispiel
Ein Händler besitzt alte Orders mit lokalen Liefergebühren, die anhand individueller Lieferzonen berechnet wurden. Diese historischen Order-Beträge können als lesbare Vergangenheitsdaten migriert werden. Für zukünftige Wix-Checkouts ist dennoch eine Versand- oder Lieferkonfiguration erforderlich, die die frühere Geschäftsregel nachbildet oder ersetzt.
Bestehensbedingung
Historische Order-Daten sind für Supportzwecke lesbar und nutzbar, während der zukünftige Wix-Checkout separat für Zahlung, Versand, Steuern, Discounts, Fulfillment und Kundenkommunikation konfiguriert und getestet wurde.
Fehler 5: Customers, Contacts, Members und App-Teilnehmer falsch einzuordnen
Was schiefgeht
Customer-Konten der Ausgangsplattform werden importiert, ohne zwischen Customer, Contact, Member, Subscriber, Gastkäufer, Loyalty-Nutzer, Booking-Teilnehmer, Paid-Plan-Nutzer oder app-spezifischer Identität zu unterscheiden. Wix kann diese Bedeutungen über verschiedene Funktionen oder Apps speichern bzw. darstellen. Ein migrierter Contact-Datensatz stellt daher nicht automatisch Kontozugriff, Membership-Verhalten, Loyalty-Teilnahme oder Marketingstatus wieder her.
Nach dem Launch kann dies zu Support- und Customer-Experience-Problemen führen. Mitarbeiter sehen möglicherweise einen Datensatz, können aber nicht erkennen, ob er einen Käufer, Site Member, Contact, Subscriber oder App-Teilnehmer repräsentiert.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Die Customer-Anzahl wird als Nachweis für Identitätskontinuität verwendet. | Zahlen bestätigen keine Konto-, Member-, Order- oder CRM-Beziehungen. |
| Gastkäufer werden nicht stichprobenartig geprüft. | Guest-Order-History kann sich anders verhalten als die Historie registrierter Customers. |
| Members und Contacts werden als identisch behandelt. | Zugriffsregeln und CRM-Kontext können unterschiedliche Wix-Behandlung erfordern. |
| Loyalty, Subscriptions, Bookings oder Paid Plans sollen automatisch migriert werden. | App-eigene Daten benötigen häufig eine separate Prüfung oder Konfiguration. |
Vorbeugung
Definieren Sie Identitätskategorien vor der Migration. Trennen Sie Customers, Gastkäufer, Contacts, Members, Subscribers, Formularteilnehmer, Booking-Teilnehmer, Loyalty-Nutzer, Paid-Plan-Members, Wholesale-Datensätze und externe CRM-Kennungen. Ordnen Sie anschließend jede Kategorie dem zentralen Record Mapping, der Wix-Konfiguration, einem App-Import, individueller Implementierung, Arbeit am externen System, manueller Rekonstruktion oder einem Ausschluss zu.
Die Validierung sollte wiederkehrende Käufer, Gastkäufer, Customers mit mehreren Adressen, Members mit Zugriffsanforderungen, mit Orders verknüpfte Customers und app-spezifische Identitätsbeispiele umfassen.
Empfehlungsbeispiel
Ein Ausgangs-Store enthält Customers, Newsletter-Abonnenten, Wholesale-Käufer, zahlende Members und Loyalty-Nutzer. Der Wix-Umfang sollte diese Datensätze nicht als dieselbe Customer-Entität behandeln. Für jeden Identitätstyp sind eine eigene Zielerwartung und eine eigene Validierungsstichprobe festzulegen.
Bestehensbedingung
Die migrierten Beziehungen zwischen Wix Customers, Contacts, Members und Order History entsprechen dem vereinbarten Umfang. App-spezifische Identitäts-, Zugriffs- oder CRM-Funktionen werden separat umgesetzt, geprüft oder als ausgeschlossen dokumentiert.
Fehler 6: CMS Pages, Blog Posts, Medien, URLs und SEO-Kontinuität zu vergessen
Was schiefgeht
Die Migration erhält Products, schwächt jedoch die Wix-Website-Erfahrung. CMS Pages, Blog Posts, dynamische Seiten, Medien, Product-Bilder, Collection-Seiten, Landingpages, Menüs, interne Links, Redirects, Seitentitel, Meta Descriptions, Alt-Text, Canonical-Anforderungen, Domains, mehrsprachige Pfade und Mobile Layout können anders als erwartet ausfallen, sofern sie nicht Teil des Umfangs und des Validierungsplans sind.
Dieser Fehler ist besonders kritisch für Stores, die auf organische Suche, ausführliche Buying Guides, content-getriebenen Verkauf, Kampagnen-Landingpages oder Blog-Traffic angewiesen sind.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| SEO wird nur auf Product-Ebene geprüft. | Risiken bei Seiten, Blog, Collections, Redirects und internen Links können bestehen bleiben. |
| Medienübertragung wird mit Seitenbereitschaft gleichgesetzt. | Bilddateien können vorhanden sein, ohne richtige Platzierung, Alt-Kontext oder Layout. |
| Redirects und Domain-Schritte werden bis zum Launch-Tag aufgeschoben. | Such-Traffic, Bookmarks, Analytics und Kampagnenlinks können brechen. |
| Blog Posts oder CMS Pages werden nicht stichprobenartig geprüft. | Content-Verlust kann erst nach dem Launch sichtbar werden. |
Vorbeugung
Erstellen Sie eine Validierungsliste für Content und SEO. Berücksichtigen Sie prioritäre Product-Seiten, Collection-Seiten, CMS Pages, Blog Posts, medienreiche Seiten, interne Links, Menüpfade, hochwertige URLs, Redirects, Seitentitel, Meta Descriptions, Alt-Kontext, Canonical-Anforderungen, Domain-Schritte und Aufgaben für die mobile Darstellung.
Trennen Sie übertragenen Content von Wix-Designarbeit. Rekonstruktion des Seitenlayouts, Mobile-Optimierung, Menüstrategie, visuelles Redesign und Domain-Arbeiten bleiben Wix-seitige Verantwortlichkeiten oder Aufgaben individueller Implementierung.
Empfehlungsbeispiel
Ein Händler besitzt Buying Guides, Blog-Tutorials und gut rankende Product-Category-Seiten. Der Wix-Präventionsplan sollte prioritäre URL-Zuordnung, Content-Stichproben, Prüfung von Blog Posts, Review interner Links, Redirect-Planung, Medienkontrollen und Mobile-Page-Prüfung vor dem Launch umfassen.
Bestehensbedingung
Prioritäre Products, Seiten, Blog Posts, Medien, Menüs, Redirects, Metadaten und interne Links sind in Wix validiert. Design-, Layout-, Domain-, Analytics- und SEO-Aufgaben außerhalb des Migrationsumfangs sind vor dem Launch zugewiesen.
Fehler 7: Apps, Velo-Logik, Service Plugins und externe Systeme als Standarddaten anzusehen
Was schiefgeht
Apps, Velo/API-Logik, CMS-Collections, Custom Catalogs, Service Plugins, individuelle Checkout-Regeln, individuelle Gebühren, Versandtarif-Integrationen, externe Zahlungsdienste, ERP-/CRM-/PIM-/WMS-/Accounting-Anbindungen oder Marketplace-Referenzen werden wie gewöhnliche Katalog-, Customer- oder Order-Felder behandelt. Der Ziel-Store kann grundlegende Migrationsprüfungen bestehen, während geschäftskritische Abläufe fehlschlagen.
Die Erweiterbarkeit von Wix bedeutet nicht, dass sich jede Funktion als gewöhnliche Daten übertragen lässt. Einige Funktionen gehören zur Wix-App-Konfiguration, zu CMS-Berechtigungen, Velo-Code, Automatisierungen, externen Integrationen, manueller Rekonstruktion oder einem bewussten Ausschluss.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| App-eigene Datensätze werden nicht getrennt aufgeführt. | Wichtige Daten können außerhalb des zentralen Wix-Stores-Migrationsumfangs liegen. |
| Velo/API-Verhalten wird ohne Beispiele beschrieben. | Code-gesteuerte Funktionen können nicht wie gewöhnliche Datensätze validiert werden. |
| Service-Plugin-Verhalten wird aus historischen Daten abgeleitet. | Checkout-, Versand-, Zahlungs- und Fulfillment-Logik kann Implementierung erfordern. |
| Externe Systeme werden erst nach dem Launch getestet. | Betriebliche Abläufe können ausfallen, nachdem der Traffic zu Wix verlagert wurde. |
Vorbeugung
Inventarisieren Sie alle individuellen und externen Abhängigkeiten vor der Migration. Erfassen Sie für jede App, jedes Custom Field, jede CMS Collection, jedes Skript, jedes Service-Plugin-Verhalten und jedes externe System den Verantwortlichen, Geschäftszweck, eine Source-Stichprobe, das erwartete Wix-Ergebnis, den vorgesehenen Behandlungsweg und den Validierungsnachweis.
Verwenden Sie unterstütztes Field Mapping nur für explizite Datensatzbeziehungen. App-eigene Datensätze, Velo/API-Verhalten, externe Kennungen, maßgeschneiderte Transformationen und Abhängigkeiten von externen Systemen benötigen eine Ziel-App, individuelle Implementierung, einen Integrationsverantwortlichen oder einen bewussten Ausschluss.
Empfehlungsbeispiel
Ein Ausgangs-Store verwendet einen Product Configurator, eine Loyalty-App und ERP-Synchronisierung. Wix-Product-Datensätze können migriert werden, das Konfiguratorverhalten, Loyalty-Salden und die ERP-Synchronisierung benötigen jedoch eine separate Behandlung. Dafür können Wix-App-Konfiguration, Velo/API-Arbeit, Implementierung des externen Systems, manuelle Rekonstruktion oder ein akzeptierter Ausschluss erforderlich sein.
Bestehensbedingung
Alle Abhängigkeiten von Apps, Velo/API, CMS-Collections, externen Systemen und Custom Data besitzen einen benannten Verantwortlichen und ein nutzbares Zielergebnis, das von den zentralen Wix-Stores-Datensätzen getrennt ist.
Fehler 8: Wix CMS Collections wie Wix-Stores-Katalogdaten zu behandeln
Was schiefgeht
Custom CMS Collections und Wix App Collections werden wie austauschbare Speicher für Product-Daten behandelt. Ein Team kann Products, Inventory, Orders oder Members in CMS-Ansichten sehen und daraus schließen, dass diese Collections wie gewöhnliche Custom Collections importiert, bearbeitet oder mit Berechtigungen versehen werden können. Das Ziel enthält anschließend doppelte Daten, schreibgeschützte Datensätze, getrennte Dynamic Pages oder Formulare, die in die falsche Collection schreiben.
Wix Stores und andere Apps besitzen ihre App Collections. Custom CMS Collections können eigenständige Content-Modelle unterstützen, werden dadurch aber nicht automatisch zum operativen Wix-Stores-Katalog.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Eine Custom Collection wird als Ziel für importierte Store Products vorgeschlagen. | Product-Darstellung kann neu aufgebaut werden, ohne Wix-Stores-Commerce-Funktionalität zu erhalten. |
| Wix App Collections werden wie bearbeitbare Custom Tables behandelt. | App-eigene Datensätze können schreibgeschützt sein oder festen Berechtigungen unterliegen. |
| Dynamic Pages zeigen Product-ähnlichen Content aus einer Custom Collection. | Die Seite kann korrekt aussehen, während Cart-, Inventory- und Order-Beziehungen fehlen. |
| Formulare oder Velo-Code schreiben direkt in eine Collection, ohne die Datenverantwortung zu klären. | Daten können die App umgehen, die sie eigentlich verwalten sollte. |
Vorbeugung
Ordnen Sie jede Collection ihrem Eigentümer und Zweck zu. Wix Stores App Collections sollten weiterhin durch Wix Stores verwaltet werden. Custom CMS Collections sollten nur verwendet werden, wenn sie ein eigenständiges Content-Modell mit bewusst definierten Feldern, Berechtigungen, Dynamic Pages und Integrationslogik abbilden. Duplizieren Sie operative Product-Daten nur, wenn für die Kopie ein klarer Synchronisierungsverantwortlicher und Geschäftszweck festgelegt ist.
| Collection-Typ | Geeignete Verwendung | Zentrale Kontrolle |
|---|---|---|
| Wix Stores App Collection | App-eigene Commerce-Daten anzeigen oder referenzieren. | Operative Daten über Wix Stores verwalten. |
| Custom CMS Collection | Strukturierter Content, Verzeichnisse, Ressourcen oder individuelle Workflows. | Felder, Berechtigungen, Dynamic Pages und Datenverantwortung definieren. |
| Member-private Collection | Member-spezifische Datensätze oder Einreichungen. | Rollen- und datensatzbezogene Zugriffsregeln erhalten. |
| Spiegel eines externen Systems | Reporting- oder Integrationszwecke. | Synchronisierung, Kennungen und Konfliktbehandlung definieren. |
Empfehlungsbeispiel
Ein Ausgangs-Store besitzt einen individuellen Vergleichsleitfaden, der mit Products verknüpft ist. Importieren Sie die Products in Wix Stores und die Datensätze des Leitfadens in eine Custom CMS Collection. Verknüpfen Sie beide über stabile Kennungen oder bewusst definierte Referenzen. Bauen Sie den Product-Katalog nicht innerhalb der Guide-Collection nach, nur weil beides auf Dynamic Pages erscheint.
Bestehensbedingung
Jede Collection besitzt einen klar benannten Eigentümer, Zweck, ein Berechtigungsmodell und einen Aktualisierungspfad. Operative Products bleiben unter der Verwaltung von Wix Stores, während Custom CMS Content ausschließlich die getrennte Funktion unterstützt, für die er vorgesehen ist.
Fehler 9: Mehrsprachigen Content und URL-Beziehungen zu vereinfachen
Was schiefgeht
Sprachen werden als doppelte Textwerte migriert, ohne die Beziehung zwischen primärem Content, übersetztem Content, sprachspezifischen SEO-Feldern und lokalisierten URLs zu erhalten. Product-Übersetzungen, Category-Namen, Checkout-Texte, CMS-Content und Redirects können unvollständig werden oder Besucher auf die falsche Sprachversion führen.
Eine einzige Redirect-Liste ist besonders riskant, wenn sich alte Pfade je Sprache unterscheiden oder die Zielplattform eine andere mehrsprachige URL-Struktur verwendet.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Übersetzungen werden ohne Beziehung zum primären Datensatz gespeichert. | Aktualisierungen können inkonsistente oder verwaiste Sprachversionen erzeugen. |
| Product- und Category-Übersetzungen werden getrennt von Checkout- und E-Mail-Texten geprüft. | Die Customer Journey kann unerwartet zwischen Sprachen wechseln. |
| Redirects werden ohne Sprachspalte oder Zielprüfung vorbereitet. | Besucher können auf der Standardsprachseite oder einem defekten Pfad landen. |
| CMS-Dynamic-Page-URLs sollen sich exakt wie gewöhnliche Pages übersetzen. | Das URL-Verhalten kann je Content-Typ unterschiedlich sein. |
Vorbeugung
Erstellen Sie eine Sprachbeziehungskarte für Products, Categories, CMS-Content, Blog Posts, Menüs, Checkout-Texte, E-Mail-Texte, SEO-Felder und Redirects. Definieren Sie Primärsprache, Übersetzungsverantwortung, Fallback-Verhalten und Ziel-URL-Struktur. Prüfen Sie Redirects im jeweiligen Sprachkontext, statt sie als eine undifferenzierte Liste für die gesamte Website zu behandeln.
| Mehrsprachige Ebene | Präventionsentscheidung |
|---|---|
| Product- und Category-Texte | Beziehung zum primären Commerce-Datensatz erhalten. |
| CMS- und Blog-Content | Übersetzte Felder und die darstellenden Seiten zuordnen. |
| URLs und Redirects | Alte und neue Pfade nach Sprache und Relevanz des Ziels zuweisen. |
| Checkout und Kommunikation | Übersetzte Labels, E-Mails und betriebliche Nachrichten konfigurieren. |
Empfehlungsbeispiel
Ein Store besitzt englische und französische Product-Seiten mit unterschiedlichen alten Pfaden. Ordnen Sie beide Sprachversionen derselben Wix-Stores-Product-Identität zu, erstellen Sie anschließend sprachgerechte Redirects und bestätigen Sie, dass französische Navigation, Product-Texte, Checkout-Labels und E-Mail-Inhalte auf Französisch bleiben.
Bestehensbedingung
Repräsentative Sprachpfade bleiben von der Landingpage über die Product-Auffindbarkeit bis zum Checkout konsistent. Übersetzungen bleiben den richtigen Datensätzen zugeordnet, und prioritäre alte URLs führen zu relevanten Zielen in der vorgesehenen Sprache.
Fehler 10: Davon auszugehen, dass Wix-Automatisierungen und Benachrichtigungen migrierten Datensätzen folgen
Was schiefgeht
Products, Contacts, Members, Orders, Formulare oder CMS-Datensätze erscheinen in Wix, und das Team geht davon aus, dass zugehörige Automatisierungen automatisch funktionieren. Tatsächlich hängen Wix-Automatisierungen von konfigurierten Triggern, Aktionen, Bedingungen, Timing, installierten Apps und teilweise von Velo-Code oder Webhook-Verbindungen ab. Historische Daten stellen diese Workflow-Definitionen nicht wieder her.
Das kann zu stillen Betriebsfehlern führen: Customers erhalten keine Bestätigung, Aufgaben für Mitarbeiter werden nicht erstellt, Leads werden nicht weitergeleitet oder externe Systeme empfangen keine Events mehr.
Frühwarnzeichen
| Warnzeichen | Warum es relevant ist |
|---|---|
| Der Ausgangs-Store besitzt Abandoned-Cart-, Order-, Formular-, Membership- oder Lead-Workflows ohne Zielinventar. | Wichtige Trigger und Aktionen können fehlen. |
| Benachrichtigungen werden aus historischen E-Mails oder Order-Notizen abgeleitet. | Frühere Ausgaben zeigen nicht die vollständige Workflow-Definition. |
| Apps werden erst nach der Automatisierungsplanung installiert. | Verfügbare Trigger und Aktionen können sich mit dem App-Set ändern. |
| Webhooks oder Velo-Aktionen haben keinen Verantwortlichen oder keine Run-Log-Prüfung. | Externe Prozesse können ausfallen, ohne sichtbare Storefront-Fehler zu verursachen. |
Vorbeugung
Inventarisieren Sie jede geschäftskritische Automatisierung nach Trigger, Bedingungen, Aktionen, Timing, Zielgruppe, App-Abhängigkeit, Datenfeldern und externem Endpoint. Bauen Sie nur Workflows neu auf, die weiterhin einem aktuellen Geschäftszweck dienen. Verwenden Sie nach der Konfiguration repräsentative Live-Events, um zu bestätigen, dass der Trigger auslöst, Bedingungen korrekt routen, Aktionen abgeschlossen werden und externe Systeme die erwarteten Daten erhalten.
| Workflow-Typ | Erforderliche Kontrolle |
|---|---|
| Order- oder Cart-Automatisierung | Wix-Stores-Trigger, Customer-Daten, Nachricht, Timing und Ausnahmebehandlung bestätigen. |
| Formular- oder Lead-Automatisierung | Formularquelle, Field Mapping, Zuweisung und Follow-up-Aktion bestätigen. |
| Member-Automatisierung | Rolle, Zugriffsereignis, Benachrichtigung und Membership-Status bestätigen. |
| Webhook- oder Velo-Workflow | Endpoint, Payload, Authentifizierung, Fehlerbehandlung und Run Log bestätigen. |
Empfehlungsbeispiel
Ein Ausgangs-Store sendet Mitarbeitern eine E-Mail, wenn eine hochwertige Order eingeht, und übermittelt Order-Daten an ein ERP. Bauen Sie die interne Benachrichtigung und die externe Übergabe als getrennte Wix-Workflows neu auf. Lösen Sie anschließend eine repräsentative Order aus und bestätigen Sie sowohl die interne Aktion als auch den externen Payload.
Bestehensbedingung
Jede geschäftskritische Automatisierung besitzt einen aktiven Trigger, korrekte Bedingungen, vollständige Aktionen, einen benannten Verantwortlichen und einen erfolgreichen Nachweis anhand eines repräsentativen Ereignisses. Migrierte Datensätze gelten nicht als Nachweis dafür, dass der Workflow selbst existiert.
Übergreifende Prioritäten zur Fehlervermeidung
| Kontrollbereich | Präventionspriorität | Kontrollnachweis |
|---|---|---|
| Wix-Stores-Katalog | Beziehungen zwischen Product, Option, Variante, Medien, Inventory und Category erhalten. | Repräsentative Products bleiben auswählbar, kaufbar und betrieblich nachvollziehbar. |
| Auffindbarkeit auf der Website | Categories, Menüs, Pages, Blog Posts, CMS-Content und Dynamic Pages bewusst miteinander verbinden. | Kunden gelangen von Content und Navigation zu den vorgesehenen Products. |
| Identität | Customers, Contacts, Site Members und App-Teilnehmer nach ihrem Einsatzzweck trennen. | Jeder Identitätstyp behält den benötigten Konto-, Zugriffs- oder Kommunikationskontext. |
| Collections | Wix App Collections von Custom CMS Collections und deren Berechtigungen unterscheiden. | Jede Collection besitzt einen klaren Verantwortlichen und Aktualisierungspfad. |
| Mehrsprachige Struktur | Übersetzten Content, SEO-Felder, URLs und Redirects als zusammenhängende Sprachpfade erhalten. | Prioritäre Pfade bleiben in jeder unterstützten Sprache konsistent. |
| Individuelle Funktionen | Apps, Velo, Service Plugins, externe Systeme und Custom Fields inventarisieren. | Jede Abhängigkeit besitzt eine Zielimplementierung oder einen bewussten Ausschluss. |
| Automatisierungen | Trigger, Bedingungen, Aktionen und Integrationen getrennt von Datensätzen neu aufbauen. | Repräsentative Events führen den vorgesehenen internen und externen Workflow aus. |
Fazit
Typische Fehler bei einer Wix-Migration lassen sich vermeiden, wenn Wix Stores, CMS Collections, Site Members, Content, mehrsprachiges Routing, Apps, Velo-Logik und Automatisierungen als verbundene, aber getrennt verantwortete Systeme behandelt werden. Ein gefülltes Dashboard reicht nicht aus, wenn die falsche Collection Daten besitzt, Übersetzungen ihre Beziehungen verlieren oder Workflow-Trigger nicht mehr existieren.
Eine belastbare Migration bewahrt plattformspezifische Tiefe und hält die Entscheidung zugleich klar. Ursache und Auswirkung sind nachvollziehbar, Warnzeichen und Zuständigkeitsgrenzen lassen sich vergleichen, und Bestehensbedingungen zeigen, dass das Verhalten der Zielplattform tatsächlich nutzbar ist.
Häufige Fragen
Warum ist Wix mehr als ein generisches Ziel für einen gehosteten Store?
Wix verbindet Wix Stores mit Pages, Blog-Content, CMS Collections, Site Members, Apps, Mehrsprachigkeitsfunktionen, Velo-Code und Automatisierungen. Diese Ebenen können denselben Customer oder Product referenzieren und dennoch unterschiedliche Zuständigkeiten und Berechtigungen besitzen.
Was ist der wichtigste Fehler bei der Product-Struktur in Wix Stores?
Optionen und Varianten der Ausgangsplattform lassen sich möglicherweise nicht direkt in die Beziehungen zwischen Wix Product, Option, Choice, Variante, Medien, Preis und Inventory übertragen. Prüfen Sie komplexe Products nach ihrem tatsächlichen Kaufverhalten statt nach der Product-Anzahl.
Sind Wix CMS Collections dasselbe wie Wix Stores Collections?
Nein. Wix App Collections stellen app-eigene Daten bereit und werden von der jeweiligen App verwaltet. Custom CMS Collections besitzen eigene Felder, Berechtigungen und Einsatzbereiche für Dynamic Pages; sie werden dadurch nicht automatisch zu einem operativen Store-Katalog.
Wie sollten Customers, Contacts und Site Members voneinander getrennt werden?
Klassifizieren Sie jede Identität nach der Funktion, die sie unterstützen muss: Commerce-Historie, Marketingkommunikation, Website-Login, geschützter Content, Loyalty, Booking oder eine andere app-spezifische Beziehung. Erhalten Sie nur Bedeutungen, für die es auf der Zielplattform einen klaren Verantwortlichen gibt.
Warum ist eine mehrsprachige Wix-Migration besonders fehleranfällig?
Übersetzungen, Product-Texte, CMS-Content, SEO-Felder, Checkout-Sprache und Redirects müssen mit den richtigen primären Datensätzen und sprachspezifischen Pfaden verbunden bleiben. Eine einzige generische Redirect- oder Übersetzungsliste reicht dafür nicht aus.
Werden Wix-Automatisierungen fortgesetzt, sobald Datensätze migriert wurden?
Nein. Automatisierungen benötigen konfigurierte Trigger, Bedingungen, Aktionen, Timing, App-Abhängigkeiten und teilweise Velo-Code oder Webhooks. Bauen Sie die Workflows neu auf und lösen Sie repräsentative Ereignisse aus, um ihre Funktion nachzuweisen.