Wird Shopify Plus als mögliche Zielplattform bewertet, muss das Datenmodell zeigen, wie Quelldaten, Beziehungen und Geschäftsbedeutung im Ziel dargestellt werden. Die Datenmodellierung für Shopify Plus beginnt mit Shopifys Datengrundlage und ergänzt sie um Enterprise-Bedeutung rund um Organisationsstruktur, B2B, Markets, mehrere Stores, Integrationen, Berechtigungen und Prozessverantwortung. Products, Varianten, Collections, Customers, Orders, Pages, Blog Posts, Redirects, Metafields und Apps bleiben zentral. Der Unterschied auf Plus-Ebene besteht darin, dass viele dieser Datensätze deutlich mehr geschäftliche Bedeutung tragen können als bei einer Migration in einen einzelnen Shopify-Store.
Das ist wichtig, weil Enterprise-Quellplattformen Commerce-Logik häufig in Strukturen speichern, die sich nicht sauber in gewöhnliche Shopify-Datensätze übersetzen lassen. Magento oder Adobe Commerce können Customer Groups, Websites, Stores, Store Views, Product Attributes, Preisregeln, Shared Catalogs, B2B-Accounts und Extension-eigene Daten verwenden. Eine individuelle Plattform kann proprietäre Tabellen, ERP-Kennungen, individuelle Checkout-Regeln, rollenbasierte Käuferberechtigungen oder regionale Catalogs besitzen. Shopify Plus kann viele Enterprise-Ergebnisse unterstützen, doch die Migrationsplanung muss entscheiden, ob eine Quellstruktur zu Shopify-Daten, Shopify-Plus-Setup, App-Konfiguration, direktem Feld-Mapping, zielseitigem Datenentwurf, Integrationsarbeit oder einem neu gestalteten Prozess werden soll.
Shopify Plus nutzt Shopify-Daten mit Enterprise-Governance
Shopify Plus ist keine von Shopify getrennte Datenplattform. Die Kerndaten folgen weiterhin Shopify-Konzepten: Products enthalten Varianten, Collections gruppieren Products, Customers und Orders bewahren Käufer- und Transaktionshistorie, Pages und Blog Posts tragen Content, Redirects unterstützen Traffic-Kontinuität und Metafields oder Metaobjects erweitern strukturierte Informationen. Die Migrationsplanung sollte deshalb das Shopify-Modell bewahren, statt in Shopify Plus ein eigenes Enterprise-Datenmodell zu erfinden.
Die Enterprise-Ebene verändert, wie dieses Modell gesteuert wird. Ein Product muss vielleicht mehrere Markets, verschiedene Storefronts, B2B-Verfügbarkeit, ERP-SKU-Kontinuität, eigene Metafields oder App-gesteuertes Merchandising unterstützen. Ein Customer muss möglicherweise von Company Account, Käuferrolle, Location, Zahlungsbedingungen oder regionaler Vertriebsstruktur getrennt werden. Eine Storefront kann ein einzelner Store mit Markets oder einer von mehreren Expansion Stores innerhalb einer Organisation sein. Diese Entscheidungen sind nicht kosmetisch; sie bestimmen, wie migrierte Daten nach dem Launch genutzt werden.
| Datenbereich | Kernbedeutung in Shopify | Bedeutung bei einer Shopify-Plus-Migration |
|---|---|---|
| Products und Varianten | Verkaufbare Katalogstruktur. | Enterprise-SKU-Logik, B2B-Verfügbarkeit, marktspezifisches Merchandising, ERP-Referenzen und Product-Governance. |
| Collections | Product-Gruppierung für Navigation und Merchandising. | Entscheidungen zu regionaler, marken-, kanal-, B2B- und kampagnenbezogener Segmentierung. |
| Customers | Käuferprofile und Order-Historie. | D2C-Käufer, B2B-Kontakte, Company-Beziehungen, Käuferrollen und Account-Verantwortung. |
| Orders | Historischer Transaktionskontext. | Support, Abstimmung, B2B-Order-Prüfung, Zahlungsbedingungen, Fulfillment-Nachweise und Integrationsreferenzen. |
| Metafields und Metaobjects | Strukturierte Erweiterungen für Custom Data. | Product-Enrichment, Content-Modelle, Integrationskennungen, B2B-Attribute und betrieblicher Enterprise-Kontext. |
| Stores und Organisation | Admin- und Storefront-Umgebungen. | Mehrere Stores, Governance, Berechtigungen, Sicherheit, Abrechnung und Betriebsverantwortung. |
Die Migration darf diese Unterschiede nicht auf einfachen Datensatztransfer reduzieren. Für jede geschäftskritische Enterprise-Struktur der Quelle muss die Zielbedeutung definiert werden.
Products, Varianten und die Bedeutung des Enterprise-Catalogs
Shopify-Products und -Varianten bleiben die erste Ebene der Katalogprüfung. Source Products mit Größen, Farben, Einheiten, Bundles, Kits, konfigurierbaren Optionen, Subscription-Auswahl oder ERP-gesteuerten SKUs müssen gegen Shopifys Product- und Variantenstruktur interpretiert werden. Shopify Plus hebt diese Entscheidung nicht auf; vielmehr werden die Folgen größer, weil dieselben Katalogdaten mehrere Marken, Markets, B2B-Catalogs, Storefronts und externe Systeme unterstützen können.
Ein einfacher D2C-Catalog lässt sich oft mit wenig zusätzlicher Interpretation in Products und Varianten überführen. Ein Enterprise-Catalog erfordert meist eine tiefere Einordnung. Source Attributes können beschreibender Content, suchbare Spezifikationen, variantenbildende Optionen, Filtereingaben, ERP-Kennungen, B2B-Zugriffsmarker, marktspezifische Werte oder App-eigene Logik sein. Werden alle Attributes nur als Beschreibung behandelt, können Merchandising, Suche und Integrationen an Aussagekraft verlieren.
| Quell-Katalogmuster | Planungsfrage für Shopify Plus |
|---|---|
| Konfigurierbares Product mit vielen Source Attributes | Welche Attributes definieren Shopify-Varianten, welche werden Metafields und welche bleiben extern? |
| Product-Sichtbarkeit nach Source Customer Group | Soll die Sichtbarkeit über B2B-Catalogs, Store-Trennung, App-Regeln oder ein separates Datendesign gesteuert werden? |
| Regionale Product-Namen oder -Beschreibungen | Soll das Ziel Markets/Lokalisierung, getrennte Stores, Übersetzungsprozesse oder Content-Neuaufbau verwenden? |
| ERP-SKU oder Product-ID | Soll die Kennung als SKU, Metafield, App-Datum oder Integrationsreferenz erhalten bleiben? |
| Bundle, Kit, Subscription oder konfigurierbares Paket | Soll Shopify- oder App-Setup, zielseitiges Redesign oder manuelle Konfiguration verwendet werden? |
| Enterprise-Product-Enrichment | Sollen strukturierte Daten zu Metafields, Metaobjects, App-Daten oder Theme-/Content-Setup werden? |
Product-Migration ist am stärksten, wenn jedes Quellfeld einen klaren Zweck im Ziel besitzt. Ziel ist nicht, jedes Enterprise-Feld in Shopifys native Product-Struktur zu zwingen, sondern die Informationen zu erhalten, die im Shopify-Plus-Betriebsmodell weiterhin nutzbar sein müssen.
Collections, Navigation und Storefront-Segmentierung
Collections entsprechen nicht automatisch den Categories jeder Quellplattform. Manche Quellplattformen verwenden Categories gleichzeitig als Datenbankhierarchie, Storefront-Navigation, Merchandising-Seiten, SEO-Landing-Pages, Reporting-Gruppen oder Zugriffskontrolle. Shopify Collections können Product-Gruppierung und Storefront-Merchandising unterstützen, doch der Migrationsplan muss entscheiden, ob eine Quellgruppierung zu Shopify Collection, Navigationseintrag, Page, Redirect-Ziel, marktspezifischem Erlebnis, B2B-Catalog-Regel oder bewusst ausgeschlossener historischer Struktur werden soll.
Shopify Plus ergänzt Segmentierungsfragen. Ein Händler betreibt vielleicht getrennte Stores für Marken oder Regionen. Ein anderer nutzt einen Store mit Markets und lokalisiertem Content. Ein B2B-Händler benötigt eventuell Product-Verfügbarkeit je Company oder Catalog statt nur über öffentliche Collections. Diese Zielentscheidungen bestimmen, wie die Bedeutung von Category und Collection abgebildet wird.
| Bedeutung der Quellgruppierung | Geeignetere Shopify-Plus-Interpretation |
|---|---|
| Öffentlicher Navigationspfad für Customers | Shopify Collection, Navigation und Storefront-Prüfung. |
| SEO-Landing-Page | Entscheidung über Collection, Page, Redirect, Metadaten oder Content-Neuaufbau. |
| Regionale Storefront-Gruppierung | Markets/Lokalisierung oder Planung von Expansion Stores. |
| B2B-exklusive Zugriffsgruppe | B2B-Catalog, App-Regel oder separates Storefront-Design. |
| Interne Reporting-Gruppe | Metafield, Tag, App-Daten oder Ausschluss aus der öffentlichen Storefront. |
| Historische Category ohne Nutzung | Bewusster Ausschluss, Archivbehandlung oder Redirect-Ziel. |
Entscheidend ist die Bedeutung. Dieselbe Source Category kann mehrere Funktionen erfüllen. Shopify-Plus-Planung muss die Funktionen erhalten, die nach dem Launch relevant bleiben, nicht nur die Namen der Categories.
B2B-Companies sind keine gewöhnlichen Customers
B2B gehört zu den wichtigsten Datenmodellunterschieden von Shopify Plus. Bei einer gewöhnlichen Shopify-Migration repräsentieren Customer-Datensätze meist Käuferprofile mit Kontaktdaten und Order-Historie. In Shopify Plus B2B kann ein Geschäftskäufer innerhalb einer Company-Struktur existieren müssen. Die Company ist die übergeordnete Organisation; Company Locations tragen standortspezifischen Einkaufskontext wie Adressen, Steuerinformationen, Catalogs, Zahlungsbedingungen und zugewiesene Kontakte. Ein Customer-Profil kann mit einer oder mehreren Company Locations verbunden sein. Käuferidentität und Business-Account-Kontext dürfen deshalb nicht in einem einzigen Customer-Tag zusammengefasst werden.
Eine Quellplattform kann B2B auf viele Arten abbilden: Customer Groups, Company Accounts, Quote-Prozesse, Account-Hierarchien, Vertrags-Catalogs, Shared Catalogs, steuerbefreite Käufer, Beziehungen zu Vertriebsmitarbeitern, ERP-Account-IDs, Freigabeberechtigungen oder Custom Fields. Diese Strukturen dürfen nicht blind als gewöhnliche Customer-Tags oder Notizen migriert werden, sofern genau das nicht die beabsichtigte Zielbedeutung ist.
| B2B-Struktur der Quelle | Zielfrage für Shopify Plus |
|---|---|
| Customer Group | Ist sie Segment, Company-Attribut, Preiskontext, Catalog-Regel oder historisches Label? |
| Company Account | Soll daraus eine Shopify-B2B-Company mit Company Locations oder eine andere definierte Account-Struktur werden? |
| Käuferrolle oder Berechtigung | Welcher Customer-Kontakt gehört zu welcher Company Location und welche Einkaufsrolle muss erhalten bleiben? |
| Vertragspreise | Gehören die Preise zu B2B-Catalogs, App-Preisen oder einem externen Preissystem? |
| ERP-Account-Kennung | Soll Company ID, Company Location ID, Metafield oder eine integrationsverwaltete Referenz verwendet werden? |
| Quote- oder Freigabeprozess | Handelt es sich um Shopify-seitiges Setup, einen App-Prozess oder nicht unterstütztes Source-Verhalten? |
Diese Trennung verhindert einen wesentlichen Migrationsfehler: Customers werden zwar als migriert gezählt, die kommerzielle Architektur, die sie für B2B nutzbar machte, geht jedoch verloren.
Markets, Lokalisierung und Multi-Store-Strukturen
Shopify-Plus-Händler wechseln häufig von Plattformen mit Websites, Store Views, Locales, Regionen, Marken, Domains oder marktspezifischen Catalogs. Diese Quellstrukturen müssen anhand des vorgesehenen Shopify-Plus-Betriebsmodells interpretiert werden. Ein einzelner Shopify-Plus-Store mit Markets unterscheidet sich von mehreren Stores innerhalb einer Organisation; die Wahl beeinflusst Product-Zuordnung, Content-Eigentum, Customer-Identität, Domains, Redirects, Integrationen und regionale Markenstrategie.
Eine Quellshop View entspricht nicht automatisch einem Shopify Market. Eine regionale Domain erfordert nicht zwingend einen separaten Shopify-Plus-Store. Eine Sprachversion kann zu Übersetzungs- und Lokalisierungssetup gehören statt zu einem eigenen migrierten Content-Baum. Eine Source Website kann Marke, Region, Kanal oder eine historische Implementierungsentscheidung darstellen, die nicht mechanisch kopiert werden sollte.
| Quellstruktur | Mögliche Shopify-Plus-Interpretation |
|---|---|
| Store View oder Sprach-View | Lokalisierungs- und Übersetzungssetup oder separate Storefront, wenn Governance dies verlangt. |
| Länderspezifische Domain | Market, Domain-Strategie, Redirect-Plan oder Entscheidung für Expansion Store. |
| Regionaler Catalog | Product-Verfügbarkeitsregeln, Markets-Setup, B2B-Catalog, App-Logik oder separater Store. |
| Multi-Brand-Source-Site | Expansion Store, separater Store, Collections oder markenspezifische Content-Architektur. |
| Lokalisierte CMS Pages | Pages, Blog Posts, Übersetzungen, Metaobjects, Redirects oder manueller Content-Neuaufbau. |
| Regionale Preise | Markets-Preise, B2B-Catalog-Preise, App-Konfiguration oder externe Systemlogik. |
Die Datenmodellfrage lautet damit nicht nur, wohin Datensätze gehen. Entscheidend ist, welche Ziel-Betriebsstruktur diese Datensätze unterstützen sollen.
Metafields, Metaobjects und Governance für Custom Data
Metafields und Metaobjects sind wichtige Werkzeuge für Shopify-Plus-Migrationen, dürfen aber nicht zum Ablageort für jedes Quellfeld werden. Metafields erweitern vorhandene Shopify-Ressourcen wie Products, Customers, Varianten, Orders oder andere Objekte. Metaobjects bilden strukturierte Objekte mit mehreren Feldern ab, die von Metafields referenziert, in Themes verwendet oder als Content-/Dateneinträge verwaltet werden können.
Bei Shopify Plus muss Custom-Data-Planung besonders diszipliniert sein, weil Enterprise-Quellplattformen häufig große Mengen an Attributes, Spezifikationen, Custom Fields, ERP-IDs, Market-Flags, B2B-Labels, Merchandising-Content und App-eigenen Datensätzen enthalten. Manche Felder sind für sichtbaren Content relevant, andere für Integrationen, historische Zwecke oder gar nicht mehr. Einige benötigen Felddefinitionen, Datenregeln oder Theme-Setup; andere sollten nicht migriert werden.
| Typ von Custom Data | Möglicher Behandlungspfad |
|---|---|
| Product-Spezifikationen | Product-Metafields, Category Metafields, Metaobjects oder App-Daten. |
| Wiederverwendbare Rich-Content-Blöcke | Metaobjects, Pages, Blog Posts, Theme Sections oder manueller Content-Neuaufbau. |
| ERP-/CRM-/PIM-Kennungen | Metafields, App-eigene Felder, native External ID oder Integrationsreferenz. |
| B2B-Account-Kontext | Company- und Company-Location-Setup, Customer-Metafields oder App-eigene Daten. |
| Daten einer Source Extension | App-Migration, Integrations-Mapping, Archivierung oder Redesign, wenn kein natives Ziel existiert. |
| Historische Reporting-Felder | Ausschluss, Archiv, Metafield oder Entscheidung für externes Reporting. |
Das beste Shopify-Plus-Datenmodell ist nicht das mit den meisten migrierten Custom Fields. Es ist das Modell, in dem jedes Custom Field einen definierten Ziel-Owner, ein klares Anzeigeverhalten, eine Datenqualitätsregel und einen geschäftlichen Zweck besitzt.
Orders, Payments, Fulfillment und Prozesskontext
Order-Migration zu Shopify Plus sollte historische Bedeutung erhalten, ohne zu suggerieren, dass jeder Source-Prozess neu erstellt wird. Source Orders können Payment-Labels, Versandmethoden, Rabatte, Steuerkontext, Fulfillment-Status, Teillieferungen, Refunds, Quotes, Invoices, Purchase-Order-Referenzen, ERP-IDs oder Vertriebsdaten enthalten. Ein Teil davon kann als historischer Order-Kontext lesbar bleiben. Anderes gehört zu Shopify-Setup, App-Konfiguration, externen Integrationen oder einem neu gestalteten Zielprozess.
Diese Trennung ist für Plus-Händler besonders wichtig, weil historische Orders Customer Service, B2B-Account-Prüfung, Wholesale-Nachbestellungen, finanzielle Abstimmung, ERP-Matching und Fulfillment-Analyse unterstützen können. Migrierte Order-Historie konfiguriert jedoch weder Live-Checkout noch Payment Processors, Steuerlogik, Fulfillment Routing, Purchase-Order-Prozesse oder B2B-Zahlungsbedingungen.
| Source-Order-Kontext | Interpretation für Shopify Plus |
|---|---|
| Payment-Referenz | Historischer Kontext, kein Live-Payment-Setup. |
| Fulfillment-Methode | Historische Lesbarkeit plus Prüfung des Ziel-Fulfillment-Setups. |
| Refund oder Stornierung | Historischer Support- und Abstimmungskontext. |
| Purchase-Order-Nummer | B2B-Order-Kontext, Metafield oder App-Daten oder externe Systemreferenz. |
| ERP-Order-ID | Native External ID, Metafield, App-Feld oder Integrationsreferenz. |
| Quote- oder Freigabehistorie | Historische Notiz, App-Prozess, B2B-Setup oder nicht unterstütztes individuelles Verhalten. |
Eine zuverlässige Shopify-Plus-Migration macht Order-Historie nutzbar, ohne Geschichte mit aktiver Betriebskonfiguration zu verwechseln.
Apps, Integrationen und Daten externer Systeme
Shopify-Plus-Händler sind häufig auf ERP-, PIM-, OMS-, CRM-, Subscription-, Loyalty-, Review-, Steuer-, Versand-, Fraud-, Analytics-, Marketplace-, Personalisierungs- und Automatisierungssysteme angewiesen. Manche Quellwerte sind native Commerce-Daten; andere gehören zu diesen Systemen und erscheinen in der Quellplattform nur, weil eine Extension oder Integration sie dorthin kopiert hat.
Bei der Übersetzung in das Zielmodell muss das weiterhin führende System bestimmt werden. Ein PIM kann für Enrichment verantwortlich bleiben. Ein ERP kann weiterhin Accounts, SKUs, Inventory- oder Order-Kennungen besitzen. Eine Subscription-Plattform kann Verträge und Abrechnungspläne besitzen. Eine Loyalty-App kann Salden und Stufenhistorie verwalten. Kopien in Shopify Plus zu speichern, überträgt weder Verantwortung noch erzeugt es den Prozess neu.
| Abhängigkeit | Datenmodellfrage |
|---|---|
| ERP | Welche Product-, Customer-, Company-, Company-Location-, Order- und Inventory-Kennungen müssen stabil bleiben? |
| PIM | Welche Attributes werden Shopify-Felder, Metafields oder Metaobjects und welche bleiben PIM-eigen? |
| OMS oder Fulfillment-System | Welche Order- und Fulfillment-Werte sind historischer Kontext und welche bleiben im verbundenen System operativ? |
| CRM | Welche Customer-Felder gehören in Shopify Plus und welche bleiben Beziehungsdaten im CRM? |
| Subscription-App | Welche Datensätze und Kennungen müssen über die App übertragen werden statt als gewöhnliche Orders dargestellt zu werden? |
| Loyalty- oder Review-App | Welche Salden, Memberships, Reviews und systemübergreifenden Schlüssel besitzen ein unterstütztes Ziel? |
Ein geschäftskritischer Wert sollte nicht nur deshalb migriert werden, weil ein Feld vorhanden ist. Er braucht einen benannten Owner, eine stabile Kennung, eine definierte Shopify-Plus-Abbildung, falls erforderlich, und einen fortbestehenden Verbraucher. Fehlen diese Voraussetzungen, kann Archivierung, Prozessneugestaltung oder der Verbleib im externen System die bessere Entscheidung sein als eine weitere unverwaltete Kopie.
Fazit
Die Unterschiede des Shopify-Plus-Datenmodells betreffen nicht nur Shopify-Felder. Sie betreffen die Enterprise-Bedeutung, die mit Shopify-Daten verbunden wird. Products, Varianten, Collections, Customers, Orders, Pages, Blog Posts, Redirects, Metafields, Metaobjects, Apps und organisationsweite Strukturen müssen durch B2B, Markets, Multi-Store-Governance, externe Integrationen und Betriebsverantwortung interpretiert werden.
Ein schlüssiges Shopify-Plus-Datenmodell unterscheidet gewöhnliche Shopify-Daten von Betriebsstrukturen auf Plus-Ebene. Es legt fest, was migriert, was in Shopify Plus konfiguriert, was von Apps oder Integrationen verwaltet, was direkt gemappt oder strukturell angepasst und was als App- oder Integrationsimplementierung behandelt werden muss. Diese Trennung verhindert, dass der Zielshop zu einer oberflächlichen Kopie der Quellplattform statt zu einer nutzbaren Enterprise-Shopify-Umgebung wird.
Häufige Fragen
Sind die Datenmodellunterschiede von Shopify Plus getrennt von denen von Shopify?
Sie hängen zusammen. Shopify Plus nutzt Shopifys Datengrundlage, doch Plus-Migrationen verbinden dieselben Datensätze meist mit zusätzlicher Enterprise-Bedeutung durch B2B, Markets, mehrere Stores, Custom Data, Integrationen, Berechtigungen und Prozess-Governance.
Sollten B2B-Customer-Groups der Quelle zu Shopify-Customer-Tags werden?
Nicht automatisch. Eine Source Customer Group kann Preise, Company-Struktur, Käuferzugriff, Steuerstatus, Segmentierung oder nur ein historisches Label darstellen. Die Zielbedeutung muss geprüft werden, bevor entschieden wird, ob sie in B2B-Companies, Catalogs, Customer Segments, Metafields, Apps oder eine bewusste Ziel-Datenentscheidung gehört.
Können Metafields jede Custom-Data-Anforderung in Shopify Plus lösen?
Nein. Metafields erweitern eine vorhandene Shopify-Ressource; Metaobjects modellieren wiederverwendbare strukturierte Datensätze. Keines von beiden rekonstruiert App-Prozesse, ERP-Beziehungen, ein B2B-Berechtigungsmodell oder ein externes System of Record. Verwenden Sie sie nur, wenn Owner und Verbraucher der Zieldaten definiert sind.
Wie sollten Multi-Store-Quelldaten für Shopify Plus interpretiert werden?
Multi-Store-Daten der Quelle müssen auf die beabsichtigte Ziel-Betriebsstruktur abgebildet werden. Sie können zu einem Shopify-Plus-Store mit Markets, mehreren Stores, Expansion Stores, lokalisiertem Content, B2B-Catalogs oder einer Kombination aus Ziel-Setup und Migrationsumfang werden.
Welche Shopify-Plus-Beziehungen benötigen die sorgfältigste Übersetzung?
B2B-Companies und Company Locations, Market- oder Store-Verantwortung, Catalog- und Preiskontext sowie Kennungen externer Systeme benötigen besonders klare Beziehungs-Mappings. Ein Datensatz kann in Shopify Plus existieren und trotzdem dem falschen Käufer, Standort, Storefront, Catalog oder System of Record zugeordnet sein.
Wie sollten B2B-Company- und Location-Beziehungen in Shopify Plus erhalten bleiben?
Behandeln Sie Company, Locations, zugewiesene Käufer, Catalogs, Zahlungsbedingungen, Steuerkontext und externe Account-IDs als verbundene Datensätze und nicht als Customer-Tags. Das Mapping muss jeden Käufer mit der richtigen Einkaufs-Location verbinden und Kennungen bewahren, die fortbestehende Backoffice-Systeme benötigen.