Wenn ShopWired als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn ShopWired als Zielplattform ausgewählt wird, muss die Vorbereitung zwischen Datensätzen unterscheiden, die in einem Export ähnlich aussehen, sich im Store jedoch unterschiedlich verhalten. Product-Variationen, Product Choices, Extras, Personalisierungsfelder, digitale Auslieferung, B2B-Customers, Categories, Marken, Filter und App-eigene Daten können die Bedeutung eines Product- oder Customer-Datensatzes verändern. Eine flache Product-Liste reicht nicht aus, um diese Beziehungen zu erklären.
Ziel der Vorbereitung ist ein belastbares Nachweispaket aus dem Quellshop, das jedem wichtigen Bereich einen Eigentümer, einen Nachweis und eine Freigabebedingung zuweist. Es sollte erklären, wie Products verkauft werden, worin sich B2B- und gewöhnliche Customers unterscheiden, wie Orders ausgewählte Optionen bewahren und welche Apps oder externen Systeme Daten außerhalb der normalen ShopWired-Datensätze besitzen.
Kontozugriff klären und die ShopWired-Umgebung dokumentieren
Dokumentieren Sie das genaue ShopWired-Konto, die primäre Domain, das aktive Theme, installierte Apps, Staff-Rollen, Steuer- und Währungskontext, Exportmöglichkeiten für Products und Orders sowie externe Systeme. Halten Sie fest, wer Katalog, B2B-Konten, Orders, SEO, Theme-Code, Finance, Auftragsabwicklung und Integrationen verantwortet.
Bereiten Sie den für den gewählten Migrationspfad unterstützten Zugriff vor. Hosted-Platform-Zugang, Exporte und autorisierte API- oder Integrationszugangsdaten sind nicht austauschbar. Der Zugriffsverantwortliche sollte die für den aktuellen Store passende Methode bereitstellen und für Fragen zu Berechtigungen oder Datenumfang verfügbar bleiben.
| Aktion | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Konto und Domain bestätigen | Store-Administrator | Kontodaten, Domain-Liste, Store-Status | Der richtige Quellshop ist eindeutig. |
| Installierte Apps inventarisieren | Plattformverantwortlicher | App-Liste, Zweck, erzeugte Daten, aktueller Status | App-eigene Daten können von nativen Datensätzen getrennt werden. |
| Theme- und Code-Verantwortung erfassen | Theme-Verantwortlicher oder Agentur | Theme-Version, Hinweis auf eigenen Code, Repository oder Backup-Speicherort | Darstellungs- und Codeabhängigkeiten haben einen benannten Eigentümer. |
| Source-Exporte und Zugriff bestätigen | Daten- oder Technikverantwortlicher | Exportrechte, ggf. API- oder Feed-Details | Erforderliche Source-Nachweise können erhoben werden. |
| Änderungsprotokoll starten | Projektverantwortlicher | Datierte Änderungen an Katalog, Customers, Orders, Apps und URLs | Der Nachweisstand veraltet nicht unbemerkt. |
Products nach Verkaufsverhalten vorbereiten
ShopWired trennt Product-Variationen, Product Choices und Product Extras. Variationen können eigenen Preis, SKU, Bestand, Bild, Gewicht, GTIN, MPN, Steuerbehandlung und weitere Attribute besitzen. Choices sind wiederverwendbare Optionssets für Products und können Kosten addieren, stellen aber keine separat bestandsgeführten Varianten dar. Extras sind optionale Ergänzungen und können in bestimmten Fällen auf ein anderes Product für Bestandszwecke verweisen. Personalisierungsfelder und Datei-Uploads erfassen käuferspezifische Eingaben.
Bereiten Sie Products nach Verhalten statt nur nach Anzahl vor. Erfassen Sie Product-ID, Titel, SKU, Status, Preis, Sale-Preis, Steuerbehandlung, Bestand, Gewicht, Categories, Marke, Filter, Bilder, Inhalte, SEO-Felder, Variationsstrukturen, Choices, Extras, Personalisierungsfelder, Digital-Delivery-Referenzen und externe Kennungen.
| Product-Muster | Vorbereitungsaktion | Nachweis | Freigabebedingung |
|---|---|---|---|
| Variationen | Optionsnamen, Werte, Kombinationen, Veröffentlichungsstatus, Variationsattribute und Parent-Vererbung erfassen | Variations-Export und Product-Beispiele | Eigenständig relevante Kombinationen sind dokumentiert. |
| Product Choices | Globales Choice-Set, Optionen, Zusatzkosten, Product-Zuweisung, Pflichtstatus und bedingte Anzeige erfassen | Choice-Set-Inventar und zugewiesene Products | Wiederverwendbare Buyer Choices werden nicht mit Varianten verwechselt. |
| Product Extras | Zweck, Preis, ggf. verknüpftes Product und Bestandsannahme erfassen | Extra-Liste und repräsentative Products | Optionale Ergänzungen haben klare Verantwortung. |
| Personalisierung oder Datei-Input | Feldlabel, Pflichtstatus, akzeptierte Eingabe und Anzeige in Order-Zeile erfassen | Product- und Order-Beispiele | Käuferspezifische Eingabe bleibt mit dem Kauf verbunden. |
| Digitales oder Service-Product | Auslieferungsmethode, Datei-/Zugriffseigentümer und Product-Status erfassen | Product-Liste und Source-Assets | Nachweise für nicht-physische Auslieferung sind vorhanden. |
| Vorbestellbares oder geplantes Product | Versand-/Release-Einstellungen und operative Verantwortung erfassen | Product-Beispiele und Datumsregeln | Zeitabhängiges Verkaufsverhalten ist dokumentiert. |
Choices oder Extras dürfen nicht allein wegen ähnlicher Labels in Variationen umgewandelt werden. Bestand, Pricing, Wiederverwendung und Order-Verhalten unterscheiden sich.
Categories, Marken, Filter und Storefront-Auffindbarkeit vorbereiten
Ein Product kann als Datensatz vollständig sein und trotzdem schwer auffindbar werden, wenn Category-, Marken-, Filter-, Such- oder Navigationsnachweise fehlen. Bereiten Sie Category-Hierarchie, Product-Zuweisungen, Marken, filterrelevante Werte, Menüs, Landingpages und wichtige Routen als getrennte, aber verbundene Source-Strukturen vor.
| Auffindbarkeit-Bereich | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Categories | Katalogverantwortlicher | Hierarchie, Product-Zuweisungen, Status, Landing-Text | Jede retained Category hat einen bekannten Zweck. |
| Marken | Merchandising | Markenliste, Product-Beziehungen, URLs, Metadaten | Markenauffindbarkeit ist von beschreibenden Labels getrennt. |
| Filter | Katalog- oder Search-Verantwortlicher | Filternamen, Werte, Product-Abdeckung, Bereinigungsausnahmen | Von Käufern verwendete Werte sind konsistent genug für die Zuordnung. |
| Menüs und Landingpages | Storefront-Verantwortlicher | Navigationskarte, Screenshots, verknüpfte Categories und Seiten | Darstellungswege sind außerhalb des Category-Exports dokumentiert. |
| Prioritäts-URLs | SEO-Verantwortlicher | Product-, Category-, Marken-, Seiten- und Kampagnenrouten | Hochwertige Routen haben eine geplante Zielbehandlung. |
Erfassen Sie Products in mehreren Categories, ausgeblendete oder saisonale Categories, nur für B2B sichtbare Bereiche und Kampagnenpfade. Diese Fälle zeigen Auffindbarkeit-Regeln, die eine reine Hierarchie nicht erkennen lässt.
Customers, B2B-Konten und Adressnachweise vorbereiten
ShopWired kann Standard-Customers und B2B-Customers mit unterschiedlichem Kontoverhalten unterstützen. B2B-Funktionen können B2B-Preise, nur für B2B sichtbare Products oder Categories, Kreditkonten, eingeschränkte Promotions und Account-Aktivierungsstatus umfassen. Die Vorbereitung muss zeigen, welche Customers gewöhnliche Konten sind und welche von B2B-Beziehungen abhängen.
Bereiten Sie Customer-ID, Name, E-Mail, Kontostatus, Adressen, Marketingpräferenzen, Custom Fields, B2B-Status, Kredit- oder Zahlungskontext, interne Notizen und externe IDs vor. Prüfen Sie doppelte oder gemeinsam genutzte E-Mail-Adressen, weil die E-Mail für Account- und Order-Beziehungen wichtig sein kann.
| Customer-Muster | Vorbereitungsaktion | Nachweis | Freigabebedingung |
|---|---|---|---|
| Registrierter Standard-Customer | Identität, Adressen, Kontostatus und Order-Beziehung erfassen | Customer- und Order-Beispiele | Kontoidentität ist eindeutig. |
| Gastkäufer | E-Mail, Order-Historie und ggf. spätere Kontobeziehung erfassen | Guest-Order-repräsentative Datensätze | Gasthistorie wird nicht als registriertes Konto interpretiert. |
| B2B-Customer | Aktivstatus, B2B-Preise, eingeschränkte Products/Categories, Kreditkontext und Custom Fields erfassen | B2B-Customer-Register | B2B-Bedeutung ist an reale Customers gebunden. |
| Doppelte/geteilte E-Mail | Datensätze, Geschäftsgrund und Entscheidung dokumentieren | Identity-Exception-Liste | Unklare Identität hat einen Verantwortlichen. |
| Customer in externem System | CRM-, Accounting-, ERP- oder Support-IDs erfassen | Integration Field Dictionary | Downstream-Lookup-Schlüssel bleiben verfügbar. |
Historische Orders und ausgewählte Product-Eingaben vorbereiten
Historische Orders sollten die Informationen bewahren, die Customer Service, Finance und Operations benötigen. ShopWired Orders können ausgewählte Variationen, Choices, Extras, Personalisierungstext, Referenzen auf hochgeladene Dateien, B2B-Preise, Versandlabels, Steuerkontext, Rabatte, Erstattungen und Notizen enthalten. Wählen Sie Orders aus, die diese Muster sichtbar machen.
| Order-Bereich | Aktion | Nachweis | Freigabebedingung |
|---|---|---|---|
| Product-Konfiguration | Variation-, Choice-, Extra- und Personalisierungsselektionen einbeziehen | Repräsentative Order-Zeilen | Gekaufte Konfiguration ist interpretierbar. |
| Customer-Identität | Registrierte, Gast- und B2B-Orders unterscheiden | Szenarioübergreifende repräsentative Datensätze | Order-Verantwortung ist klar. |
| Preise und Rabatte | B2B-Preis, Sale-Preis, Gutschein, manuelle Anpassung und Steuerfälle einbeziehen | Komponenten der Gesamtsumme | Historischer kommerzieller Kontext ist dokumentiert. |
| Versand und Auftragsabwicklung | Versandart, Status, Tracking, Abholung und Sonderbehandlung erfassen | Order- und Shipment-Beispiele | Auftragsabwicklung-Historie hat bekannte Bedeutung. |
| Erstattungen und Stornierungen | Betrag, Status, Notizen und zugehörige Order einbeziehen | Exception-Order-Set | Finanz- und Servicehistorie bleibt verständlich. |
| Externe Referenzen | Accounting-, ERP-, Marketplace-, Auftragsabwicklung- oder Support-IDs erfassen | Integrationssensitive Orders | Erforderliche Lookup-Werte sind identifiziert. |
Historische Order-Nachweise beschreiben, was geschehen ist. Sie ersetzen nicht die Live-Konfiguration für Zahlung, Versand, Steuer, E-Mail oder Checkout im neuen Store.
Apps, APIs, Webhooks, Feeds und eigenen Code inventarisieren
Erstellen Sie ein Abhängigkeitsverzeichnis für jede ShopWired-App, jeden Product-Feed, jede Marktplatzverbindung, Accounting-Lösung, CRM, ERP, Auftragsabwicklung-Service, Lagerlösung, Analyse-Integration, API-Automatisierung, jeden Webhook und jede Theme-Anpassung. Erfassen Sie, ob eine Abhängigkeit Daten erzeugt, liest, Checkout oder Darstellung verändert, Bestand schreibt oder Kennungen nutzt, die weiterhin auffindbar sein müssen.
| Abhängigkeitsfeld | Erforderliches Detail | Freigabebedingung |
|---|---|---|
| Eigentümer und Zweck | fachlicher Verantwortlicher, technischer Verantwortlicher, unterstützter Prozess | Verantwortung ist eindeutig. |
| Datenobjekte | Verwendete Products, Customers, Orders, Bestand, Categories, Inhalte oder Custom Fields | Betroffene Datensätze sind bekannt. |
| Richtung und Timing | Read, Write, bidirektional, zeitgesteuert, eventbasiert oder manuell | Source Authority ist dokumentiert. |
| Kennungen | SKU, Product-ID, Customer-E-Mail, Order-Nummer, externer Schlüssel | Lookup-Abhängigkeiten bleiben erhalten. |
| Übergangsentscheidung | Wiederverbinden, neu bauen, stilllegen, ersetzen oder prüfen | Keine Abhängigkeit wird als automatisch fortbestehend angenommen. |
Theme-Code gehört ebenfalls in die Bestandsaufnahme, wenn er Product-Optionen, B2B-Sichtbarkeit, Navigation, Content-Darstellung oder Order-Erfassung verändert. Reiner Darstellungscode und datenführender Code sind nicht dasselbe Risiko.
Inhalte, Medien, URLs und Theme-Nachweise vorbereiten
Bereiten Sie Seiten, Blog- oder Guide-Inhalte, Richtlinien, Formulare, Medien, Downloads, Product- und Category-Beschreibungen, Markenseiten, Metadaten, interne Links, Canonical-Erwartungen und Redirects vor. Erfassen Sie, welche Inhalte nativ, App-eigen oder im Theme-Code eingebettet sind.
| Content-Bereich | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Product- und Category-Content | Katalog oder Marketing | Exporte, Medienpfade, repräsentative Seiten | Kommerzieller Inhalt kann Datensätzen zugeordnet werden. |
| Seiten und Richtlinien | Content-Verantwortlicher | Seiteninventar, Status, Route, interne Links | Entscheidungen zu Beibehalten, Neuaufbau, Zusammenführung oder Ausschluss sind dokumentiert. |
| Digitale Assets | Operations oder Content | Originaldateien, Product-Beziehung, Zugriffsregeln | Source-Dateien sind verfügbar. |
| SEO-Routen | SEO-Verantwortlicher | Prioritäts-URLs, Metadaten, Redirects, Kampagnenpfade | Inputs für URL-Kontinuität sind vollständig. |
| Theme-abhängige Inhalte | Theme-Verantwortlicher | Template-Orte, Custom Sections, Screenshots | Im Presentation-Code versteckter Content ist identifiziert. |
Exporte, Backups und Source-Change-Control vorbereiten
Erstellen Sie ein datiertes Archiv mit Product-, Customer-, B2B-Customer-, Order-, Category-, Marken-, Filter-, Content- und App-bezogenen Exporten sowie Medien, Screenshots, API-/Feed-Dokumentation, Theme-Backup und erklärenden Notizen. Originalexporte bleiben unverändert; Bereinigungen erfolgen in Arbeitskopien.
| Nachweis-Set | Erforderlicher Inhalt | Freigabebedingung |
|---|---|---|
| Core-Exporte | Dateien, Exportdatum, Feldset, Kontokontext, Checksum | Datensätze sind vollständig und zuordenbar. |
| Optionsnachweise | Variationen, Choices, Extras, Personalisierungsfelder, Product-Zuweisungen | Verkaufsverhalten geht nicht in einem Product-only-Export verloren. |
| Theme und Medien | Theme-Backup oder Code-Nachweis, Bilder, Downloads, Upload-Assets | Darstellung und Source-Dateien sind auffindbar. |
| Abhängigkeitsdaten | App-Liste, Feeds, API-/Webhook-Notizen, externe IDs | Integrations-Verantwortung ist dokumentiert. |
| Änderungsprotokoll | Neue/geänderte Products, Customers, Orders, URLs, Apps und B2B-Regeln | Spätere Source-Änderungen können abgestimmt werden. |
Repräsentative Datensätze für den Migrationstest auswählen
Wählen Sie repräsentative Datensätze, die unterschiedliche ShopWired-Strukturen sichtbar machen, statt nur gewöhnliche Datensätze. Für jedes repräsentativer Datensatz sollte eine kurze Erwartung aus dem Quellshop dokumentieren, warum es ausgewählt wurde und welche Felder oder Beziehungen relevant sind.
| repräsentativer Datensatz-Gruppe | Einbeziehen | Vorbereitungszweck |
|---|---|---|
| Products | Einfaches Product, Multi-Variation-Product, Choice-lastiges Product, Extra, Personalisierungs-/Upload-Product, digitales Product, B2B-only Product | Unterschiedliche Verkaufsverhaltensweisen sichtbar machen. |
| Customers | Registriert, Gast, B2B, Kreditkontext, Duplicate-E-Mail-Ausnahme, Customer mit externer ID | Identitäts- und B2B-Unterschiede abdecken. |
| Orders | Variation, Choices, Personalisierung, B2B-Preis, Rabatt, Erstattung, ungewöhnlicher Versand, externe Referenz | Historischen Kontext erhalten. |
| Auffindbarkeit | Priority Category, Marke, Filterset, Menüpfad, Landingpage | Storefront-Strukturnachweise vorbereiten. |
| Content und Integrationen | SEO-sensitive Seite, digitales Asset, App-eigenes Feld, Feed- oder API-Datensatz | Nicht-Core-Abhängigkeiten repräsentieren. |
Das repräsentativer Datensatz-Paket ist bereit, wenn jeder ausgewählte Datensatz eine Erwartung aus dem Quellshop, verknüpfte Nachweise, relevante Kennungen und einen benannten Prüfverantwortlicher besitzt.
ShopWired-Freigabekriterien abschließen
| Final Freigabekriterium | Freigabebedingung |
|---|---|
| Zugriff | Richtiges Konto, Exporte, Apps, Theme-Verantwortung und technische Ansprechpartner sind bestätigt. |
| Products | Variationen, Choices, Extras, Personalisierung, digitale Auslieferung, B2B-Sichtbarkeit und Kennungen sind dokumentiert. |
| Auffindbarkeit | Categories, Marken, Filter, Menüs und Prioritätsrouten sind vorbereitet. |
| Customers | Standard-, Gast-, B2B-, Duplicate-, Adress- und externe-ID-Fälle sind verstanden. |
| Orders | Product-Auswahl, Summen, Versand, Erstattungen, Notizen und externe Referenzen sind interpretierbar. |
| Dependencies | Apps, APIs, Webhooks, Feeds, Theme-Code und externe Systeme haben definierte Übergangsentscheidungen. |
| Inputs | Exporte, Assets, Backups, Checksums und Change Log sind verfügbar. |
| repräsentative Datensätze | Repräsentative Migrationsdatensätze decken gewöhnliche und komplexe Source-Muster ab. |
Fazit
Die ShopWired-Vorbereitung sollte den Unterschied zwischen Variationen, Choices, Extras, Personalisierung, B2B-Verhalten und App-eigenen Daten erhalten. Diese Unterschiede bestimmen, ob Product, Customer oder Order außerhalb des Quellshop verständlich bleibt.
Wenn Zugriff, Source-Beziehungen, Exporte, Assets, Dependencies und repräsentative Datensätze dokumentiert sind, kann die Migrationskonfiguration auf einer stabilen und überprüfbaren Grundlage beginnen.
Häufige Fragen
Warum sollten Variationen, Choices und Extras getrennt inventarisiert werden?
Weil sie unterschiedliche Preis-, Bestands-, Wiederverwendungs- und Order-Verhaltensweisen haben. Eine generische Optionsstruktur kann wichtige kommerzielle Bedeutung entfernen.
Welche ShopWired Products gehören in das repräsentativer Datensatz-Set?
Nehmen Sie einfache Products, Variationen, Choices, Extras, Personalisierungs- oder Datei-Upload-Products, digitale oder Service-Products, B2B-only Products und Datensätze mit externen Kennungen auf.
Wie sollten B2B-Customers vorbereitet werden?
Dokumentieren Sie Aktivstatus, B2B-Preise, eingeschränkte Products oder Categories, Kreditkontext, Custom Fields, Adressen, Order-Historie und externe Systemkennungen.
Sollten Guest Orders bei der Bereinigung registrierten Customers zugeordnet werden?
Nur wenn das Unternehmen die Identitätsbeziehung ausdrücklich bestätigt hat. Gemeinsam genutzte oder wiederverwendete E-Mail-Adressen können eine automatische Zusammenführung unzuverlässig machen.
Welche App-Informationen werden vor der Migration benötigt?
Erfassen Sie Zweck, gelesene oder erzeugte Datensätze, Kennungen, Eigentümer, Integrationstiming und die Entscheidung, ob die App wiederverbunden, neu aufgebaut, stillgelegt oder ersetzt wird.
Wie sollten Änderungen nach dem Exportdatum kontrolliert werden?
Führen Sie ein datiertes Änderungsprotokoll für Products, Customers, Orders, URLs, Apps, Theme-Code und B2B-Regeln, damit spätere Änderungen mit dem vorbereiteten Nachweisstand abgeglichen werden können.