Wenn Shopify 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 Shopify als Zielplattform ausgewählt wird, sollte die Vorbereitung den Quellshop vor dem ersten Migrationslauf in eine Reihe klarer, belegter Entscheidungen übersetzen. Es geht nicht darum, den gesamten Shopdarstellung im Voraus neu zu gestalten, sondern festzulegen, wie wichtige Products, Varianten, Collections, Customers, Orders, Inhalte, URLs, Apps, Metafields, Metaobjects, Markets und externe Kennungen in Shopify dargestellt werden sollen.
Ein brauchbares Vorbereitungspaket beantwortet für jeden wichtigen Datenbereich vier Fragen: Was muss bereitgestellt werden? Wer besitzt die Entscheidung? Welche Nachweise stützen sie? Und welche Bedingung macht den Bereich bereit? Dadurch wird verhindert, dass erst beim repräsentativen Migrationstest auffällt, dass eine Quelloption in Wahrheit eine individuelle Product-Eingabe ist, eine Category eigentlich eine Kampagnenseite oder eine Customer-Gruppe von einem externen Wholesale-System abhängt.
Zielentscheidungen für Shopify festlegen
Bevor Dateien gesammelt werden, müssen die Shopify-Strukturen definiert werden, die wichtige Quellbeziehungen aufnehmen sollen. Der Entscheidungsnachweis benennt für jede wesentliche Quellbeziehung den vorgesehenen Shopify-Eigentümer.
| Vorbereitungsbereich | Zu dokumentierende Entscheidung | Verantwortlich | Nachweis für Bereitschaft |
|---|---|---|---|
| Product-Struktur | Welche Quellrecords zu Products, Varianten, Metafields, Metaobjects, Tags oder App-eigenen Datensätze werden | Katalogverantwortlicher | Abgenommene Zuordnungsbeispiele für jede wichtige Product-Familie |
| Katalogorganisation | Welche Source Categories zu manuellen oder automatisierten Collections, Navigationslinks, Filtern, Landingpages oder Weiterleitungen werden | Merchandising und Content | Collection- und Navigationsentwurf mit repräsentativen Quellpfaden |
| Customer-Kontinuität | Welche Konto-, Tag-, Steuer-, Wholesale-, Loyalty-, Abonnement- oder externen CRM-Beziehungen nutzbar bleiben müssen | Customer Operations | Inventar der Customer-Beziehungen und Kommunikationsplan für Kontozugriff |
| Order-Historie | Welche Order-Status, Positionsdetails, Rückerstattungen, Notizen und externen Referenzen Mitarbeitende benötigen | Operations und Kundendienst | Muster historischer Orders plus Erläuterung der Feldbedeutung |
| Internationale Struktur | Welche Länder, Sprachen, Währungen, Domains, Unterverzeichnisse, lokalisierten Inhalte und marketspezifischen Datensätze relevant sind | International verantwortliches Team | Market- und Domain-Matrix |
| benutzerdefinierte Daten | Welche Quellfelder zu Shopify Metafields, Metaobjects, App-Daten, Content oder Ausschlüssen werden | Katalog und Technik | Feldinventar mit Zielverantwortlichem und fortbestehendem Nutzer |
Datensatzanzahlen sind kein primäres Bereitschaftssignal. Sie beschreiben Volumen, entscheiden aber nicht, ob eine Quelloption eine Shopify-Variante werden soll, ob ein Bundle App-eigene Beziehung bleibt oder ob ein regionaler Katalog getrennte Entscheidungen zu Shopify Market und Content benötigt.
Shop-Zugriffe und Quellnachweise vorbereiten
Bereiten Sie die Zugriffe auf Quelle und Shopify vor, die zum Abrufen, Interpretieren und Bewahren der in Umfang befindlichen Datensätze nötig sind. Das Paket muss auch für jemanden verständlich sein, der den Quellshop nicht eingerichtet hat, und darf nicht von undokumentiertem Wissen einzelner Mitarbeitender abhängen.
Sammeln Sie:
- Administratorzugriff auf Quellshop und Shopify Store mit den erforderlichen Berechtigungen;
- aktuelle Exporte oder Berichte für Products, Customers, Orders, Categories, Content, Bewertungen, Rabatte und weitere in Umfang befindliche Datensätze;
- Product-Medien, wenn Quell-URLs temporär, geschützt oder unzuverlässig sind;
- aktuelle Listen von Domains, Subdomains, Sprachverzeichnissen und regionalen URLs;
- App- und Integrationsinventare einschließlich Business- und Systemverantwortlicher;
- Definitionen benutzerdefinierter Quellfelder, Optionssets, Gruppenregeln und externer Kennungen;
- Beispiele kommerziell kritischer oder ungewöhnlich komplexer Datensätze;
- einen datierten Snapshot der Quelle sowie einen Hinweis, welche Daten sich bis zum Migrationsfenster noch ändern können.
| Nachweis | Warum er benötigt wird | Bereitschaftsbedingung |
|---|---|---|
| Quellzugriff | Ermöglicht die Prüfung der Quellbedeutung im tatsächlichen Administrationskontext | Zugriff funktioniert und erforderliche Datenbereiche sind sichtbar |
| Shopify-Zugriff | Ermöglicht die Bestätigung von Zieleinstellungen und Datensatz-Zuständigkeiten | Erforderliche Berechtigungen sind verfügbar, ohne persönliche Zugangsdaten informell zu teilen |
| Exportarchiv | Bewahrt eine Referenz des Quellzustands | Dateien öffnen korrekt, enthalten erwartete Datensätze und tragen ein Exportdatum |
| Wörterbuch benutzerdefinierter Felder | Erklärt sonst uneindeutige Bezeichnungen | Jedes wichtige Feld hat Zweck, Eigentümer und Beispielwert |
| Liste externer IDs | Schützt ERP-, PIM-, CRM-, WMS-, Marktplatz- oder Accounting-Kontinuität | Jede Kennung ist der richtigen Product-, Varianten-, Customer- oder Order-Ebene zugeordnet |
Fehlen wichtige App-Datensätze in einem Export, muss diese Lücke dokumentiert werden, statt anzunehmen, die Datensätze existierten nicht. Ein fehlender App-Export, eine geschützte Medienquelle oder eine undokumentierte Custom Table ist ein Bereitschaftsproblem mit notwendigem Verantwortlichen.
Products, Varianten und benutzerdefinierte Katalogdaten vorbereiten
Bei der Shopify-Product-Vorbereitung sind echte verkaufbare Kombinationen von beschreibenden Informationen, Kundeneingaben, Merchandising-Beziehungen und Daten externer Systeme zu unterscheiden.
Erstellen Sie ein Inventar von Product-Familien für:
- einfache Products mit einer verkaufbaren Konfiguration;
- Products mit mehreren Optionen und variantenspezifischen Unterschieden bei SKU, Barcode, Preis, Bestand, Gewicht, Bild, Steuern oder Fulfillment;
- Products, deren Optionskombinationen aus der Quelle konsolidiert, geteilt oder stillgelegt werden sollen;
- Bundles, Kits, Abonnements, Preorders, Garantien und anderes Kaufoptionsverhalten;
- personalisierte Products mit Text-, Datei-, Datums-, Maß- oder bedingten Eingaben;
- Products mit technischen Spezifikationen, Kompatibilitätstabellen, Größenratgebern, Dokumenten oder strukturierten Referenzdaten;
- Products, deren Inhalte oder Verfügbarkeit nach Region, Channel oder Customer-Typ abweichen;
- Products, die mit ERP, PIM, Lager, Marktplatz oder Lieferantenfeed synchronisiert werden.
Für jede Familie wird ein Beispiel-Zuordnungsblatt vorbereitet:
| Quellverhalten | Shopify-Vorbereitungsentscheidung | Beizufügender Nachweis |
|---|---|---|
| Auswahl erzeugt eigene SKU oder Bestandseinheit | Vorgesehene Product- und Variantenbeziehung definieren | Source Parent/Child IDs, Optionswerte, SKU, Bestand, Preis und Bildbeispiele |
| Wert beschreibt das Product | Metafield, Metaobject, Product-Inhalt oder anderes strukturiertes Ziel definieren | Feldzweck, Datentyp, zulässige Werte und Darstellungsverantwortlicher |
| Customer gibt einmaligen Wert ein | Product-Eingabe, App oder Positionsbeziehung bestimmen | Beispiel aus der Shopdarstellung und historisches Beispiel einer historischen Order-Position |
| Product ist Bundle, Abonnement oder konfigurierbares Set | Anwendung oder Zielstruktur bestimmen, die das Verhalten besitzt | Komponentenliste, Preislogik, Bestandszuständigkeit und Beispiel-Orders |
| Wert wird nur durch externes System genutzt | Auf richtiger Product- oder Variantenebene bewahren | Name des externen Systems, Eindeutigkeitsregel und Beispielsuche |
Options- und Attributnamen sollten normalisiert werden, bevor sie Shopify-Strukturen bilden. Entscheiden Sie etwa, ob „Colour“, „Color“ und „Finish“ ein kontrolliertes Konzept oder bewusst unterschiedliche Konzepte sind. Entfernen Sie veraltete oder inkonsistente Werte sowie Werte, die nur als Workaround der Quellplattform entstanden sind.
Collections, Navigation, Markets, Content und URLs vorbereiten
Source Categories lassen sich nur selten eins zu eins in Shopify Collections überführen. Klassifizieren Sie jede wichtige Gruppierung und Route.
| Quellstruktur | Vorbereitungsfrage | Nachweis für Bereitschaft |
|---|---|---|
| Dauerhafte Category | Soll sie manuelle Collection, automatisierte Collection oder ein anderes Ziel werden? | Collection-Regel oder Beispiel für Product-Mitgliedschaft |
| Reine Menügruppierung | Gehört sie in Navigation statt Katalogklassifikation? | Vorgesehene Menühierarchie und Ziellinks |
| Kampagnen- oder saisonale Gruppe | Ist sie temporäre Collection, Landingpage, Promotion oder stillgelegte Route? | Kampagnenverantwortlicher und Retain/Retire-Entscheidung |
| Filterwert | Soll er Product category, Optionswerte, Metafields oder App-verwaltete Suchdaten nutzen? | Kontrollierte Werteliste und Filterverantwortlicher |
| Regionale Route | Welche Market-, Domain-, Sprach-, Währungs- und Localized-Content-Beziehung gilt? | Market- und URL-Matrix |
Erstellen Sie ein Inventar von Products, Collections, CMS Pages, Blog Posts, Policy-Seiten, Guides und aktiven Kampagnenseiten. Für jede priorisierte Route werden Quell-URL, vorgesehenes Shopify-Ziel, Content-Verantwortlicher, Lokalisierungsbedarf und Weiterleitungsbedarf dokumentiert.
Dazu gehören:
- Product-URLs mit hohem Traffic oder Umsatz;
- Category- und Marken-Landingpages mit Backlinks oder Paid-Media-Wert;
- CMS Pages und Blog Posts, die Vertrauen, SEO oder Kundenservice unterstützen;
- lokalisierte oder regionale Pfade;
- eingestellte Product-Routen mit Bedarf an relevantem Ersatz;
- interne Links in Beschreibungen, Blog Posts, Seiten und Navigation;
- Dateien, Dokumente und Bilder, auf die Quellcontent verweist.
Bereitschaft bedeutet nicht „alle URLs wurden exportiert“, sondern dass jeder priorisierte Quellpfad ein definiertes Shopify-Ziel oder eine bewusste Stilllegungsentscheidung hat.
Customers, Konten und historische Orders vorbereiten
Bei Customers ist Identität von den Anwendungen und Regeln zu trennen, die an diese Identität gebunden sind. Bereiten Sie Beispiele für registrierte Customers, Gastkäufer, mehrere Adressen, Steuerbehandlung, Tags oder Gruppen, B2B-Beziehungen, Loyalty, Abonnements, Mitgliedschaften und externe CRM-Referenzen vor.
Gehen Sie nicht davon aus, dass Authentifizierungsdaten der Quelle in Shopify weiterverwendet werden können. Bereiten Sie den Kommunikations- und Zugriffsansatz vor, über den migrierte Customers ihren neuen Shopzugang erhalten.
Für Orders sollten Beispiele reale historische Komplexität abdecken:
- bezahlte, ausstehende, stornierte, vollständig und teilweise zurückerstattete Orders;
- teilweise erfüllte Orders und Sendungen mit mehreren Lieferungen;
- Orders mit Rabatten, Gift Cards, Store Credit, Steuern, Abgaben, Versandanpassungen oder manuellen Änderungen;
- Orders mit individuellen Product-Eingaben, Bundles, Abonnements oder App-eigenen Line-Daten;
- Orders mit Verbindung zu Marktplätzen, ERP, Accounting, Fulfillment, Kundendienst oder CRM;
- Orders aus jedem priorisierten Market, jeder Währung oder jedem Shopdarstellung.
| Vorbereitungspunkt | Verantwortlich | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Regeln zur Customer-Identität | Customer Operations | Beispiele doppelter Konten und externe IDs | Regeln für Zusammenführen, getrenntes Beibehalten und Gäste sind dokumentiert |
| Kontozugriff | Customer Experience | Kommunikationsentwurf und zuständiges Team | Mitarbeitende wissen, wie wiederkehrende Customers erneut Zugang erhalten |
| Customer-Klassifikationen | B2B-, Steuer-, Loyalty- oder CRM-Verantwortlicher | Gruppen-/Tag-Beispiele und zugehörige Geschäftsregel | Zieleigentümer jeder Klassifikation ist definiert |
| Bedeutung historischer Orders | Kundendienst und Finanzteam | Repräsentatives Order-Paket | Positionen, Anpassungen, Status, Rückerstattungen und Referenzen sind erklärt |
| Umfang sensibler Daten | Recht oder Datenverantwortlicher | Genehmigte Feldliste | Unnötige oder nicht unterstützte personenbezogene Daten sind ausgeschlossen |
Apps, Integrationen und externe Abhängigkeiten inventarisieren
Erstellen Sie ein gemeinsames Abhängigkeitsregister für jede App, Quellerweiterung, jedes Skript, jede Custom-Field-Gruppe, Automatisierung, jeden Webhook und jedes externe System, das Product-, Customer-, Order-, Preis-, Content- oder Fulfillment-Verhalten verändert.
Für jede Abhängigkeit werden dokumentiert:
- geschäftlicher Zweck;
- erzeugte oder veränderte Datensatz-Typen;
- beteiligte Parent-Datensätze in Shopify oder der Quelle;
- Daten- und Technikverantwortlicher;
- Export- oder API-Verfügbarkeit;
- externe Kennungen für Abstimmung;
- ob die Abhängigkeit weiterbesteht, ersetzt oder stillgelegt wird;
- Daten, die vorhanden sein müssen, bevor der Ersatz konfiguriert werden kann.
Prioritär sind häufig Bewertungen, Suche und Filter, Abonnements, Bundles, Loyalty, B2B, Product-Anpassung, Steuern, Versand, Zahlungen, Marktplatzlistings, ERP, PIM, WMS, CRM, Accounting, Analysen und Consent-Systeme.
Das Register ist erst bereit, wenn jede kommerziell wichtige Abhängigkeit einen benannten Zielverantwortlichen besitzt. „Die App hat das gemacht“ ist kein ausreichender Nachweis.
Repräsentative Migrations-Testmuster auswählen
Die repräsentative Stichprobe soll wichtige Shopify-Entscheidungen sichtbar machen, ohne den gesamten Katalog abzubilden. Wählen Sie Datensätze bewusst und ergänzen Sie erwartete Zuständigkeiten.
| Muster | Zweck der Vorbereitung |
|---|---|
| Einfaches Product | Gewöhnliches Muster für Product, Collection, Bild und Bestand festlegen |
| Product mit vielen Varianten | Optionsbenennung, Variantenidentität, Bilder, Bestand und externe IDs sichtbar machen |
| Product mit strukturiertem Content | Anforderungen an Metafields oder Metaobjects sichtbar machen |
| Personalisiertes oder App-abhängiges Product | Customer-Eingabe oder Anwendungszuständigkeit sichtbar machen |
| Priorisierte Collection und URL | Gruppierung, Navigation, Content und Weiterleitungen sichtbar machen |
| Komplexer Customer | Adressen, Klassifikationen, externe IDs und Kontozugriffsplanung prüfen |
| Komplexer historischer Order | Positionsdetails, Rabatte, Fulfillment, Rückerstattungen und externe Referenzen prüfen |
| Lokalisierter oder marketspezifischer Datensatz | Sprache, Domain, Währung und regionalen Content-Umfang prüfen |
Für jedes Muster werden Quell-ID, gegebenenfalls Quell-URL, geschäftlicher Auswahlgrund, erwarteter Shopify-Eigentümer, zugehörige externe IDs und bekannte Ausschlüsse dokumentiert. Das Register ist bereit, wenn jeder ausgewählte Datensatz eine Quellerwartung, relevante Kennungen, bekannte Ausschlüsse und einen benannten Prüfer besitzt.
Shopify-Bereitschaftsgate abschließen
Vor Terminierung des Migrationslaufs erfolgt eine abschließende Prüfung.
| Bereitschaftsfrage | Erforderlicher Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Sind erforderliche Zugriffe verfügbar? | Zugriffsprotokoll und verantwortliche Kontakte | Erforderliche Source- und Shopify-Bereiche sind erreichbar |
| Sind Product-Familien klassifiziert? | Product-Familienmatrix | Jedes wichtige Product-Muster besitzt einen Zieleigentümer |
| Sind Collection- und URL-Entscheidungen vollständig? | Routeninventar und Collection-Entwurf | Priorisierte Routen besitzen Ziele oder Stilllegungsentscheidungen |
| Sind Customer- und Order-Muster erklärt? | Customer- und Order-Nachweispaket | Historische und kontobezogene Beziehungen sind dokumentiert |
| Sind Apps und externe Systeme inventarisiert? | Abhängigkeitsregister | Jede wichtige Abhängigkeit besitzt einen fortbestehenden Eigentümer |
| Sind Quell-Backups und Exporte aktuell? | Datiertes Archiv und Prüfsumme oder Dateiliste | Quellnachweise können unabhängig vom Live-Shop wiederhergestellt werden |
| Sind repräsentative Migrationsmuster ausgewählt? | Musterregister | Die Auswahl deckt gewöhnliche und außergewöhnliche Datensätze ab |
| Sind offene Punkte zugeordnet? | Entscheidungsprotokoll | Jeder offene Punkt hat Eigentümer und Fälligkeitsdatum |
Vorbereitungsbereit ist die Migration, wenn keine kritische Product-, Customer-, Order-, URL- oder Integrationsentscheidung mehr von undokumentierten Annahmen abhängt. Die Abschlussprüfung sollte außerdem bestätigen, dass das Nachweispaket auch außerhalb des Teams verständlich ist, das den Quellshop aufgebaut hat. Hängt eine Entscheidung davon ab, dass eine einzelne Person sich an die Funktionsweise einer alten App oder eines Feldes erinnert, muss dieses Wissen vor Terminierung des Migrationslaufs dokumentiert werden.
Fazit
Die Shopify-Vorbereitung sollte ein praktisches Nachweispaket und keine generische Checkliste erzeugen. Products und Varianten brauchen definierte Zuständigkeiten, Collections müssen von Navigation und URLs getrennt werden, Customer-Identität ist von Konto- und Anwendungsverhalten zu unterscheiden, historische Orders brauchen repräsentative Nachweise und jede App beziehungsweise externe Kennung benötigt einen fortbestehenden Eigentümer.
Sind diese Entscheidungen vor dem repräsentativen Migrationstest dokumentiert, kann das Migrationsteam die beabsichtigte Shopify-Darstellung prüfen, statt das Zielmodell erst aus isolierten migrierten Datensätzen abzuleiten.
Häufige Fragen
Welches Shopify-Vorbereitungsdokument sollte zuerst erstellt werden?
Beginnen Sie mit der Zielentscheidungsmatrix für Products, Collections, Customers, Orders, Content, Markets, Apps und externe Systeme. Sie bestimmt, welche Exporte, Muster und Verantwortlichen für den Rest des Vorbereitungspakets erforderlich sind.
Wie viele Products sollten für einen repräsentativen Migrationstest ausgewählt werden?
Verwenden Sie die kleinste Auswahl, die jedes wichtige Product-Muster abdeckt: einfach, variantenreich, mit strukturiertem Content, personalisiert, gebündelt oder abonnementsbasiert, lokalisiert und extern synchronisiert. Verhaltensabdeckung ist wichtiger als eine feste Anzahl.
Sollten alle benutzerdefinierten Quellfelder Shopify Metafields werden?
Nein. Manche Werte gehören in Metafields oder Metaobjects, andere in Product-Content, Varianten, Apps, externe Systeme oder einen bewussten Ausschluss. Klassifizieren Sie das Feld nach Zweck und fortbestehendem Verbraucher, bevor Sie das Ziel wählen.
Welche Customer-Account-Informationen benötigen besondere Vorbereitung?
Bereiten Sie Identitätsregeln, Umgang mit doppelten Konten, Adressbeispiele, Customer-Klassifikationen, externe IDs und den Kommunikationsansatz für wiederkehrende Customers vor. Nehmen Sie nicht an, dass Quellzugangsdaten einfach weiterverwendet werden können.
Was gehört in das Shopify-URL-Inventar?
Priorisierte Product-, Collection-äquivalente, CMS-Page-, Blog-Post-, Policy-, Kampagnen-, lokalisierte und extern verlinkte Routen. Jede benötigt ein vorgesehenes Shopify-Ziel oder eine explizite Stilllegungsentscheidung.
Wann ist das Shopify-Bereitschaftsgate abgeschlossen?
Wenn erforderliche Zugriffe funktionieren, Quellnachweise wiederherstellbar sind, wichtige Datensätze dokumentierte Zieleigentümer besitzen, repräsentative Muster die reale Komplexität abdecken und jeder offene Punkt einem Verantwortlichen zugeordnet ist.