A source Category can carry hierarchy, membership, navigation and access meaning at once. Shopify divides those jobs among collections, menus, filters, catalogs and other configured structures. A successful migration preserves the relationship that buyers or staff need, rather than copying each field into a similarly named destination.
Treat Shopify data-model mapping as a translation of business meaning. The important connections include Product to variant, collection to discovery path, Customer to Order, content to URL, and external identifier to its continuing system.
Translate Meaning, Not Just Fields
Shopify's hosted model defines distinct catalog, customer, Order, content and configuration structures. Source attributes, extensions, custom Product types, multi-store logic and theme data may therefore need different target owners.
The useful test is whether buyers can choose and discover the right Products, read important content, use the intended account and Order context, and reach the correct URLs. Required app-supported functions need an implementation as well as data.
| Source Platform meaning | Possible Shopify destination | Planning question |
|---|---|---|
| Sellable product difference | Product option, variant, SKU, price, inventory, media, or app-supported behavior | Is the difference a real buying choice or only descriptive information? |
| Category or department | Collection, menu, filter, product category, product type, tag, page, or redirect | Does the structure support customer discovery or only legacy organization? |
| Custom field | Native field, metafield, metaobject, app-owned field, integration reference, or deliberate exclusion | Who will use the value after launch and where should it appear or be processed? |
| Extension, module, or app data | Shopify app setup, metafields, integration planning, manual configuration, or separate application work | Is the data useful without the behavior that originally used it? |
| International or multi-store structure | Markets, domains, languages, currencies, catalogs, redirects, or separate store planning | Which regional differences must be visible and usable after launch? |
| SEO-sensitive URL | Shopify handle, route, redirect, collection path, page path, Blog Post path, or cleanup decision | Which source paths deserve priority redirect and destination review? |
Products, Options and Variants
A Product represents the item; options describe buying-choice dimensions such as size or color; variants represent their purchasable combinations. Source labels such as “option,” “attribute” and “specification” are not interchangeable in Shopify.
Configurable or grouped Products, bundles, kits, subscriptions, personalization and optional extras can combine several of these meanings.
Product differences should be classified by commercial function:
- real customer-facing buying choices;
- SKU, inventory, price, barcode, fulfillment, or tax differences;
- product specifications or compatibility details;
- variant-specific images or media order;
- personalization inputs or custom option behavior;
- bundle, kit, subscription, or add-on logic;
- operational identifiers used by ERP, marketplace, fulfillment, analytics, or reporting systems;
- obsolete fields or extension residue that should not clutter Shopify.
Select the destination from the value's commercial function:
- A variant-driving choice changes the sellable combination.
- A specification describes the Product or variant.
- A line-item property records a buyer's choice on the transaction.
- An app may own a configurator and its behavior.
Other source values may belong in content, metafields, metaobjects, tags, theme display or integration data.
Product identity, variant identity and SKU also remain distinct. A SKU is a business reference, not a substitute for the target identity used by media, stock, Order or custom-data relationships. Copying the same text into another field does not preserve its buying or historical meaning.
Native capacity and target design
Shopify supports up to three Product options and 2,048 variants per Product. Those native limits do not mean every source attribute belongs in an option, or that a source catalog can be copied unchanged.
Four buying dimensions, formula-based choices, extension-owned configurators or more than 2,048 combinations require a different design. Splitting Products, using an app or retaining non-variant attributes changes identity and stock relationships; the accepted design must account for them without silently dropping combinations.
Theme, app and sales-channel compatibility must be confirmed separately from native capacity. A custom field or line-item property does not automatically extend the native inventory-bearing variant model.
Classification and enrichment
Keep these organizational meanings distinct:
- Product category: Shopify's standard taxonomy, with implications for attributes, channels, tax, discovery and organization.
- Product type: a merchant-defined organizational field.
- Tags and metafields: additional organization, filtering or display where a target purpose exists.
None should become an indiscriminate home for every source attribute.
Product relationships and their consumers
Related, up-sell, cross-sell, accessory and recommendation links need references to the intended target Products and a defined merchandising consumer. Native features, metafields, a theme, an app or another merchandising system may supply that consumer.
Stored relationship data and a visible recommendation block are different outcomes. Native capability also does not prove that the selected migration path transfers the relationship.
Inventory by Location and State
Inventory adds both location and state to a variant:
- On hand includes available, committed and unavailable units.
- Incoming stock has not yet become available.
- A global total cannot preserve the intended quantity basis at each location.
- Stock held at a location does not by itself establish that location's fulfillment role.
Historical Order import must not be treated as an instruction to recreate reservations or current stock movements.
Collections, Navigation and Selling Context
Source Categories may combine hierarchy, landing pages, filters, campaigns, SEO, internal classification and browsing habits. Shopify collections preserve only the meanings assigned to them; menus, content and access rules may need separate owners.
Where the newer collection model is available, its sources can include:
- Products, including their variants;
- specific variants, for selected combinations;
- other collections, creating nested membership relationships;
- application sources, supplying app-owned membership.
Preserve source conditions, resulting membership and collection relationships separately. Existing stores may use earlier patterns, so the design must match the actual destination. A discovery collection is not automatically a B2B catalog or purchase-permission rule.
That platform capability is separate from the migration mechanism used to preserve a source Category hierarchy. In the migration flow documented for this platform, Source Product Categories can still be represented as Shopify collections while Migration Menu preserves the migrated source hierarchy through navigation. Treat Migration Menu as migration output behavior, not as evidence that Shopify collections themselves cannot express nested relationships.
A merchant can also design or revise multi-level Shopify navigation when a different storefront arrangement is preferred.
A source category may become:
| Source category role | Shopify treatment to consider |
|---|---|
| Customer-facing product group | Collection, menu item, filter group, or landing page |
| SEO landing page | Collection with content, page, redirect destination, or cleanup decision |
| Internal classification | Product type, tag, metafield, or no migrated customer-facing structure |
| Filter or layered-navigation context | Search and discovery configuration, tags, metafields, product category attributes, or app-supported filtering |
| Campaign or seasonal grouping | Collection, rule-based grouping, page, menu placement, or archived redirect |
| Deep legacy taxonomy | Collection relationships where suitable, navigation structure, and redirects for priority paths |
A fixed membership list, a condition-driven source and a nested collection relationship express different rules. Menus point to discovery destinations; they do not own Product membership. Preserved Category names or member counts alone cannot establish those distinctions.
The selected theme and apps still control collection layout, cards, menu depth, filters, badges and custom displays. Moving collection data does not recreate the complete browsing experience.
Markets can vary selling conditions within a store. A separate store has its own records and native identities. That distinction determines which relationships remain local and which need cross-store ownership.
Customers, Accounts and Order History
A Customer record can preserve useful history while account behavior, passwords, loyalty, group logic, support processes or B2B experiences differ from the source. Separate the meanings that need continuity:
- profile details and contact information;
- billing and shipping addresses;
- customer tags, notes, and segmentation signals;
- marketing status and communication expectations;
- order-history association;
- loyalty, rewards, memberships, wholesale status, or account-tier information;
- customer-specific identifiers used by external systems;
- password, login, or activation expectations.
Profile identity and account access
With current Shopify customer accounts enabled, an existing Customer profile can support passwordless sign-in through its associated email address. Migrating that profile does not, by itself, reproduce source credentials, membership permissions or the same account experience.
Legacy password accounts and configured identity providers have separate authentication owners. Password-verification continuity depends on the exact supported Source-to-Target path and applicable account model. Where unavailable, the chosen model needs appropriate invitation, activation, reset or first-login handling.
B2B Company and purchasing-location relationships are also distinct from Customer tags. Their required behavior depends on plan and configuration; B2B availability is not universally Plus-only.
Historical Orders and continuing behavior
Useful Order history connects several kinds of context:
- Transaction detail: line items, totals, tax, shipping and discounts.
- Identity and service: Customer association, notes, source references and customer-service context.
- Historical state: payment and fulfillment meaning.
Payment systems, fulfillment tools, invoices, subscriptions, loyalty, fraud tools and other external systems may own behavior beyond those records. The target history should support service, operational reference, reporting and buyer confidence where visible, without implying that source workflows have been recreated.
Payment and fulfillment are separate dimensions
Payment state describes financial settlement; fulfillment state describes what happened to physical or digital delivery. A broad source status may combine settlement, delivery, cancellation and refund meaning, so copying its label cannot establish each Shopify state.
A payment reference or “refunded” label preserves evidence of the source transaction. It does not authorize a new gateway action or recreate fulfillment.
Historical tax and future calculation
Tax amounts, tax lines and tax-inclusive prices describe the original transaction and its tax basis. Current Product taxability and the Target Store's future tax configuration serve a different purpose.
Preserving history does not configure tax on new Orders. The same amount under a different tax basis can produce a different checkout result.
Content, URLs and SEO
Content may support trust, policy compliance, shipping, returns, sizing, campaigns, buying advice, education and brand credibility. Pages and Blog Posts need their media, internal links and metadata considered alongside handles, menus and redirects. Product and collection descriptions also need to fit the target selling experience.
Use the content's purpose to decide its destination:
| Content or URL area | Shopify data-model implication |
|---|---|
| CMS Pages | May require page migration, navigation placement, internal-link review, media review, and metadata decisions. |
| Blog Posts | May require blog structure, article paths, media, metadata, author/date expectations, and internal-link review. |
| Product and collection descriptions | Should support target-store selling logic and theme display, not only preserve old text. |
| Source category URLs | May need collection destinations, page destinations, redirects, or cleanup decisions. |
| Product URLs | Need handle review and redirect planning for priority paths. |
| Filtered, search, or query-string URLs | Need special review because they may not behave like ordinary product, collection, page, or Blog Post paths. |
| International or localized URLs | Need market, language, domain, subfolder, and redirect planning where regional selling matters. |
Shopify URL structure is controlled by its storefront model. Exact source paths may not be preserved, especially for products, collections, CMS Pages, Blog Posts, filtered routes, and custom paths. That makes redirect planning part of data-model translation, not only a final SEO task.
Priority paths need an explicit Shopify destination and redirect relationship. Identify them through:
- Audience and acquisition: organic traffic, paid campaigns, backlinks and customer bookmarks.
- Commercial use: high-revenue Products and important Categories.
- Content and regional needs: policies, Blog Posts and regional landing pages.
Preserving text without its route and discovery relationships can leave important content unusable.
Custom Data, Apps and External Systems
Source extension data is useful only when a continuing theme, app, workflow or integration can consume it. Common dependencies include:
- product reviews and ratings;
- subscriptions, bundles, kits, optional product extras, or personalization logic;
- loyalty, rewards, memberships, and customer tiers;
- advanced search, filtering, recommendations, or merchandising rules;
- wholesale, B2B-style behavior, customer-specific pricing, or gated content;
- ERP, fulfillment, marketplace, PIM, CRM, analytics, accounting, or support identifiers;
- delivery rules, shipping logic, tax assumptions, invoices, and payment-related context;
- custom storefront displays controlled by theme code or app blocks.
For each dependency, name the business outcome, source data, Shopify destination and required target behavior. The appropriate treatment may be app import, manual or Target Store configuration, explicit relationship mapping, integration work or restructuring. Retire data that has no continuing purpose.
Keep structured custom-data roles distinct:
- Metafields extend a particular resource with defined typed data.
- Metaobjects provide reusable entries containing several fields.
- Typed references connect an owning Product, variant, Customer or Order to the intended target record.
Definitions, value types, access and a theme or application consumer give those values meaning. A source ID stored as text creates neither the target relationship nor the source-side logic.
External identifiers must resolve the intended store, resource and continuing system. A correctly copied value is insufficient if that system expects a different identity or lookup relationship.
Build the Data Translation Map
Migration scope should identify which source meanings must remain useful and who owns them in Shopify. Separate these four outcomes before treating field availability as completeness:
| Mapping outcome | Shopify meaning |
|---|---|
| Native Shopify record | The source meaning fits a supported Product, variant, Customer, Order, collection-related record, CMS Page, Blog Post, redirect, or another native destination. |
| Shopify configuration or storefront ownership | The record can exist, but its usefulness depends on collections, menus, Search & Discovery settings, theme sections, Markets, customer accounts, or another Target Store configuration. |
| Structured custom-data ownership | The source meaning belongs in a defined metafield, category metafield, metaobject, app-owned field, or integration reference with a known consumer. |
| Exclude, archive, or redesign | The source value is obsolete, duplicated, dependent on retired extension logic, or has no continuing storefront or operational purpose. |
Matching records or counts can conceal missing relationships:
- A variant count can match while option values represent the wrong buying dimensions.
- A collection can exist while its discovery path is lost or menus point to obsolete URLs.
- A metafield can hold the right value while no theme, app or integration consumes it.
- A Customer can exist while Order associations or the source login experience differ.
- An Order can preserve history without recreating live payments, fulfillment or subscriptions.
These are differences in target meaning, rather than simply missing fields.
For every important source meaning, the translation map should name the destination, required relationship, continuing system or team, and necessary Target Store setup. The matrix below connects those decisions to business use:
| Source meaning | Shopify representation question | Required target meaning |
|---|---|---|
| Sellable Product family | Which data belongs to the Product, its variants, media, inventory items, and locations? | Each sellable combination has the correct SKU, price, option values, image, and inventory relationship. |
| Browsing hierarchy | Which source Categories become collections, menus, filters, pages, redirects, or internal organization only? | Priority discovery paths lead buyers to the intended Product set without duplicate or orphaned destinations. |
| Structured enrichment | Should the value become a native field, metafield, metaobject reference, tag, taxonomy value, or external-system attribute? | The value is visible or consumable by the theme, application, workflow, or integration that needs it. |
| Customer identity | Which values belong to the Customer profile, addresses, tags, notes, marketing state, B2B context, or historical Order only? | Staff can identify the buyer and interpret history without inventing unsupported account behavior. |
| Historical transaction | Which Order, payment, fulfillment, refund, discount, tax, and external-reference details remain useful? | Customer-service and reconciliation work can understand the transaction without treating history as live configuration. |
| Content and URL equity | Which pages, Blog Posts, handles, media, metadata, menus, and redirects need a Shopify destination? | Priority URLs resolve intentionally and important content remains discoverable. |
| App or integration state | Which system owns the data after launch, and what cross-system identifier connects it? | The continuing owner can find and use the migrated record without duplicate sources of truth. |
Conclusion
Shopify data-model differences become manageable when each important source meaning has an appropriate target record, relationship and continuing owner. Deliberate redesign can preserve usability better than reproducing an obsolete source structure.
Use that translation map as the foundation for the Shopify preparation checklist. Record transfer, storefront configuration, app behavior and external-system ownership then remain distinct parts of the intended outcome.
Common Questions
Are Shopify collections the same as source categories?
No. Collections can use Product, variant, collection, or application sources where the newer model is available.
Source Categories may also own navigation, filters, landing pages, or access meaning. Preserve source conditions and membership separately from menu links.
Migration Menu can retain migrated hierarchy through navigation without implying that native Shopify collections are universally flat.
Should every custom source field become a Shopify metafield?
No. Metafields are useful when the field has a clear target purpose. Obsolete fields, duplicate fields, extension residue, or values with no storefront, operational, integration, or reporting purpose can make the Target Store harder to maintain.
Do Shopify apps migrate automatically from the Source Platform?
No. Apps, extensions, modules, and theme behavior are not ordinary migrated records. The migration plan should identify which source behaviors need Shopify app configuration, Target Store setup, direct field mapping, integration work, or target-side data restructuring.
Can Shopify preserve the same customer account experience as the Source Platform?
Profile and Order-history continuity do not establish the same account experience.
Current Shopify accounts are passwordless by default; legacy password accounts and configured providers have different owners.
Password continuity depends on the exact supported Source-to-Target path and applicable account model. Other paths need invitation, activation, reset, or first-login handling rather than inferred access from the Customer record.
How should Shopify metafields and metaobjects be divided?
Use a metafield for typed data owned by a specific resource; use a metaobject for a reusable structured entry. A typed reference connects that resource to the correct target entry.
Definition, access, and a theme, application, or integration consumer must also be appropriate. A source identifier stored as text does not create a target relationship.
How should external system identifiers be preserved in Shopify?
Keep an external identifier only when an active ERP, PIM, CRM, fulfillment, marketplace, or reporting process still depends on it. Store it on the Shopify resource or integration record that the continuing system expects; uniqueness, format, and lookup behavior must remain consistent with that continuing system. An unused identifier should not become permanent storefront metadata.
How should source variants, options, and attributes be translated to Shopify?
Separate sellable variant choices, descriptive attributes, transaction-specific properties, and application-owned behavior.
Native Shopify Products support up to three options and 2,048 variants. A source design beyond those boundaries needs a representation that preserves identity and buying meaning; an application or theme field does not automatically become another native inventory-bearing variant.
How should Shopify payment and fulfillment statuses be treated during migration?
Payment and fulfillment are separate historical dimensions, with cancellation and refund meaning also interpreted from the source transaction.
A broad source label should not be used as proof of every target state. Preserving the state or reference does not recreate a gateway refund, shipment, reservation, or other live action.
Does migrating historical tax information configure future Shopify tax behavior?
No. Historical tax lines and amounts belong to transaction snapshots; current Product taxability and future calculation belong to Target Store configuration. Preserve the original amount and tax basis where supported without treating past Orders as the rules for new checkout.
How should related Products be represented on Shopify?
Related Products require target references and a defined merchandising consumer, which may be native functionality, a theme, metadata, or an application. The selected migration path must support the required relationship. Preserving its data does not automatically produce a storefront recommendation block.
Does one Shopify inventory total preserve stock meaning across locations?
No. Inventory belongs to a variant, location, and state. Available, committed, unavailable, and incoming quantities have different meanings, and on-hand quantity is not the same as stock available to sell. Preserve the intended quantity basis and location relationship without assuming that historical Order import recreates reservations or fulfillment routing.