A business buyer can be one Customer contact purchasing for several Company Locations, with a different catalog or payment context at each location. That relationship cannot be preserved by copying a wholesale tag. For a prospective Shopify Plus destination, the central data-model decision is which Shopify record owns enterprise identity and which configured relationship gives it commercial meaning.
Shopify Plus data modeling uses the Shopify foundation with enterprise context around Companies, purchasing locations, catalogs, Markets, multiple stores, permissions, and external-system ownership. Products, variants, collections, Customers, Orders, pages, Blog Posts, redirects, metafields, and applications remain central. B2B Company structures also exist on other Shopify plans; Plus distinctions depend on the enabled feature, such as direct catalog assignment to Companies and Company Locations. Enterprise meaning must therefore be attributed to the actual relationship, not to an assumed separate Plus database.
That distinction matters because enterprise Source Platforms often store commerce logic in structures that do not translate cleanly into ordinary Shopify records. A Magento or Adobe Commerce source may use customer groups, websites, stores, store views, product attributes, price rules, shared catalogs, B2B accounts, and extension-owned data. A Custom Platform may use proprietary tables, ERP identifiers, custom checkout rules, role-based buyer permissions, or regional catalogs. Shopify Plus can support many enterprise outcomes, but migration planning must decide whether each source structure should become Shopify data, Shopify Plus setup, app configuration, direct field mapping, target-side data design, integration work, or a redesigned workflow.
Shopify Plus Uses Shopify Data With Enterprise Governance
Shopify Plus is not a separate data platform detached from Shopify. The core data still follows Shopify concepts: products contain variants, collections group products, customers and orders hold buyer and transaction history, pages and Blog Posts support content, redirects help traffic continuity, and metafields or metaobjects extend structured information. Migration planning should therefore preserve the Shopify model rather than inventing a custom enterprise model inside Shopify Plus.
The enterprise layer changes how that model is governed. A Product may serve several Markets, B2B catalogs, storefronts, and ERP references. A Customer contact may purchase for one or more Company Locations, each with its own commercial context. A store using Markets remains a different structure from several stores in an organization: organization access and governance do not make their native Product, Customer, or Order identities interchangeable.
| Data area | Core Shopify meaning | Shopify Plus migration meaning |
|---|---|---|
| Products and variants | Sellable catalog structure. | Enterprise SKU logic, B2B availability, market-specific merchandising, ERP references, and product data governance. |
| Collections | Product grouping for browsing and merchandising. | Regional, brand, channel, B2B, and campaign segmentation decisions. |
| Customers | Buyer profiles and order history. | D2C buyers, B2B contacts, company relationships, buyer roles, and account ownership. |
| Orders | Historical transaction context. | Support, reconciliation, B2B order review, payment terms, fulfillment evidence, and integration reference value. |
| Metafields and metaobjects | Structured custom data extensions. | Product enrichment, content models, integration identifiers, B2B attributes, and enterprise operational context. |
| Stores and organization | Admin and storefront environments. | Multiple stores, governance, permissions, security, billing, and operating ownership. |
The migration should not flatten these differences into simple record transfer. It should define the target meaning of every enterprise-critical source structure.
Products, Variants, and Enterprise Catalog Meaning
Shopify products and variants remain the first catalog review layer. Source products with sizes, colors, units, bundles, kits, configurable options, subscription choices, or ERP-driven SKUs need to be interpreted against Shopify’s product and variant structure. Shopify Plus does not remove the need to make those decisions; it raises the stakes because catalog data may support more brands, markets, B2B catalogs, storefronts, and external systems.
A simple D2C catalog may migrate into products and variants with little additional interpretation. An enterprise catalog often requires deeper classification. Source attributes may be descriptive content, searchable specifications, variant-defining options, filter inputs, ERP identifiers, B2B eligibility markers, market-specific values, or app-owned logic. Treating all attributes as ordinary descriptions can weaken merchandising, search, and integrations.
| Source catalog pattern | Shopify Plus planning question |
|---|---|
| Configurable product with many source attributes | Which attributes define Shopify variants, which become metafields, and which should remain external? |
| Source customer-group product visibility | Should visibility be handled through B2B catalogs, store separation, an application rule, or a separate data design? |
| Regional product names or descriptions | Should the target use Markets/localization, separate stores, translation workflows, or content rebuild? |
| ERP SKU or product ID | Should the identifier be preserved as SKU, metafield, app data, or integration reference? |
| Bundle, kit, subscription, or configurable package | Should it use Shopify or application setup, target-side redesign, or manual configuration? |
| Enterprise product enrichment | Should structured data become metafields, metaobjects, app data, or theme/content setup? |
Product migration is strongest when each source field has a clear target purpose. The goal is not to force every enterprise source field into Shopify’s native product form. The goal is to preserve the information that must remain usable in the Shopify Plus operating model.
Native identity and external identity also need different owners. A Product or variant ID resolves a record inside its target store, while an ERP SKU or PIM reference resolves the item in the continuing external system. The same business reference used across stores does not establish one shared native record. Catalog availability and contextual pricing describe where and under which conditions the item is sold; they do not replace variant identity or its inventory relationships.
Collections, Navigation, and Storefront Segmentation
Collections are not the same as every source platform’s categories. Some Source Platforms use categories as database hierarchy, storefront navigation, merchandising pages, SEO landing pages, reporting groups, or access-control structures. Shopify collections can support product grouping and storefront merchandising, but the migration plan should decide whether each source grouping should become a Shopify collection, navigation item, page, redirect target, market-specific experience, B2B catalog rule, or excluded historical structure.
Shopify Plus adds segmentation questions. One store can use Markets and localized content, while separate stores carry separate commerce identities and governance. Collections can use Product, variant, collection, or application sources where the newer model is available; their definitions and membership still differ from navigation. A B2B catalog determines purchasing availability and pricing in its configured context, so public collection membership is not a substitute for Company or location catalog eligibility.
| Source grouping meaning | Better Shopify Plus interpretation |
|---|---|
| Public customer browsing path | Shopify collection, navigation, and storefront review. |
| SEO landing page | Collection, page, redirect, metadata, or content rebuild decision. |
| Regional storefront grouping | Markets/localization or expansion-store planning. |
| B2B-only access grouping | B2B catalog, application rule, or separate storefront design. |
| Internal reporting group | Metafield, tag, app data, or exclusion from public storefront. |
| Legacy Category no longer used | Deliberate exclusion, archive treatment, or redirect destination. |
The key difference is meaning. The same source category can have several functions. Shopify Plus planning should preserve the functions that matter after launch, not just the category names.
B2B Companies Are Not Ordinary Customers
B2B illustrates the distinction between a contact and a purchasing account. A Company is the parent organization; Company Locations carry purchasing context such as addresses, tax information, catalogs, payment terms, and contacts. A Customer can act as a contact for more than one Company Location, with permission at each relevant location. A purchasing location is not automatically an inventory or fulfillment location. These Company structures are shared Shopify concepts; direct Company and location catalog assignment is a plan-qualified Plus capability.
A Source Platform may represent B2B in many ways: customer groups, company accounts, quote workflows, account hierarchies, contract catalogs, shared catalogs, tax-exempt buyers, sales representative relationships, ERP account IDs, approval permissions, or custom fields. These should not be migrated blindly as ordinary customer tags or notes unless that outcome is the intended target meaning.
| Source B2B structure | Shopify Plus destination question |
|---|---|
| Customer group | Is it a segment, a company attribute, pricing context, catalog rule, or historical label? |
| Company account | Should it become a Shopify B2B Company with Company Locations, or use another defined account structure? |
| Buyer role or permission | Which Customer contact belongs to which Company Location, and what purchasing role should remain? |
| Contract pricing | Is the pricing owned by B2B catalogs, application pricing, or an external pricing system? |
| ERP account identifier | Should it use the Company ID, Company Location ID, a metafield, or an integration-owned reference? |
| Quote or approval workflow | Is it Shopify-side setup, app workflow, or unsupported source behavior? |
This separation prevents a major migration error: counting customer records as migrated while losing the commercial architecture that made those customers usable for B2B selling.
Customer profile, Company membership, purchasing permission, and authentication are separate relationships. Current Customer accounts are passwordless by default; a configured identity provider has its own authority and credentials. Applicable password continuity depends on the exact supported Source-to-Target path and account model. Migrating contact details, a Company tag, or historical Orders does not establish sign-in, approval, or permission to purchase for a Company Location.
Markets, Localization, and Multi-Store Structures
Shopify Plus merchants often move from platforms with websites, store views, locales, regions, brands, domains, or market-specific catalogs. These source structures must be interpreted carefully because Shopify Plus can support international selling through Markets and can also support multiple stores or expansion stores. The right target model depends on governance, content ownership, operational teams, product availability, currency, tax, shipping, and regional brand strategy.
A source store view may not equal a Shopify market. A regional domain may not require a separate Shopify Plus store. A language version may belong to translation/localization setup rather than a separate migrated content tree. A source website may represent a brand, geography, channel, or old implementation choice that should not be copied mechanically.
| Source structure | Possible Shopify Plus interpretation |
|---|---|
| Store view or language view | Localization and translation setup, or separate storefront if governance requires it. |
| Country-specific domain | Market, domain strategy, redirect plan, or expansion-store decision. |
| Regional catalog | Product availability rules, Markets setup, B2B catalog, app logic, or separate store. |
| Multi-brand source site | Expansion store, separate store, collections, or brand-specific content architecture. |
| Localized CMS Pages | Pages, Blog Posts, translations, metaobjects, redirects, or manual content rebuild. |
| Regional pricing | Markets pricing, B2B catalog pricing, app configuration, or external system logic. |
The data model question is therefore not only where records go. It is which target operating structure the migrated records should support.
Metafields, Metaobjects, and Custom Data Governance
Metafields attach typed values to defined Shopify resources; metaobjects provide reusable structured entries. A reference between them must resolve the correct target record. An ERP account code stored on a Company is therefore different from a Company Location reference or a Customer’s purchasing assignment. Definitions, access settings, and a theme, application, or integration consumer determine how the custom data is used; storing it does not recreate the source workflow.
For Shopify Plus, custom data planning should be more disciplined because enterprise source platforms often have large volumes of attributes, specifications, custom fields, ERP IDs, market flags, B2B labels, merchandising content, and app-owned records. Some fields are useful for customer-facing content. Some are needed for integrations. Some are historical. Some are obsolete. Some require field definitions, data rules, or theme setup. Some should not migrate at all.
| Custom data type | Possible handling path |
|---|---|
| Product specifications | Product metafields, category metafields, metaobjects, or app data. |
| Rich reusable content blocks | Metaobjects, pages, Blog Posts, theme sections, or manual content rebuild. |
| ERP/CRM/PIM identifiers | Metafields, app-owned fields, a native external ID, or an integration reference. |
| B2B account context | Company and Company Location setup, Customer metafields, or application-owned data. |
| Source extension data | Application migration, integration mapping, archive, or redesign when no native destination exists. |
| Historical reporting fields | Exclusion, archive, metafield, or external reporting decision. |
The best Shopify Plus data model is not the one with the most migrated custom fields. It is the one where every custom field has a defined target owner, display behavior, data-quality rule, and business purpose.
Orders, Payments, Fulfillment, and Workflow Context
Order migration into Shopify Plus should preserve historical meaning, not imply that every source workflow is recreated. Source orders may include payment labels, shipping methods, discounts, tax context, fulfillment states, partial shipments, refunds, quotes, invoices, purchase order references, ERP IDs, or sales representative data. Some of that context may be readable as historical order information. Some may belong to Shopify setup, application configuration, external integrations, or a redesigned target workflow.
This distinction becomes more important for Plus merchants because historical orders may support customer service, B2B account review, wholesale reordering, financial reconciliation, ERP matching, and fulfillment analysis. However, migrated order history does not configure live Shopify checkout, payment processors, tax logic, fulfillment routing, purchase order workflows, or B2B payment terms.
| Source order context | Shopify Plus migration interpretation |
|---|---|
| Payment reference | Historical context, not live payment setup. |
| Fulfillment method | Historical readability plus target fulfillment setup review. |
| Refund or cancellation | Historical support and reconciliation context. |
| Purchase order number | B2B Order context, metafield or application data, or an external-system reference. |
| ERP order ID | A native external ID, metafield, application field, or integration reference. |
| Quote or approval history | Historical note, app workflow, B2B setup, or unsupported custom behavior. |
A reliable Shopify Plus migration should make order history useful without confusing history with live operational configuration.
Apps, Integrations, and External-System Data
Shopify Plus merchants often depend on ERP, PIM, OMS, CRM, subscription, loyalty, reviews, tax, shipping, fraud, analytics, marketplace, personalization, and automation systems. Some source values are native commerce data; others belong to those systems and appear in the Source Platform only because an extension or integration copied them there.
The translation decision should identify the continuing system of record. A PIM may remain authoritative for enrichment. An ERP may continue to own account, SKU, inventory, or Order identifiers. A subscription platform may own contracts and billing schedules. A loyalty application may own balances and tier history. Storing copies in Shopify Plus does not transfer ownership or recreate the workflow.
| Dependency | Data-model question |
|---|---|
| ERP | Which Product, Customer, Company, Company Location, Order, and inventory identifiers must remain stable? |
| PIM | Which attributes become Shopify fields, metafields, or metaobjects, and which remain PIM-owned? |
| OMS or fulfillment system | Which Order and fulfillment values are historical context, and which remain operational in the connected system? |
| CRM | Which Customer fields belong in Shopify Plus and which remain relationship data in the CRM? |
| Subscription application | Which records and identifiers must be transferred through the application rather than represented as ordinary Orders? |
| Loyalty or review application | Which balances, memberships, reviews, and cross-system keys have a supported destination? |
A business-critical value should not be moved merely because a field is available. It should have a named owner, a stable identifier, a defined Shopify Plus representation when needed, and a continuing consumer. When those conditions are absent, the better decision may be to archive the value, redesign the workflow, or keep it in the external system rather than creating another unmanaged copy.
Conclusion
Shopify Plus data model differences are not only about Shopify fields. They are about enterprise meaning attached to Shopify data. Products, variants, collections, customers, orders, pages, Blog Posts, redirects, metafields, metaobjects, apps, and organization-level structures must be interpreted through B2B, Markets, multi-store governance, external integrations, and operating ownership.
A coherent Shopify Plus data model keeps shared Shopify identity separate from plan-qualified features and configured enterprise relationships. Company contacts, purchasing locations, catalog eligibility, Markets, store boundaries, and external-system keys each retain a defined owner. Historical evidence remains distinct from live checkout or integration authority. That gives migrated records continuing enterprise meaning instead of relying on tags or copied field values to imply the missing relationships.
Common Questions
Are Shopify Plus data model differences separate from Shopify data model differences?
They share the same core model. Plus projects often carry more enterprise context, but Companies, contacts, collections, and Markets are not a separate Plus database. Feature availability depends on plan and configuration; direct Company or Company Location catalog assignment is one Plus distinction. Preserve the actual relationship rather than assume every B2B concept is exclusive to Plus.
Should source B2B customer groups become Shopify customer tags?
Not automatically. A source group may mean marketing segmentation, a purchasing account, catalog eligibility, pricing, permission, or historical classification. A Customer tag cannot stand in for Company identity, location-specific commercial context, or the contact’s purchasing assignment. The target owner must match the source group’s continuing purpose.
Can metafields solve every Shopify Plus custom-data requirement?
No. A metafield extends a defined resource; a metaobject is a reusable structured entry. Neither creates Company membership, permissions, an ERP relationship, or executable application logic. Types, target references, access, and consumers must match the intended meaning.
How should multi-store source data be interpreted for Shopify Plus?
Map shared records, localized values, commercial context, and governance separately. One store with Markets differs from several stores in an organization; organization membership does not make native record identities interchangeable. The same ERP key can span stores while resolving to a different Product or buyer record in each.
Which Shopify Plus relationships require the most careful translation?
Company contacts and purchasing locations, catalog eligibility and pricing context, Market or store ownership, and external-system identifiers need the clearest relationships. A purchasing location is not automatically a stock location. Each target record must retain the context that makes it usable rather than merely exist with the right label.
How should B2B company and location relationships be preserved in Shopify Plus?
Keep the Company, its purchasing locations, assigned Customer contacts, location permissions, catalogs, terms, tax context, and external account keys distinct and connected. Shared Company structures are available beyond Plus, while direct catalog assignment depends on the plan. A buyer profile or copied wholesale tag does not establish location permission, authentication, or live commercial behavior.