Wenn Shift4Shop als mögliche Zielplattform eingesetzt wird, bleiben Migrationsprobleme häufig verborgen, weil die Storefront vollständig wirkt, bevor die zugrunde liegenden Verkaufsregeln korrekt übertragen wurden. Products können sichtbar sein, obwohl der Bestand auf Optionsebene falsch ist. Customers können vorhanden sein, obwohl Group-Zugriff und Price Levels nicht mehr zusammenhängen. Orders können lesbar sein, während Mitarbeiter Status, Rabatte oder Fulfillment-Historie nicht nachvollziehen können. Die zuverlässigste Prävention besteht deshalb darin, die geschäftliche Funktionsweise jedes Datensatzes zu prüfen und nicht nur sein Vorhandensein.
Die folgenden Fehlerbilder konzentrieren sich auf wiederkehrende Probleme bei einer Migration zu Shift4Shop. Jedes beschreibt die betriebliche Folge, die frühen Warnzeichen und die Bedingung, die beweist, dass genau dieser Fehler verhindert wurde.
Fehler 1: Product Options und Advanced Options als dieselbe Struktur behandeln
Was schiefgeht
Auswählbare Varianten eines Quell-Products werden als gewöhnliche Options übertragen, obwohl bestimmte Kombinationen eine eigene SKU, GTIN, einen eigenen Bestand, ein eigenes Gewicht, eigene Kosten oder eine eigene Preisbedeutung besitzen. Die Storefront zeigt die Auswahlmöglichkeiten, aber Bestand, Versand, Einkauf oder Reporting verwenden das Parent Product statt der gewählten Kombination.
Shift4Shop kann Product Options für die Auswahl durch Customers und Advanced Options für kommerzielle Daten auf Kombinationsebene verwenden. Werden beide Ebenen zusammengefasst, geht der Unterschied zwischen einer sichtbaren Auswahl und einer eigenständig verfolgten verkaufbaren Konfiguration verloren.
Frühe Warnzeichen
| Warnzeichen | Wahrscheinliche Folge |
|---|---|
| Eine Quellvariante besitzt eine eigene SKU oder Bestandsmenge. | Sie wird nur als Darstellungsoption angelegt. |
| Optionskombinationen ändern Gewicht oder Kosten. | Versand- und Margenberichte verwenden die Parent-Werte. |
| Unterschiedliche Customer Groups sollen unterschiedliche Optionspreise sehen. | Eine Optionsanpassung wird auf alle Price Levels angewendet. |
| Die Quelle enthält deaktivierte oder nicht verfügbare Kombinationen. | Shift4Shop bietet Kombinationen an, die nicht verkauft werden sollen. |
Prävention
Klassifizieren Sie jede Product-Auswahl danach, welche Daten sie steuert. Verwenden Sie gewöhnliche Options für Auswahlverhalten, das keine eigenständige Verfolgung benötigt. Verwenden Sie Advanced Options, wenn eine Kombination eigenen Bestand, eigene Kennungen, eigenes Gewicht, eigene Kosten oder andere kommerzielle Merkmale benötigt.
Dokumentieren Sie, wo Optionspreis-Anpassungen global gelten und wo eine Group-spezifische Behandlung erforderlich ist. Gehen Sie nicht davon aus, dass der Preis des Parent Products plus ein einzelner Optionsaufschlag jede Preisregel der Quelle reproduziert.
Empfehlungsbeispiel
Vergleichen Sie bei einem Bekleidungs-Product mit Größe und Farbe mindestens eine verfügbare Kombination, eine deaktivierte Kombination und eine Kombination mit abweichendem Gewicht oder Preis. Bestätigen Sie, dass die gewählte Option die erwartete SKU, den richtigen Bestand und die richtigen Order-Line-Details erzeugt.
Pass-Bedingung
Repräsentative Optionskombinationen bewahren vorgesehene Verfügbarkeit, Kennungen, Preis, Bestand, Gewicht und resultierende Order-Details, ohne doppelte oder unmögliche Konfigurationen zu erzeugen.
Fehler 2: Categories erhalten, aber die Discovery verschlechtern
Was schiefgeht
Category-Namen werden migriert, doch die Storefront führt Käufer nicht mehr durch dieselben Discovery-Pfade. Parent-Child-Hierarchie, Product-Zuordnungen, Sichtbarkeitsregeln, SmartCategory-Logik, Menüplatzierung, Breadcrumbs und Prioritätsrouten können abweichen, obwohl jeder Category-Datensatz vorhanden ist.
Besonders leicht wird der Fehler übersehen, wenn der Quellshop dynamische oder kuratierte Gruppierungen statt einer einfachen statischen Hierarchie verwendet hat.
Frühe Warnzeichen
| Discovery-Ebene | Warnzeichen |
|---|---|
| Parent Categories | Children erscheinen auf falscher Ebene oder ohne nutzbare Landingpage. |
| SmartCategories | Mitgliedschaftsregeln werden durch eine einmalig importierte Product-Liste ersetzt. |
| Group-beschränkte Categories | Die Category ist für die falsche Customer Group sichtbar. |
| Suche und Navigation | Wichtige Products sind vorhanden, aber schwer erreichbar. |
| Historische Routen | Alte Category-URLs haben kein relevantes Ziel. |
Prävention
Ordnen Sie Categories nach ihrem Zweck ein: Navigation, Merchandising, Zugriffskontrolle, Kampagnengruppierung oder SEO-Landingpage. Bewahren Sie die Hierarchie nur, wenn sie den Zielshop weiterhin unterstützt. Bauen Sie dynamische oder manuell kuratierte Mitgliedschaften neu auf, wenn ein statischer Import schnell veralten würde.
Erstellen Sie eine Routen- und Discovery-Karte für Categories, die Umsatz, organischen Traffic oder eingeschränkten Zugriff tragen. Menü- und Breadcrumb-Funktionsweise gehören zur Darstellung im Ziel und dürfen nicht als automatische Folge migrierter Category-Datensätze vorausgesetzt werden.
Empfehlungsbeispiel
Wählen Sie einen tiefen Category-Pfad, eine SmartCategory oder dynamisch gepflegte Gruppierung und eine Group-beschränkte Category. Verfolgen Sie, wie ein Käufer jede Seite erreicht und welche Products dort erscheinen sollen.
Pass-Bedingung
Prioritäts-Products bleiben über die vorgesehenen Category-, Such-, Menü- und Breadcrumb-Pfade auffindbar; eingeschränkte oder dynamische Gruppierungen bewahren ihren geschäftlichen Zweck.
Fehler 3: Customer Groups ohne ihre Preis- und Zugriffsregeln migrieren
Was schiefgeht
Customers werden Groups zugeordnet, aber Price Level, Minimum Order, Product-Sichtbarkeit, Category-Zugriff, Content-Zugriff sowie verfügbare Payment- oder Shipping-Methoden der Group werden nicht neu eingerichtet. Die Group-Bezeichnung bleibt erhalten, während sich die Behandlung des Käufers verändert.
Shift4Shop Customer Groups können mit Price Levels und Zugriffsbeschränkungen zusammenwirken. Eine Group ist daher mehr als Segmentierung: Sie kann bestimmen, was ein Customer sieht und wie er einkauft.
Frühe Warnzeichen
| Group-Abhängigkeit | Fehlerbild |
|---|---|
| Price Level | Der Customer meldet sich an, sieht aber Retail-Preise. |
| Product- oder Category-Zugriff | Eingeschränkte Ware wird öffentlich oder verschwindet für berechtigte Käufer. |
| Minimum Order | Wholesale Customers können unterhalb des vorgesehenen Schwellenwerts auschecken. |
| Verfügbarkeit von Shipping oder Payment | Eine Group erreicht den Checkout, hat aber keine gültige Methode. |
| Steuerbehandlung | Die Group wird fälschlich besteuert oder befreit. |
Prävention
Erstellen Sie eine Customer-Group-Regelmatrix, die jede Group mit ihrem Price Level, den Zugriffskontrollen, Checkout-Anforderungen, der Steuerbehandlung und dem Kommunikationszweck verbindet. Weisen Sie Customers erst zu, nachdem die Regeln der Ziel-Group definiert sind.
Verwendet die Quelle kontospezifische Preise statt Group-Preise, muss dieser Unterschied sichtbar bleiben. Komprimieren Sie verhandelte Preislisten nicht in eine breite Group, sofern das Unternehmen diese Änderung nicht ausdrücklich freigegeben hat.
Empfehlungsbeispiel
Verwenden Sie einen Retail Customer, einen Wholesale Customer und einen Customer mit eingeschränktem Zugriff. Bestätigen Sie Products, Categories, Preise, Mindestbestellwert, Steuerverhalten und Checkout-Methoden, die jeder Customer erhalten soll.
Pass-Bedingung
Repräsentative Customers erhalten nach der Anmeldung das richtige Price Level, den korrekten Katalogzugriff, das richtige Minimum-Order-Verhalten, die richtige Steuerbehandlung sowie die vorgesehenen Shipping- und Payment-Methoden.
Fehler 4: Mengenpreise, Rabatte, Coupons und Guthabenwerte vereinfachen
Was schiefgeht
Kommerzielle Regeln bleiben als Namen oder historische Beträge erhalten, aber ihre Auslösebedingungen gehen verloren. Mengenstaffeln können für die falsche Group gelten, Coupons Product- oder Category-Ausschlüsse ignorieren, Optionspreis-Anpassungen anders rechnen oder die Historie von Gift Certificates kann fälschlich als aktives Guthaben behandelt werden.
Ein sichtbarer Rabattdatensatz beweist nicht, dass die Zielberechnung der Quelle entspricht. Umfang, Berechtigung, Anwendungsreihenfolge und fortbestehende Verantwortung der Regel müssen verstanden werden.
Frühe Warnzeichen
| Kommerzielle Regel | Warnzeichen |
|---|---|
| Quantity Pricing | Nur eine Mengenstufe wird geprüft. |
| Customer-Group-Preise | Für jede Group erscheint derselbe Product-Preis. |
| Coupon | Der Code funktioniert, ignoriert aber Ausschlüsse oder Schwellenwerte. |
| Gift Certificate | Historische Codes werden ohne Abstimmung als aktive Verbindlichkeiten behandelt. |
| Optionspreis-Anpassung | Der Aufschlag stimmt für Retail, aber nicht für ein anderes Price Level. |
Prävention
Inventarisieren Sie jede Regel, die den vom Käufer gezahlten Betrag verändert. Dokumentieren Sie berechtigten Customer, Product- oder Category-Umfang, Mengenschwelle, Zeitraum, Stacking-Verhalten und Owner. Trennen Sie historische Evidenz von aktiven Guthaben und aktiven Berechnungsregeln.
Erfordert Shift4Shop eine andere Regelstruktur, definieren Sie das beabsichtigte Ergebnis, statt die Quellkonfiguration wörtlich nachzubauen.
Empfehlungsbeispiel
Verwenden Sie einen Warenkorb mit einem mengenbepreisten Product, einem Optionsaufschlag und einem Coupon mit Berechtigungsbeschränkung. Vergleichen Sie das erwartete Ergebnis für einen Retail- und einen Wholesale Customer.
Pass-Bedingung
Repräsentative Warenkörbe erzeugen nachvollziehbare und freigegebene Summen; aktive Gift-, Coupon- und Preisverpflichtungen werden abgestimmt und nicht aus historischen Datensätzen abgeleitet.
Fehler 5: Orders erhalten, aber den für Mitarbeiter nutzbaren Kontext verlieren
Was schiefgeht
Orders werden mit Nummern, Daten, Customers und Summen migriert, doch Mitarbeitern fehlen Statushistorie, Payment-Bezeichnung, Shipping Method, Tracking-Referenz, Rabattbegründung, interne Notiz, CRM-Beziehung oder Ausnahmekontext, die sie für den Customer-Support benötigen.
Das Problem tritt häufig auf, wenn nur abgeschlossene Orders geprüft werden. Stornierte, erstattete, teilweise versendete, manuell angepasste oder Wholesale Orders enthalten oft genau die Informationen, die schwaches Mapping sichtbar machen.
Frühe Warnzeichen
| Order-Stichprobe | Verdecktes Risiko |
|---|---|
| Abgeschlossene Retail Order | Basisfelder bestehen, Ausnahmebehandlung bleibt ungetestet. |
| Rabattierte Order | Die Endsumme ist vorhanden, aber der Grund fehlt. |
| Wholesale Order | Group- und Price-Level-Kontext ist nicht sichtbar. |
| Erstattete oder stornierte Order | Status- und Payment-Evidenz werden vereinfacht. |
| Order mit CRM- oder Affiliate-Daten | Mitarbeiter können die zugehörige Historie nicht verfolgen. |
Prävention
Definieren Sie den freigegebenen Zweck historischer Orders und die dafür benötigte Evidenz. Bewahren Sie lesbare Products, Optionsauswahlen, Customer-Verknüpfungen, Summen, Steuern, Rabatte, Status, Versand, Tracking, Payment-Bezeichnungen und relevante Notizen.
Ordnen Sie Quellstatus klaren historischen Bedeutungen zu. Weisen Sie einer importierten Order keinen aktiven Betriebsstatus zu, sofern der Shop nicht bewusst möchte, dass Mitarbeiter diese Order weiterbearbeiten.
Empfehlungsbeispiel
Prüfen Sie eine gewöhnliche Order, eine Wholesale Order, eine rabattierte Order, eine erstattete oder stornierte Order und eine Order mit Details auf Optionsebene. Ein Mitarbeiter sollte erklären können, was passiert ist, ohne die Quellplattform aufzurufen.
Pass-Bedingung
Mitarbeiter können repräsentative Order-Historien einschließlich Ausnahmen und kommerziellem Kontext verstehen, ohne importierte Datensätze mit aktiven Fulfillment- oder Payment-Aufgaben zu verwechseln.
Fehler 6: Shipping-, Payment- und Checkout-Fragen als Customer-Daten behandeln
Was schiefgeht
Die Migration erhält Customer Groups und historische Orders, deshalb nimmt das Team an, Shipping Methods, Payment Methods, Checkout Questions, Steuerregeln und Kaufbeschränkungen würden automatisch folgen. Diese Elemente sind Live-Konfigurationen des Stores und können je Customer Group variieren.
Eine Group kann deshalb im Customer-Datensatz korrekt aussehen, während ihre Mitglieder keine gültige Shipping Method, die falsche Payment Method oder unvollständige Checkout-Informationen vorfinden.
Frühe Warnzeichen
| Checkout-Abhängigkeit | Warnzeichen |
|---|---|
| Group-spezifischer Versand | Alle Methoden sind nur für die Default Group konfiguriert. |
| Group-spezifische Zahlung | Wholesale Customers können den freigegebenen Zahlungsweg nicht auswählen. |
| Checkout Questions | Erforderliche Geschäftsinformationen werden nicht erfasst. |
| Mindestkaufregeln | Der Ziel-Checkout erzwingt den beabsichtigten Schwellenwert nicht. |
| Steuerbefreite Group | Customer-Daten sind vorhanden, aber der Checkout berechnet weiterhin Steuer. |
Prävention
Führen Sie eine separate Ownership-Matrix für den Live Checkout, unabhängig von migrierten Customer- und Order-Datensätzen. Definieren Sie für jede Customer Group verfügbare Payment- und Shipping-Methoden, Mindestbestellregeln, Steuerbehandlung und erforderliche Checkout Questions.
Verwenden Sie historische Payment- oder Shipping-Bezeichnungen nicht als Konfigurationsanweisung, ohne zu bestätigen, dass die Methoden im Zielshop weiterhin gültig sind.
Empfehlungsbeispiel
Führen Sie einen repräsentativen Checkout als Retail Customer und als Wholesale Customer durch. Beide Sitzungen sollten den vorgesehenen Katalog, die korrekten Preise, Shipping, Payment, Steuerbehandlung und erforderlichen Fragen zeigen.
Pass-Bedingung
Jede aktive Customer Group kann den vorgesehenen Checkout-Pfad mit mindestens einer gültigen Shipping- und Payment-Methode sowie den richtigen Beschränkungen und Fragen abschließen.
Fehler 7: Inhalte und SEO als reine Redirect-Aufgabe behandeln
Was schiefgeht
Das Team mappt alte URLs, bewahrt aber Inhalte, Hierarchie, Metadaten, interne Links oder den Käuferzweck der Zielseiten nicht. Product- und Category-Routen können weiterleiten, während Landingpages, Informationsseiten, Blog-Inhalte und Kampagnenpfade verschwinden oder auf irrelevante Seiten führen.
Redirects schützen Kontinuität nur, wenn das Ziel die ursprüngliche Intention erfüllt. Selbst eine technisch erfolgreiche Weiterleitung auf die Startseite kann Discovery und Conversion verschlechtern.
Frühe Warnzeichen
| Seitentyp | Risiko |
|---|---|
| Product-Seite | Das Ziel-Product unterscheidet sich oder wichtige Inhalte fehlen. |
| Category-Seite | Die Hierarchie existiert, aber die Seite unterstützt Discovery nicht mehr. |
| Informationsseite | Richtlinie, Support- oder Kaufberatung fehlt. |
| Eingeschränkte Inhaltsseite | Zugriffsregeln gehen bei der Neuerstellung der Route verloren. |
| Kampagnen-Landingpage | Alte Links funktionieren, aber Angebot oder Kontext existieren nicht mehr. |
Prävention
Klassifizieren Sie Prioritäts-URLs nach Seitentyp, Traffic-Wert, Backlinks, Kampagnennutzung und Zielintention. Verbinden Sie Routenentscheidungen mit Content-Entscheidungen. Bauen Sie Seiten neu auf oder konsolidieren Sie sie, bevor Redirects aktiviert werden, damit das Ziel bereits sinnvoll ist.
Bewahren Sie interne Links und Navigationsverweise auf Prioritätsinhalte. Nehmen Sie veraltete Seiten bewusst außer Betrieb, statt zufällige Fehler entstehen zu lassen.
Empfehlungsbeispiel
Ordnen Sie eine stark frequentierte Product-URL, eine Category-URL, eine Wholesale-Informationsseite und eine Kampagnen-Landingpage zu. Jede sollte auf ein Ziel führen, das denselben Käuferzweck unterstützt.
Pass-Bedingung
Prioritäts-URLs der Quelle führen auf relevante, veröffentlichte und erreichbare Shift4Shop-Ziele, bewahren die ursprüngliche Käuferintention und verwenden keine pauschale Weiterleitung, um fehlende Inhalte zu kaschieren.
Fehler 8: Native Felder, benutzerdefinierte Daten und integrationsgebundene Werte vermischen
Was schiefgeht
Historische 3dcart- oder Shift4Shop-Felder, benutzerdefinierte Felder, ERP-Kennungen, Marketplace-Attribute und reine Reporting-Werte werden in das nächstgelegene verfügbare Zielfeld kopiert. Die Daten bleiben sichtbar, verlieren aber Datensatzebene, Format oder Ownership, die Integrationen und Mitarbeiter erwarten.
Dieselbe Bezeichnung kann unterschiedliche Dinge meinen: ein natives Shift4Shop-Feld, ein benutzerdefiniertes Feld, einen veralteten Quell-Workaround oder einen durch ein externes System gepflegten Wert. Werden sie gleich behandelt, entstehen Synchronisations- und Reporting-Fehler.
Frühe Warnzeichen
| Datentyp | Ownership-Risiko |
|---|---|
| Natives Product-Feld | Es wird für unzusammenhängende externe Metadaten zweckentfremdet. |
| Benutzerdefiniertes Feld | Kein Mitarbeiter und keine Integration ist als Consumer benannt. |
| ERP- oder Marketplace-ID | Sie wandert von der Variante zum Parent Product. |
| Historische 3dcart-Referenz | Der Wert dokumentiert alte Logik, die nicht mehr existiert. |
| Benutzerdefiniertes Report-Feld | Der Zielreport liest den migrierten Speicherort nicht. |
Prävention
Erstellen Sie ein Field-Ownership-Ledger mit Quell- und Zieldatensatz, erwartetem Format, fortbestehendem Consumer, Schreibverantwortung und Entscheidung über Beibehaltung oder Ausmusterung. Externe Kennungen müssen exakt auf der Ebene erhalten bleiben, die die weiterverwendete Integration nutzt.
Migrieren Sie einen Wert nicht allein deshalb, weil er verfügbar ist. Schließen Sie veraltete Felder aus und bauen Sie aktive Logik in dem System neu auf, das sie künftig besitzt.
Empfehlungsbeispiel
Verfolgen Sie bei einer ERP-angebundenen Product-Familie Parent-Product-ID, Option- oder Advanced-Option-SKU, Bestands-Owner und Order-Line-Kennung durch das Ziel. Bestätigen Sie, dass das ERP nach dem Cutover dieselben Beziehungen liest.
Pass-Bedingung
Jeder beibehaltene benutzerdefinierte oder integrationsgebundene Wert besitzt einen benannten Consumer, die richtige Datensatzebene, ein stabiles Format, einen funktionierenden Reporting-Pfad im Ziel und eine eindeutige Schreibverantwortung nach dem Cutover.
Fehler 9: Theme- und App-Ausgabe nachbauen, ohne ihre Datenabhängigkeiten wiederherzustellen
Was schiefgeht
Das Ziel-Theme ähnelt optisch dem Quellshop, aber die zugrunde liegende App, der Feed, das benutzerdefinierte Script, Product-Feld, die Category-Regel oder der Content-Block, die das Erlebnis erzeugt haben, fehlen. Suche, Empfehlungen, Product Badges, Reviews, Feeds oder eingeschränkte Inhalte wirken danach unvollständig oder statisch.
Darstellung ist häufig nur das Endergebnis mehrerer Datenbeziehungen. Das Kopieren von Markup oder Design stellt diese Beziehungen nicht wieder her.
Frühe Warnzeichen
| Quellfunktion | Verdeckte Abhängigkeit |
|---|---|
| Product Badge oder Label | Ein benutzerdefiniertes Product-Feld oder eine Regel liefert den Wert. |
| Gefilterte Landingpage | Eine SmartCategory oder ein Script steuert die Mitgliedschaft. |
| Review-Darstellung | Product-Kennungen verknüpfen den Review-Datensatz. |
| Marketplace Feed | Benötigte Attribute stammen aus benutzerdefinierten Daten oder Daten auf Optionsebene. |
| Group-spezifische Inhalte | Customer-Group-Sicherheit steuert die Sichtbarkeit. |
Prävention
Inventarisieren Sie Theme-Komponenten und Apps nach den Daten, die sie konsumieren. Entscheiden Sie für jede Abhängigkeit, ob sie als native Shift4Shop-Konfiguration, App, benutzerdefiniertes Feld, Integration oder bewusst nicht beibehaltene Funktion weitergeführt wird. Bauen Sie den Datenfluss neu auf, bevor die Darstellung rekonstruiert wird.
Entfernen Sie veraltete Scripts, statt sie ohne Owner in das Ziel mitzunehmen.
Empfehlungsbeispiel
Nehmen Sie eine umsatzkritische Product-Seite mit Reviews, Filtern, Badges und Daten auf Optionsebene. Identifizieren Sie jedes Quellfeld und jede App, die das sichtbare Erlebnis steuert, und bestätigen Sie anschließend den Ziel-Owner jeder Abhängigkeit.
Pass-Bedingung
Prioritäre Storefront-Komponenten erhalten aktuelle Daten von einem definierten Ziel-Owner und hängen weder von kopiertem Markup noch von verwaisten Scripts oder veralteten Quellfeldern ab.
Übergreifende Präventionsmatrix
| Kontrollbereich | Abgedeckte Fehler | Erforderliches Ergebnis |
|---|---|---|
| Product-Beziehungsmodell | 1, 2, 4 | Options, Advanced Options, Categories und Preisregeln bewahren die Verkaufsbedeutung. |
| Matrix für Customer-Behandlung | 3, 6 | Groups, Price Levels, Zugriff, Steuer, Shipping, Payment und Checkout-Regeln bleiben verbunden. |
| Modell für historische Evidenz | 5 | Orders bleiben verständlich, ohne zu aktiven Betriebsaufgaben zu werden. |
| Routen- und Content-Inventar | 2, 7 | Discovery und wichtige eingehende Pfade bleiben bewusst gesteuert. |
| Field- und Dependency-Ownership | 8, 9 | Benutzerdefinierte Daten, Apps, Themes und Integrationen besitzen fortbestehende Owner. |
Fazit
Die Qualität einer Shift4Shop-Migration hängt davon ab, die Beziehungen zwischen Product-Struktur, Customer-Behandlung, kommerziellen Regeln, Store-Konfiguration und betrieblicher Evidenz zu erhalten. Ein sichtbarer Katalog genügt nicht, wenn Options, Price Levels, Checkout-Zugriff oder App-eigene Daten nicht mehr korrekt funktionieren. Hat jedes Fehlerbild einen eindeutigen Owner, ein repräsentatives Szenario und eine Pass-Bedingung, kann der Store seine kommerzielle Logik bewahren, ohne die Analyse auf eine generische Checkliste zu reduzieren.
Häufige Fragen
Warum kann ein Shift4Shop-Shop vollständig aussehen und trotzdem kommerziell falsch sein?
Sichtbare Datensätze beweisen nicht, dass Bestand auf Optionsebene, Customer-Group-Preise, Category-Zugriff, Rabatte, Shipping- oder Payment-Regeln miteinander verbunden sind. Diese Beziehungen brauchen eine eigene Prüfung.
Wann sollte eine Quellvariante zu einer Advanced Option werden?
Verwenden Sie die Advanced-Option-Struktur, wenn eine Kombination eine eigene SKU, eigenen Bestand, eigenes Gewicht, eigene Kosten, GTIN oder vergleichbare kommerzielle Daten benötigt. Eine reine Anzeigeauswahl kann eine gewöhnliche Product Option bleiben.
Warum sind Customer Groups ein wichtiges Migrationsrisiko?
Eine Group kann Price Levels, Mindestbestellungen, Katalogzugriff, Steuerbehandlung, Inhalte, Payment und Shipping steuern. Wird nur der Group-Name migriert, ohne diese Beziehungen wiederherzustellen, verändert sich die Behandlung des Käufers.
Sollten historische Gift Certificates als aktive Guthaben behandelt werden?
Nicht automatisch. Aktive Verbindlichkeiten sollten abgestimmt und bewusst eingerichtet werden. Historische Order-Evidenz allein beweist nicht, dass ein Code oder Guthaben weiterhin gültig ist.
Warum können ältere 3dcart-Felder bei einer Shift4Shop-Migration problematisch sein?
Bestimmen Sie für jedes Feld, ob es nativ, benutzerdefiniert, integrationsgebunden, nur für Reporting genutzt oder veraltet ist. Bewahren Sie nur Werte mit definiertem Zieldatensatz und fortbestehendem Consumer.
Wie sollten Theme- und App-Abhängigkeiten beim Wechsel zu Shift4Shop behandelt werden?
Inventarisieren Sie Felder, Apps, Scripts, Regeln und Integrationen, die wichtige Storefront-Erlebnisse steuern. Weisen Sie jeder Abhängigkeit einen fortbestehenden Ziel-Owner zu, etwa native Shift4Shop-Konfiguration, eine App, ein benutzerdefiniertes Feld, eine Integration oder eine bewusst ausgemusterte Funktion. Stellen Sie den erforderlichen Datenfluss wieder her, bevor die Darstellung nachgebaut wird, und nehmen Sie nicht an, dass kopiertes Markup die zugrunde liegende Abhängigkeit automatisch rekonstruiert.