Wenn Shift4Shop als mögliche Zielplattform ausgewählt wird, sollte die Vorbereitung dokumentieren, wie der Quellshop über Products, gewöhnliche Optionen, Advanced Options, Product Extra Fields, Categories, SmartCategories, Customer Groups, Price Levels, Customers, Orders, Content, Module und externe Systeme abgebildet werden soll. Langjährig betriebene Stores können außerdem 3dcart-Bezeichnungen, Exporte, benutzerdefinierte Felder und Integrationen enthalten, deren heutige Bedeutung am Feldnamen allein nicht erkennbar ist.
Das Vorbereitungspaket sollte Zugriff, Nachweise, Verantwortlichkeiten und klare Bereitschaftsbedingungen zusammenführen. Ziel ist, die Logik des Quellshops explizit zu machen, bevor der repräsentative Satz an Migrationsmustern zusammengestellt wird.
Annahmen für die Shift4Shop-Zielplattform dokumentieren
Beginnen Sie mit den Annahmen zum künftigen Betrieb, die die Datenvorbereitung beeinflussen.
| Bereich | Zu dokumentierende Entscheidung | Nachweis |
|---|---|---|
| Product-Identität | Welche Quelldatensätze zu Basis-Products werden und welche Optionskombinationen eine eigene kommerzielle Identität benötigen | Product-Family-Matrix |
| Optionsverhalten | Welche Auswahlmöglichkeiten gewöhnliche Optionen bleiben und welche Advanced Options oder einen anderen Eigentümer benötigen | Beispiele für Optionen und Kombinationen |
| Katalogauffindbarkeit | Welche Quell-Categories statisch, dynamisch, navigativ, suchbar oder veraltet sind | Klassifizierung von Categories und SmartCategories |
| Käuferbehandlung | Welche Customer Groups, Price Levels, Zugriffsregeln und benutzerdefinierten Felder erhalten bleiben | Gruppen- und Preisinventar |
| Historische Orders | Welche Positionsdetails, Statuswerte, Rabatte, Rewards, Affiliate- und externe Referenzen Mitarbeiter benötigen | Repräsentatives Order-Paket |
| Legacy- und benutzerdefinierte Datensätze | Welche 3dcart-Felder, Module, Apps oder externen IDs weiterhin aktiv sind | Herkunfts- und Abhängigkeitsregister |
Eine Option im Quell-Product sollte nicht allein deshalb Advanced Options zugeordnet werden, weil sie mehrere Werte besitzt. Entscheidend ist, ob die Kombination SKU, Bestand, GTIN, Gewicht, Preis, Bild, Verfügbarkeit oder einen anderen eigenständig verwalteten Wert besitzt. Dokumentieren Sie diese Entscheidung auf Ebene der Product-Familie, damit ähnliche Products einer kontrollierten Regel folgen und nicht während der Migration unterschiedlich interpretiert werden.
Zugriff, Exporte und einen Snapshot des Quellshops vorbereiten
Sammeln Sie den Zugriff und die Nachweise, die benötigt werden, um den Quellshop zu verstehen und Shift4Shop vorzubereiten.
Dazu gehören:
- Administratorzugriff auf Quellshop und Shift4Shop mit geeigneten Berechtigungen;
- Exporte für Products, Optionen, Customers, Orders, Categories, Content und Weiterleitungen, soweit verfügbar;
- Medien- und Dateiarchive, wenn Quelllinks geschützt oder nur temporär gültig sind;
- Definitionen von Customer Groups und Price Levels;
- Definitionen und Beispiele für Product Extra Fields;
- Regeln für SmartCategories und Zuordnungen gewöhnlicher Categories;
- Datensätze aus Modulen, Apps, Affiliate-, Reward-, CRM-, Waiting-List- und Review-Systemen, sofern im Umfang;
- externe IDs aus ERP-, Buchhaltungs-, Fulfillment-, Marketplace- oder CRM-Systemen;
- datierte Backups des Quellshops sowie eine Aufstellung der Daten, die sich bis zum Migrationsfenster voraussichtlich ändern.
| Nachweis | Bereitschaftsbedingung |
|---|---|
| Zugriffsprotokoll | Erforderliche Verwaltungsbereiche sind erreichbar und verantwortliche Ansprechpartner bekannt |
| Exportarchiv | Dateien lassen sich öffnen, enthalten die erwarteten Datensätze und besitzen ein eindeutiges Exportdatum |
| Feld- und Modulverzeichnis | Wichtige benutzerdefinierte oder ältere Werte besitzen Zweck und Eigentümer |
| Product-Musterliste | Gewöhnliche und außergewöhnliche Optionsstrukturen sind vertreten |
| Order-Musterliste | Historische Statuswerte, Anpassungen und externe Referenzen sind vertreten |
Products, Optionen und Advanced Options vorbereiten
Gewöhnliche Shift4Shop-Optionen können Käuferauswahl sowie Preis- oder Gewichtsanpassungen steuern, während Advanced Options bestimmten Kombinationen eigene kommerzielle Felder geben können. Bereiten Sie Product-Beispiele vor, die diesen Unterschied sichtbar machen.
Berücksichtigen Sie:
- einfache Products;
- Products mit gewöhnlichem Dropdown-, Radio-, Bild-, Text- oder anderem Optionsverhalten;
- Products mit Advanced Options und Kombinationsebene für Code, GTIN, Bestand, Gewicht, Preis, Bild oder Verfügbarkeit;
- Products, die Category-basierte Optionsvererbung verwenden;
- Products mit Extra Fields, Manufacturer IDs, Search Keywords oder spezialisierten Product-Metadaten;
- Kits, Bundles, digitale Products, Waiting-List-Funktionen, Abonnements oder app-eigene Konfiguration;
- Products, deren Preis oder Sichtbarkeit je Customer Group oder Price Level variiert;
- Products, die mit einem externen Bestands- oder Katalogsystem synchronisiert werden.
| Quellverhalten | Vorbereitungsentscheidung für Shift4Shop | Erforderlicher Nachweis |
|---|---|---|
| Option verändert Auswahl, besitzt aber keinen eigenen Bestand | Gewöhnliche Product Option | Optionstyp, Werte, Preis-/Gewichtswirkung und Order-Line-Beispiel |
| Kombination besitzt eigene SKU, Bestand, GTIN, Gewicht oder Bild | Advanced Option | Kombinationsmatrix und Quellkennungen |
| Wert beschreibt das Product | Extra Field, Beschreibung, Search Field oder externe Metadaten | Feldzweck, Datentyp und Consumer |
| Auswahl wird einmalig vom Käufer eingegeben | Text- oder Custom-Input-Beziehung | Storefront-Beispiel und Order-Line-Nachweis |
| Logik wird durch App oder individuellen Code erzeugt | App oder externer Eigentümer | Regelbeschreibung, zugehörige Datensätze und externe IDs |
Normalisieren Sie Optionsnamen, Product Codes, Manufacturer IDs und die Bedeutung von Extra Fields vor der Migration. Ein Exportlabel aus der 3dcart-Ära sollte mit dem tatsächlichen aktuellen Workflow verbunden werden und nicht allein deshalb erhalten bleiben, weil es existiert.
Categories, SmartCategories, Suche und URLs vorbereiten
Gewöhnliche Shift4Shop Categories enthalten zugewiesene Products. SmartCategories können sich dagegen dynamisch aus Regeln wie Sale-Status, Veröffentlichungszeitpunkt, Versandbehandlung oder Keywords befüllen. Bereiten Sie beide Strukturen getrennt vor.
| Quellgruppierung | Zielfrage | Bereitschaftsnachweis |
|---|---|---|
| Stabile Category | Soll die Product-Mitgliedschaft direkt erhalten bleiben? | Category-Hierarchie und Product-Zuordnungen |
| Dynamische Collection | Ist eine SmartCategory oder andere Merchandising-Regel sinnvoll? | Quellregel und beabsichtigte Verantwortung |
| Brand- oder Herstellergruppierung | Soll sie Category, Manufacturer Field, Filter oder Seite bleiben? | Brand-Beispiele und Zweck für Auffindbarkeit |
| Nur für Suche genutzter Wert | Soll er Keyword, Extra Field, Product Code oder anderes durchsuchbares Feld bleiben? | Suchbegriff- und Feldinventar |
| Reiner Menülink | Auf welche Category, Seite, welches Product oder externe Ziel verweist er? | Navigationsübersicht |
| Legacy-URL | Welches Product, welche Category oder Seite ist das beabsichtigte Ziel? | Priorisierte Weiterleitungsliste |
Bereiten Sie URLs für Products, Categories, Extra Pages, Blog-/Content-Seiten, Hersteller, Kampagnen und Richtlinien vor. Dokumentieren Sie Quellpfad, beabsichtigtes Ziel, Content Owner, Metadaten, interne Links und Weiterleitungsbedarf. Bei SmartCategories sollte die Mitgliedschaftsregel als eigener Nachweis neben der öffentlichen Category-URL erhalten bleiben; eine dynamische Gruppe lässt sich aus einer einmaligen Product-Liste nicht zuverlässig rekonstruieren.
Customer Groups, Price Levels und Customer-Datensätze vorbereiten
Shift4Shop Customer Groups können Customers mit Price Levels, Mindestbestellanforderungen, Product- oder Category-Sichtbarkeit sowie verfügbaren Payment- oder Versandmethoden verbinden. Bereiten Sie Gruppe und zugehörige Regeln gemeinsam vor.
Sammeln Sie:
- Namen und Zweck der Customer Groups;
- Price-Level-Zuordnungen und Product-Preise;
- Einschränkungen der Product- oder Category-Sichtbarkeit;
- Mindestbestellanforderungen;
- benutzerdefinierte Customer-Felder und Adressen;
- Steuerbefreiungs-, Großhandels-, Affiliate-, Reward-, CRM-, Review-, Waiting-List- oder Marketingbeziehungen;
- externe Account-IDs und Company-Referenzen;
- Beispiele für doppelte Customers und Guest Checkout.
| Vorbereitungsfrage | Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Welche Gruppen sind kommerziell noch aktiv? | Gruppenliste und Eigentümer | Veraltete Gruppen sind ausgeschlossen oder archiviert |
| Welche Price Levels gehören zu welcher Gruppe? | Product- und Gruppenbeispiele | Beziehungen zwischen Product, Price Level und Customer Group sind explizit |
| Welche Zugriffsregeln hängen von Gruppen ab? | Beispiele eingeschränkter Products/Categories | Sichtbarkeitsregeln besitzen einen Zieleigentümer |
| Welche App-Datensätze gehören zu Customers? | Reward-, Affiliate-, CRM- oder Review-Beispiele | Fortbestehender App- oder externer Eigentümer ist dokumentiert |
| Wie werden doppelte Customers behandelt? | Beispiele für Matching Keys | Regeln für Zusammenführung oder getrennte Beibehaltung sind definiert |
Historische Orders und betriebliche Referenzen vorbereiten
Bereiten Sie Orders vor, die die Struktur der historischen Datensätze zeigen und nicht nur gewöhnliche bezahlte Orders.
Berücksichtigen Sie:
- Orders mit gewöhnlichen Optionen und Advanced Options;
- Kontext zu Customer Group oder Price Level;
- Coupons, Promotions, Gift Certificates, Rewards, Affiliate Attribution, Steuern und Versandkosten;
- Pending-, Canceled-, Refunded-, Partially Refunded-, Shipped- und Partially Fulfilled-Orders;
- CRM-Tickets, Waiting-List-Kontext, Reviews, Notizen und manuelle Anpassungen, sofern relevant;
- ERP-, Buchhaltungs-, Marketplace-, Fulfillment- oder Payment-Referenzen;
- ältere Statuslabels, die Mitarbeiter weiterhin verwenden.
Erklären Sie für jedes Muster, welche Position, Summe, welcher Status oder welche externe Referenz Customer Service, Finance, Fulfillment oder Reporting unterstützt. Die aktuelle Payment-, Versand-, Steuer- und Benachrichtigungskonfiguration sollte getrennt von historischen Order-Nachweisen dokumentiert werden.
Module, Apps, benutzerdefinierte Felder und Legacy-Datensätze inventarisieren
Erstellen Sie ein Abhängigkeitsregister für Shift4Shop-Module, optionale Apps, benutzerdefinierte Felder, Skripte, Integrationen und ältere Datensätze aus der 3dcart-Ära.
Dokumentieren Sie für jedes Element:
- geschäftlichen Zweck;
- Eigentümer im Quellsystem;
- zugehörige Products, Customers, Orders, Categories oder Seiten;
- Beispieldatensätze;
- Export- oder API-Nachweise;
- externe Kennungen;
- ob die Funktion fortgeführt, ersetzt oder eingestellt wird;
- welche Daten für Historie oder Abstimmung erhalten bleiben müssen.
Besondere Aufmerksamkeit benötigen Suche, Advanced-Options-Pricing, Rewards, Affiliate, CRM, Reviews, Waiting Lists, Abonnements, digitale Products, Marktplätze, ERP, Buchhaltung, Steuern, Versand und Payment. Das Register ist vollständig, wenn jedes aktive Nicht-Core-Feld einen Parent-Datensatz, geschäftlichen Eigentümer, Exportpfad, externe Kennung und eine Entscheidung zur Fortführung oder Stilllegung besitzt.
Repräsentative Migrationsmuster für Shift4Shop auswählen
| Muster | Zweck der Vorbereitung |
|---|---|
| Einfaches Product | Gewöhnliche Product-, Category-, Medien-, Preis- und Bestandsbehandlung etablieren |
| Product mit gewöhnlichen Optionen | Optionswerte und Order-Line-Bedeutung ohne eigenständigen Bestand sichtbar machen |
| Product mit Advanced Options | Kombinationsebene für Code, Bestand, GTIN, Gewicht, Bild und Preis sichtbar machen |
| Product mit Extra Fields oder durchsuchbaren Metadaten | Beschreibende und integrationsverwaltete Felder sichtbar machen |
| Product in SmartCategory | Dynamische Gruppierung gegenüber direkter Category-Zuordnung sichtbar machen |
| Customer in kommerzieller Gruppe | Beziehungen zwischen Customer Group, Price Level, Zugriff und benutzerdefinierten Feldern sichtbar machen |
| Komplexe historische Order | Optionen, Summen, Statuswerte, Rewards, Refunds und externe Referenzen sichtbar machen |
| Priorisierter Content-Pfad | Entscheidungen zu Extra Page, Product, Category, Metadaten und Weiterleitung sichtbar machen |
| Legacy- oder app-eigener Datensatz | Aktuelle Verantwortung für 3dcart- oder erweiterungserzeugte Daten sichtbar machen |
Hinterlegen Sie Quell-IDs, geschäftlichen Zweck, erwarteten Zieleigentümer, zugehörige externe IDs und bekannte Ausschlüsse. Das Musterregister sollte erklären, warum jeder Datensatz ausgewählt wurde und welche Quellbeziehung er repräsentiert, ohne spätere Pass- oder Launch-Kriterien vorwegzunehmen. Verwenden Sie getrennte Muster für gewöhnliche Optionen, Advanced Options, SmartCategories, Customer-Group-Pricing und Legacy-App-Daten, wenn ein einziges Muster diese Strukturen nicht zuverlässig abdeckt.
Bereitschaftstor für Shift4Shop abschließen
| Bereitschaftsfrage | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Ist der erforderliche Zugriff vorhanden? | Zugriffsprotokoll | Erforderliche Quell- und Zielbereiche sind erreichbar |
| Sind gewöhnliche und Advanced Options unterschieden? | Product-Family-Matrix | Jedes wichtige Optionsmuster besitzt einen dokumentierten Eigentümer |
| Sind Categories und SmartCategories klassifiziert? | Category-Inventar | Statische und dynamische Mitgliedschaft werden nicht verwechselt |
| Sind Customer-Group- und Price-Level-Regeln dokumentiert? | Matrix kommerzieller Beziehungen | Gruppen, Products, Preise und Einschränkungen sind verbunden |
| Sind historische Orders repräsentiert? | Order-Musterpaket | Wichtige Statuswerte, Anpassungen und externe Referenzen sind erklärt |
| Haben Module und Legacy-Felder Eigentümer? | Abhängigkeitsregister | Jeder aktive benutzerdefinierte Datensatz besitzt einen fortbestehenden Eigentümer |
| Sind Backups und Exporte aktuell? | Datiertes Quellarchiv | Nachweise können unabhängig vom Live Store wiederhergestellt werden |
| Sind repräsentative Migrationsmuster ausgewählt? | Musterregister | Gewöhnliche und außergewöhnliche Strukturen sind abgedeckt |
Die Vorbereitung ist abgeschlossen, wenn keine kritische Entscheidung zu Product, Customer, Order, Category oder Integration von einem unerklärten Legacy-Label oder undokumentierten Modul abhängt. Jeder offene Punkt sollte den verantwortlichen Business Owner, den noch benötigten Nachweis und die Zielstruktur oder das System benennen, das die endgültige Entscheidung besitzen wird.
Fazit
Die Vorbereitung auf eine Migration zu Shift4Shop sollte die Beziehungen hinter Products, gewöhnlichen Optionen, Advanced Options, Categories, SmartCategories, Customer Groups, Price Levels, Orders, Content und Legacy-Datensätzen sichtbar machen. Besonders wichtig ist die Trennung nativer Strukturen von modulverwalteten und 3dcart-bezogenen Daten bei gleichzeitiger Bewahrung der Kennungen, die Mitarbeiter und externe Systeme weiterhin benötigen.
Ein dokumentiertes Nachweispaket stellt für die repräsentative Migration einen belastbaren Mustersatz mit klaren Quellerwartungen und Verantwortlichkeiten bereit.
Häufige Fragen
Welche Katalogentscheidung sollte bei Shift4Shop zuerst vorbereitet werden?
Bestimmen Sie, welche Quellauswahl gewöhnliche Product Options bleiben und welche Kombinationen eine Advanced-Option-Identität benötigen. Diese Unterscheidung beeinflusst SKU, Bestand, GTIN, Gewicht, Preis, Bilder und Bedeutung der Order Line.
Sollte jede Quell-Category zu einer Shift4Shop Category werden?
Nein. Einige Quellgruppen sind dynamische Kampagnen, Search Collections, Manufacturer Views, Menülinks oder interne Klassifizierungen. Klären Sie zuerst den beabsichtigten Zweck für Auffindbarkeit, bevor das Ziel festgelegt wird.
Warum müssen Customer Groups und Price Levels gemeinsam vorbereitet werden?
Die Gruppe definiert den Customer-Kontext, während Price Level und zugehörige Einschränkungen das kommerzielle Verhalten bestimmen. Ein Gruppenname ohne seine Product-Preise oder Zugriffsregeln ist unvollständig.
Welche Orders gehören in den repräsentativen Migrationsmusternsatz?
Berücksichtigen Sie Orders mit gewöhnlichen Optionen, Advanced Options, Rabatten, Steuern, Versand, unterschiedlichen Statuswerten, Refunds, Reward- oder Affiliate-Kontext und externen Systemreferenzen.
Welche Nachweise sollten für alte 3dcart-Felder gesammelt werden?
Verfolgen Sie jedes Feld bis zu seinem heutigen geschäftlichen Zweck und Consumer. Bewahren Sie es nur, wenn eine Shift4Shop-Struktur, ein aktives Modul oder ein externes System den Wert weiterhin besitzt.
Wann ist die Vorbereitung für Shift4Shop abgeschlossen?
Wenn Zugriffe und Exporte bereitstehen, Product-Optionsmuster klassifiziert, kommerzielle Gruppen und Preise dokumentiert, priorisierte Pfade zugeordnet, Abhängigkeiten Verantwortlichen zugewiesen und repräsentative Muster ausgewählt sind.