Die Datenmodellbewertung für Shopify als mögliche Zielplattform beginnt damit, die Quellstrukturen und ihre Beziehungen in der Zielrepräsentation einzuordnen. Eine Migration zu Shopify ist eine Übersetzung in ein gehostetes Commerce-Modell mit klaren Rollen für Products, Varianten, Collections, Menüs, Customers, Orders, Inhalte, Metafields, Metaobjects, Apps und Integrationen. Quellstrukturen stimmen nur selten eins zu eins mit Shopify überein. Eine Source Category kann zu einer Collection, einem Menüeintrag, einer Seite, einem Filter, einer Weiterleitung oder einer internen Klassifikation werden; ein benutzerdefiniertes Feld kann in ein natives Feld, Metafield, eine Metaobject-Referenz, einen App-eigenen Wert oder einen bewusst ausgeschlossenen Datenpunkt überführt werden.
Das Ziel sollte die geschäftliche Bedeutung bewahren, die nach dem Launch erforderlich ist, und nicht zufällige Strukturen nachbauen, die über Jahre durch Workarounds auf der Quellplattform entstanden sind. Dafür müssen Beziehungen übersetzt werden: Product zu Variante, Collection zu Produktfindung, Customer zu Order, Inhalt zu URL-Ziel und externe Kennung zu dem System, das sie weiterhin nutzt.
Warum Unterschiede im Datenmodell wichtig sind
Shopify ist eine gehostete SaaS-Zielplattform mit plattformdefinierten Strukturen für Katalog-, Shopdarstellungs-, Customer-, Order-, Content- und Konfigurationsdaten. Dieses Modell kann den Zielshop leichter verwaltbar machen, bedeutet aber zugleich, dass die Quellplattform nicht mechanisch kopiert werden sollte.
Eine Quellplattform kann Categories, Datenbankattribute, Erweiterungen, Module, benutzerdefinierte Felder, eigene Product-Typen, Multi-Store-Logik oder Theme-spezifische Daten verwenden, um Geschäftsfunktionen bereitzustellen. Shopify kann denselben geschäftlichen Zweck über Products, Optionen, Varianten, Collections, Product category, Product type, Tags, Metafields, Metaobjects, Apps, Themes, Markets, URL-Weiterleitungen oder eine separate Einrichtung im Zielshop darstellen.
Ziel ist nicht strukturelle Gleichheit, sondern Nutzbarkeit im Zielshop. Ein gutes Shopify-Datenmodell bewahrt die kommerzielle und betriebliche Bedeutung, die zählt: Kunden können Products korrekt auswählen, die richtigen Gruppen durchsuchen, passende Inhalte lesen, auf nützlichen Konto- und Order-Kontext zugreifen, wichtige URLs erreichen und sich auf App-gestützte Funktionen verlassen, sofern diese zum erwarteten Launch-Umfang gehören.
| Bedeutung auf der Quellplattform | Mögliches Shopify-Ziel | Planungsfrage |
|---|---|---|
| Kaufrelevanter Product-Unterschied | Product-Option, Variante, SKU, Preis, Bestand, Medien oder App-gestütztes Verhalten | Ist der Unterschied eine echte Kaufentscheidung oder nur beschreibende Information? |
| Category oder Abteilung | Collection, Menü, Filter, Product category, Product type, Tag, Seite oder Weiterleitung | Unterstützt die Struktur die Produktfindung oder nur historische Organisation? |
| Benutzerdefiniertes Feld | Natives Feld, Metafield, Metaobject, App-eigenes Feld, Integrationsreferenz oder bewusster Ausschluss | Wer nutzt den Wert nach dem Launch und wo muss er angezeigt oder verarbeitet werden? |
| Daten aus Erweiterung, Modul oder App | Shopify-App-Einrichtung, Metafields, Integrationsplanung, manuelle Konfiguration oder separate Anwendungsarbeit | Sind die Daten auch ohne das ursprüngliche Verhalten noch nützlich? |
| Internationale oder Multi-Store-Struktur | Markets, Domains, Sprachen, Währungen, Kataloge, Weiterleitungen oder Planung separater Shops | Welche regionalen Unterschiede müssen nach dem Launch sichtbar und nutzbar sein? |
| SEO-relevante URL | Shopify-Handle, Route, Weiterleitung, Collection-Pfad, Seitenpfad, Blog-Post-Pfad oder Bereinigungsentscheidung | Welche Quellpfade brauchen priorisierte Weiterleitungen und eine Prüfung der Zielseite? |
Unterschiede bei Katalog- und Product-Strukturen
Die Shopify-Katalogplanung beginnt mit den Beziehungen zwischen Products, Optionen, Varianten, Product category, Product type, Tags, Metafields, Medien und Bestand. Quellshops verwenden häufig vielfältigere Strukturen, insbesondere wenn sie von selbst gehosteten, erweiterungsintensiven oder individuell entwickelten Plattformen stammen.
Ein Product sollte den verkauften Artikel repräsentieren. Optionen sollten kundenorientierte Auswahldimensionen wie Größe, Farbe, Material, Packungsgröße, Oberfläche oder Konfiguration abbilden. Varianten sollten die kaufbaren Kombinationen dieser Optionen darstellen. Diese Logik ist klar, wenn der Quellkatalog echte Kaufentscheidungen bereits von beschreibenden Details trennt. Sensibler wird sie, wenn die Quellplattform konfigurierbare Products, gruppierte Products, benutzerdefinierte Optionen, Bundles, Kits, Personalisierungsfelder, optionale Zusatzleistungen oder Erweiterungslogik verwendet.
Product-Unterschiede sollten nach ihrer kommerziellen Funktion klassifiziert werden:
- echte kundenorientierte Kaufoptionen;
- Unterschiede bei SKU, Bestand, Preis, Barcode, Fulfillment oder Steuern;
- Product-Spezifikationen oder Kompatibilitätsmerkmale;
- variantenspezifische Bilder oder Medienreihenfolge;
- Personalisierungseingaben oder Verhalten benutzerdefinierter Optionen;
- Bundle-, Kit-, Abonnement- oder Zusatzlogik;
- betriebliche Kennungen für ERP-, Marktplatz-, Fulfillment-, Analyse- oder Berichtssysteme;
- veraltete Felder oder Erweiterungsreste, die Shopify nicht belasten sollten.
Nicht jede Option der Quelle sollte zu einer Shopify-Variante werden. Manche Werte lassen sich besser als Product-Inhalt, Metafield, Metaobject, Tag, App-Konfiguration, Theme-Darstellung, Integrationsdaten oder über einen definierten Anwendungs- beziehungsweise Datendesignpfad behandeln. Der praktische Prüfstein ist, ob die gewählte Shopify-Struktur sowohl Kaufklarheit als auch betriebliche Nutzbarkeit bewahrt.
Auch Shopify Product category und Product type müssen getrennt behandelt werden. Product category ordnet ein Product Shopifys Standardtaxonomie zu und kann Attribute, Vertriebskanäle, Steuern, Auffindbarkeit und Product-Organisation beeinflussen. Product type ist ein benutzerdefiniertes Organisationsfeld. Tags und Metafields können zusätzliche Organisation, Filterung oder Darstellung unterstützen, sollten aber nicht zum Sammelbecken für jedes Quellattribut werden.
Unterschiede bei Categories, Collections, Navigation und Struktur der Shopdarstellung
Source Categories tragen häufig mehrere Bedeutungen gleichzeitig. Sie können Hierarchie, Navigation, Landingpages, Product-Filterung, Merchandising-Gruppen, SEO-Pfade, interne Klassifikation, Kampagnenseiten oder gewohnte Browsing-Pfade der Kunden definieren. Shopify Collections können einen Teil dieser Bedeutung bewahren, sind aber nicht immer ein Eins-zu-eins-Ersatz für Source Categories.
Eine Source Category kann wie folgt behandelt werden:
| Rolle der Source Category | Zu prüfende Shopify-Behandlung |
|---|---|
| Kundenorientierte Product-Gruppe | Collection, Menüeintrag, Filtergruppe oder Landingpage |
| SEO-Landingpage | Collection mit Inhalt, Seite, Weiterleitungsziel oder Bereinigungsentscheidung |
| Interne Klassifikation | Product type, Tag, Metafield oder keine kundenorientierte Zielstruktur |
| Filter- oder Layered-Navigation-Kontext | Search-&-Discovery-Konfiguration, Tags, Metafields, Product-category-Attribute oder App-gestützte Filterung |
| Kampagnen- oder saisonale Gruppierung | Manuelle Collection, automatisierte Collection, Seite, Menüplatzierung oder archivierte Weiterleitung |
| Tiefe Legacy-Taxonomie | Vereinfachtes Collection-Modell plus Weiterleitungen für priorisierte Pfade |
Der Collection-Plan sollte anhand der Produktfindung durch Kunden beurteilt werden und nicht danach, ob die Anzahl der Categories erhalten bleibt. Kunden sollten die vorgesehenen Products weiterhin über Collections, Menüs, Suche, Filter, Empfehlungen und priorisierte Landingpages finden. Eine kleinere Shopify-Collection-Struktur kann stärker sein als eine kopierte Althierarchie, wenn sie klarere Navigation und saubereres Merchandising ermöglicht.
Auch das Theme-Verhalten spielt eine Rolle. Collection-Layout, Product-Cards, Menütiefe, Filter, Badges, Empfehlungen und individuelle Darstellungen können vom gewählten Theme und der App-Konfiguration abhängen. Die Migration von Category- oder Collection-Daten stellt das vollständige Browsing-Erlebnis im Shopdarstellung nicht automatisch wieder her.
Unterschiede bei Customer-, Konto- und Order-Daten
Customer- und Order-Migration sollten danach beurteilt werden, wie nützlich die Daten nach der Migration sind. Ein Customer-Datensatz kann in Shopify existieren, während Kontoerfahrung, Passworterwartungen, Loyalty-Kontext, Kundengruppenlogik, Kundendienst-Prozesse oder B2B-ähnliches Verhalten von der Quellplattform abweichen.
Customer-Daten sollten nach praktischer Bedeutung getrennt werden:
- Profildetails und Kontaktinformationen;
- Rechnungs- und Lieferadressen;
- Customer-Tags, Notizen und Segmentierungssignale;
- Marketingstatus und Kommunikationserwartungen;
- Zuordnung zur Order-Historie;
- Loyalty, Rewards, Mitgliedschaften, Großhandelsstatus oder Kontostufen;
- customerspezifische Kennungen externer Systeme;
- Erwartungen an Passwort, Login oder Aktivierung.
Customer-Datensätze und Kundenkonten sind unterschiedliche Planungsbereiche. Die Migration kann nützlichen Customer-Kontext bewahren, doch der Zugang wiederkehrender Kunden kann Kommunikation, Kontoaktivierung, Zielshop-Konfiguration, App-Prüfung oder Planung von Kundendienst-Prozessen erfordern.
Auch Order-Daten sollten als betrieblicher Kontext betrachtet werden und nicht nur als historische Datensätze. Eine nützliche Order-Migration hängt typischerweise von Positionen, Customer-Zuordnung, Summen, Steuern, Versand, Rabatten, Zahlungsstatus, Fulfillment-Status, Order-Notizen, Quellreferenznummern und Kundenservice-Kontext ab. Bestimmtes Order-Verhalten der Quelle kann aus Zahlungssystemen, Fulfillment-Werkzeugen, Rechnungen, Abonnements, Loyalty-Erweiterungen, Betrugswerkzeugen oder externen Systemen stammen. Dieses Verhalten ist von den Order-Datensätzen selbst zu trennen.
Praktisches Ziel ist eine Shopify-Order-Historie, die Kundenservice, betriebliche Nachschlagearbeit, Auswertungsprüfung und Kundenvertrauen unterstützt, sofern die Historie sichtbar ist. Exaktes Verhalten des Quellsystems darf nur vorausgesetzt werden, wenn dafür ein klares Shopify-Ziel existiert.
Unterschiede bei Content-, URL- und SEO-Daten
Eine Shopify-Content-Migration kann CMS Pages, Blog Posts, Product-Beschreibungen, Collection-Beschreibungen, Medien, interne Links, Metadaten, Handles, Menüs und Weiterleitungen umfassen. Die Bedeutung dieser Inhalte reicht über eine reine Textübertragung hinaus. Manche Inhalte stützen Vertrauen, Richtlinienkonformität, Versandinformationen, Retouren, Größenberatung, SEO, Kampagnen, Kaufberatung, Kundeninformation oder die Glaubwürdigkeit der Marke.
Inhalte sollten nach ihrem Zweck geprüft werden:
| Content- oder URL-Bereich | Auswirkung auf das Shopify-Datenmodell |
|---|---|
| CMS Pages | Können Seitenmigration, Navigationsplatzierung, Prüfung interner Links, Medienprüfung und Metadatenentscheidungen erfordern. |
| Blog Posts | Können Blog-Struktur, Artikelpfade, Medien, Metadaten, Autor-/Datumsanforderungen und Prüfung interner Links erfordern. |
| Product- und Collection-Beschreibungen | Sollten die Verkaufslogik und Theme-Darstellung des Zielshops unterstützen, nicht nur alten Text bewahren. |
| Source-Category-URLs | Können Collection-Ziele, Seitenziele, Weiterleitungen oder Bereinigungsentscheidungen erfordern. |
| Product-URLs | Benötigen Handle-Prüfung und Weiterleitungsplanung für priorisierte Pfade. |
| Gefilterte, Such- oder Query-String-URLs | Benötigen besondere Prüfung, da sie sich möglicherweise nicht wie gewöhnliche Product-, Collection-, Seiten- oder Blog-Post-Pfade verhalten. |
| Internationale oder lokalisierte URLs | Benötigen Market-, Sprach-, Domain-, Unterverzeichnis- und Weiterleitungsplanung, wenn regionale Verkäufe relevant sind. |
Shopifys URL-Struktur wird durch das Darstellungsmodell des Shops kontrolliert. Exakte Quellpfade können insbesondere für Products, Collections, CMS Pages, Blog Posts, gefilterte Routen und individuelle Pfade nicht immer bewahrt werden. Damit wird Weiterleitungsplanung Teil der Datenmodellübersetzung und nicht bloß eine abschließende SEO-Aufgabe.
Priorisierte URLs tragen eine Routenidentität, die im Zielmodell bewusst bewahrt werden muss. Dazu gehören typischerweise URLs mit organischem Traffic, bezahltem Kampagnenwert, Backlinks, Kunden-Lesezeichen, umsatzstarken Products, wichtigen Categories, Richtlinienseiten, Blog Posts und regionalen Landingpages. Jeder priorisierte Pfad benötigt deshalb ein explizites Shopify-Ziel und eine definierte Weiterleitungsbeziehung.
Unterschiede bei App-, Erweiterungs-, Integrations- und benutzerdefinierten Daten
Shopify-Shops hängen häufig von Apps, Themes und Integrationen ab. Das ist normal, doch App-gestütztes Verhalten darf nicht mit gewöhnlichen migrierten Daten verwechselt werden. Eine Erweiterung der Quellplattform kann Daten speichern, die nur dann sinnvoll sind, wenn eine Shopify-App, ein Theme oder eine Integration im Ziel sie tatsächlich verwenden kann.
Häufig sensible Bereiche sind:
- Product-Bewertungen und Ratings;
- Abonnements, Bundles, Kits, optionale Product-Zusätze oder Personalisierungslogik;
- Loyalty, Rewards, Mitgliedschaften und Customer-Stufen;
- erweiterte Suche, Filterung, Empfehlungen oder Merchandising-Regeln;
- Wholesale-, B2B-ähnliches Verhalten, customerspezifische Preise oder zugriffsbeschränkte Inhalte;
- Kennungen für ERP, Fulfillment, Marktplätze, PIM, CRM, Analysen, Buchhaltung oder Kundendienst;
- Lieferregeln, Versandlogik, Steuerannahmen, Rechnungen und zahlungsbezogener Kontext;
- individuelle Darstellung im Shopen, die durch Theme-Code oder App-Blocks gesteuert werden.
Für jede Abhängigkeit sollte der Migrationsplan das geschäftliche Ergebnis, die betroffenen Quelldaten, das Shopify-Ziel und das nach dem Launch benötigte Zielverhalten benennen. Manche Daten können in Metafields oder Metaobjects migriert werden. Andere benötigen einen App-Import, manuelle Konfiguration, explizite Zuordnung von Feldbeziehungen, Zielkonfiguration, Integrationsarbeit oder Datenneustrukturierung. Wieder andere sind den Aufwand einer Übertragung möglicherweise nicht wert.
Metafields und Metaobjects sind sinnvoll, wenn benutzerdefinierte Informationen einen Zielzweck besitzen. Metafields können Shopify-Ressourcen wie Products, Customers und Orders erweitern. Metaobjects können strukturierte Inhalte mit mehreren Feldern und wiederverwendbaren Einträgen modellieren. Keines von beiden stellt automatisch die Geschäftslogik der Quelle wieder her. Ein Wert kann in Shopify vorhanden und dennoch unsichtbar, ungenutzt oder betrieblich bedeutungslos sein, solange Theme, App, Prozess oder Integration ihn nicht verwendet.
Wie Datenmodellunterschiede den Migrationsumfang beeinflussen
Shopify-Datenmodellentscheidungen sollten den Migrationsumfang präziser machen. Zweck ist nicht, jedes Quellfeld zu reproduzieren. Stattdessen müssen die Bedeutungen identifiziert werden, die in Shopify nutzbar bleiben sollen, und dem jeweils richtigen Zielverantwortlichen zugeordnet werden.
Ein praktischer Umfang trennt vier Ergebnisse:
| Zuordnungsergebnis | Bedeutung in Shopify |
|---|---|
| Nativer Shopify-Datensatz | Die Quellbedeutung passt in ein unterstütztes Product, eine Variante, einen Customer, Order, Collection-bezogenen Datensatz, eine CMS Page, einen Blog Post, eine Weiterleitung oder ein anderes natives Ziel. |
| Shopify-Konfiguration oder Zuständigkeit für die Shopdarstellung | Der Datensatz kann existieren, seine Nutzbarkeit hängt aber von Collections, Menüs, Search-&-Discovery-Einstellungen, Theme-Sections, Markets, Kundenkonten oder anderer Zielshop-Konfiguration ab. |
| Zuständigkeit für strukturierte benutzerdefinierte Daten | Die Quellbedeutung gehört in ein definiertes Metafield, Category-Metafield, Metaobject, App-eigenes Feld oder eine Integrationsreferenz mit bekanntem Verbraucher. |
| Ausschließen, archivieren oder neu gestalten | Der Quellwert ist veraltet, dupliziert, von stillgelegter Erweiterungslogik abhängig oder besitzt keinen fortbestehenden Zweck für Shopdarstellung oder Betrieb. |
Diese Trennung verhindert falsche Vollständigkeit. Eine Collection kann existieren, ohne den alten Such- oder Browsing-Pfad zu bewahren. Ein Metafield kann den richtigen Wert enthalten, obwohl kein Theme, keine App und keine Integration ihn verwendet. Ein Customer kann existieren, ohne das Login-Modell der Quelle wiederherzustellen. Ein Order kann historische Details bewahren, ohne live Zahlungs-, Fulfillment- oder Abonnementverhalten zu rekonstruieren.
Das zentrale Planungsartefakt sollte eine Datenübersetzungsmatrix sein. Für jede wichtige Quellbedeutung benennt sie das Shopify-Ziel, die Beziehung, die intakt bleiben muss, das System oder Team, das sie nutzt, und jede im Zielshop benötigte Einrichtung. Diese Matrix schafft eine stabile Grundlage für spätere Migrationsentscheidungen, ohne Datensatzübertragung mit Konfiguration der Shopdarstellung, Anwendungsverhalten oder Zuständigkeit externer Systeme zu vermischen.
Shopify-Matrix zur Übersetzung von Beziehungen
Shopify-Zuordnungen werden klarer, wenn jede Quellbedeutung einem Zieldatensatz, einer Zielkonfiguration, einer verbundenen Anwendung oder einem bewussten Ausschluss zugeordnet wird. Die folgende Matrix hält diese Entscheidung von der reinen Feldverfügbarkeit getrennt.
| Quellbedeutung | Frage zur Shopify-Darstellung | Erforderliche Zielbedeutung |
|---|---|---|
| Kaufbare Product-Familie | Welche Daten gehören zum Product, seinen Varianten, Medien, Inventory Items und Locations? | Jede kaufbare Kombination besitzt die richtige SKU, den richtigen Preis, Optionswerte, Bild und Bestandsbeziehung. |
| Browsing-Hierarchie | Welche Source Categories werden Collections, Menüs, Filter, Seiten, Weiterleitungen oder nur interne Organisation? | Priorisierte Such- und Browse-Pfade führen Käufer zum vorgesehenen Product-Set ohne doppelte oder verwaiste Ziele. |
| Strukturierte Anreicherung | Soll der Wert natives Feld, Metafield, Metaobject-Referenz, Tag, Taxonomiewert oder Attribut eines externen Systems werden? | Der Wert ist für Theme, Anwendung, Prozess oder Integration sichtbar beziehungsweise konsumierbar, die ihn benötigt. |
| Customer-Identität | Welche Werte gehören in Customer-Profil, Adressen, Tags, Notizen, Marketingstatus, B2B-Kontext oder nur in historische Orders? | Mitarbeitende können Käufer identifizieren und Historie verstehen, ohne nicht unterstütztes Kontoverhalten zu erfinden. |
| Historische Transaktion | Welche Order-, Zahlungs-, Fulfillment-, Rückerstattungs-, Rabatt-, Steuer- und externe Referenzdaten bleiben nützlich? | Kundenservice und Abstimmung können die Transaktion verstehen, ohne Historie mit Live-Konfiguration zu verwechseln. |
| Content- und URL-Wert | Welche Seiten, Blog Posts, Handles, Medien, Metadaten, Menüs und Weiterleitungen benötigen ein Shopify-Ziel? | Priorisierte URLs werden bewusst aufgelöst und wichtige Inhalte bleiben auffindbar. |
| App- oder Integrationszustand | Welches System besitzt die Daten nach dem Launch und welche systemübergreifende Kennung verbindet sie? | Der fortbestehende Eigentümer kann den migrierten Datensatz finden und nutzen, ohne doppelte Datenquellen zu erzeugen. |
Ein Shopify-Datenmodell sollte anhand von Beziehungen und nicht anhand von Datensatzanzahlen beurteilt werden. Eine Variantenanzahl kann übereinstimmen, obwohl Optionswerte die falschen Kaufdimensionen darstellen; ein Metafield kann existieren, obwohl kein Theme oder keine App es verwendet; ein Customer kann existieren, obwohl historische Orders nicht wie vorgesehen zugeordnet sind; und eine Collection kann existieren, obwohl Menüs weiter auf veraltete Pfade zeigen. Die Übersetzungsmatrix sollte deshalb sowohl den Zieldatensatz als auch die Beziehung dokumentieren, die ihm geschäftliche Bedeutung gibt.
Repräsentative Beispiele stärken diese Matrix. Eine komplexe Product-Familie kann zeigen, wie Optionen, Varianten, Medien, Bestand und Kennungen zusammenhängen. Ein wertvoller Category-Pfad kann zeigen, wie Collections, Menüs, Filter und Weiterleitungen Verantwortung aufteilen. Ein Customer mit mehreren Orders kann zeigen, wie Identität und Transaktionshistorie verbunden bleiben. Eine App-eigene Kennung kann zeigen, welches System den Wert nach dem Launch weiterhin besitzt.
Fazit
Unterschiede im Shopify-Datenmodell sind relevant, weil Shopify Bedeutungen der Quellplattform in ein gehostetes Plattformmodell übersetzt. Products, Varianten, Collections, Product category, Product type, Tags, Metafields, Metaobjects, Customers, Orders, CMS Pages, Blog Posts, Apps, Themes, Markets, Weiterleitungen und Integrationen erfüllen jeweils eine eigene Rolle in der Zielplattform.
Eine belastbare Shopify-Migration versucht nicht, jede Quellstruktur exakt zu bewahren. Sie erhält die geschäftliche Bedeutung, die nach dem Launch weiterbestehen soll. Werden Kataloglogik, Collection-Bedeutung, Customer- und Order-Kontext, Inhalte, URLs, benutzerdefinierte Felder, App-gestütztes Verhalten und Integrationskennungen bewusst übersetzt, lässt sich der Shopify-Shop leichter betreiben und steuern.
Häufige Fragen
Sind Shopify Collections dasselbe wie Source Categories?
Nein. Shopify Collections können manche Rollen von Source Categories übernehmen, doch Categories können zusätzlich Navigation, Filter, Landingpages, SEO-Wert, interne Gruppierung oder Merchandising-Regeln repräsentieren. Priorisierte Browsing-Pfade sollten in ein Shopify-Modell zur Produktfindung übersetzt und nicht eins zu eins kopiert werden.
Sollte jedes benutzerdefinierte Quellfeld zu einem Shopify Metafield werden?
Nein. Metafields sind sinnvoll, wenn das Feld einen klaren Zielzweck hat. Veraltete oder doppelte Felder, Erweiterungsreste oder Werte ohne Shopdarstellungs-, Betriebs-, Integrations- oder Berichtszweck erschweren die Wartung des Zielshops.
Werden Shopify Apps automatisch von der Quellplattform migriert?
Nein. Apps, Erweiterungen, Module und Theme-Verhalten sind keine gewöhnlichen migrierten Datensätze. Der Migrationsplan muss festlegen, welches Quellverhalten Shopify-App-Konfiguration, Zielshop-Einrichtung, direkte Feldzuordnung, Integrationsarbeit oder zielseitige Datenneustrukturierung erfordert.
Kann Shopify dieselbe Kundenkontoerfahrung wie die Quellplattform bewahren?
Customer-Datensätze und Kundenkontoerfahrung sollten getrennt geplant werden. Migrierte Customers können nützlichen Profil- und Order-Historienkontext bewahren; Login-Verhalten, Aktivierung, Passworterwartungen, Loyalty-Kontext und Kundenkommunikation können jedoch eigene Zielplanung benötigen.
Wie sollten Shopify Metafields und Metaobjects aufgeteilt werden?
Ein Metafield eignet sich, wenn benutzerdefinierte Daten eine bestimmte Shopify-Ressource wie Product, Variante, Customer oder Order erweitern. Ein Metaobject eignet sich, wenn die Information ein wiederverwendbares strukturiertes Objekt mit mehreren Feldern bildet, etwa einen Spezifikationsblock, ein Autorenprofil, einen Inhaltsstoffdatensatz, eine Größentabelle oder eine Markengeschichte. In beiden Fällen muss feststehen, wer die Daten nutzt und wie sie im Zielshop dargestellt oder verarbeitet werden.
Wie sollten Kennungen externer Systeme in Shopify bewahrt werden?
Eine externe Kennung sollte nur erhalten bleiben, wenn ein aktiver ERP-, PIM-, CRM-, Fulfillment-, Marktplatz- oder Berichtsprozess weiterhin davon abhängt. Sie muss an der Shopify-Ressource oder dem Integrationsdatensatz gespeichert werden, den das fortbestehende System erwartet; Eindeutigkeit, Format und Suchverhalten müssen mit diesem System konsistent bleiben. Eine ungenutzte Kennung sollte nicht zu dauerhaftem Metadatum der Shopdarstellung werden.