Choose a Next-Cart approach for Shopify by separating three decisions:
- Data scope: which source meanings fit supported Shopify records, eligible enhancements or agreed tailored handling?
- Execution: who performs the agreed Migration Actions?
- Evidence: what can standard samples prove, what needs paid proof, and what belongs to Target Store implementation?
Start with the future operating model. Product choices, collection paths, Customer and Order context, custom references, apps, Markets and URLs can affect scope more than record count. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
Define the Shopify Data Outcome
A variant, descriptive metafield, metaobject reference and app-owned record have different destinations and consumers. A variant can own stock; compatible options can connect to category or Product metafields using metaobject references. Copying the displayed label does not preserve the typed relationship or target definition.
Name the record, value type, reference and consumer before deciding on supported mapping, Shopify setup or tailored work. The Shopify data model guide provides the underlying context.
| Scope area | Approach question | Shopify planning implication |
|---|---|---|
| Products and variants | Can source product choices become clear Shopify products, options, and variants? | Clean product structures may fit Standard Service, while custom options, bundles, personalization, or subscription logic may need Add-ons, Shopify setup, apps, or Custom Service review. |
| Collections and navigation | Can source categories, filters, and browse paths become Shopify collections, menus, tags, metafields, content pages, or redirects? | Ordinary category-to-collection logic is usually easier than layered navigation, extension-driven merchandising, or complex legacy paths. |
| Customers and orders | Are records needed mainly for reference, or do they carry account, loyalty, wholesale, subscription, or external-system meaning? | Reference history is different from recreating source-side customer behavior or operational workflows. |
| CMS Pages, Blog Posts, and URLs | Which content and paths support trust, SEO, campaigns, support, policies, or buying decisions? | Migration scope should prioritize useful destinations, redirects, and content continuity rather than moving old pages without purpose. |
| Apps and custom data | Which values are native source records, and which belong to apps, extensions, custom fields, external systems, or custom logic? | Compatible values may be mapped or configured; unsupported behavior needs custom review or reconstruction outside ordinary migration. |
| Markets and localization | Does the store depend on countries, languages, currencies, domains, localized URLs, or regional catalog behavior? | Market-specific expectations should be scoped before choosing the service path because they can affect products, content, redirects, and validation. |
The most demanding required outcome sets the scope boundary. A small migration can need Custom Service for bespoke buying logic; a large compatible catalog can remain suitable for Standard Service when the customer can execute and review it confidently.
Use Add-ons for Supported Adjustments
Add-ons refine compatible migration behavior rather than supply an unsupported data model. Their processing sequence is Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping:
- Data Filter selects supported records using data-type-specific conditions.
- Data Transformation changes supported field values through expressions.
- Mapping routes a source or already transformed value to a compatible destination without changing it during mapping.
Combining supported Add-ons does not itself require Custom Service. Tax remains outside both mapping Add-ons.
| Shopify requirement | Add-on direction | Planning purpose |
|---|---|---|
| Move only records that meet defined conditions | Data Filter | Apply field-based conditions to supported Products, Customers, Orders, or content so only matching records migrate. |
| Transform supported field values | Data Transformation | Apply expressions to produce defined Shopify-compatible values during migration. |
| Change supported field destinations | Advanced Data Mapping | Remap supported standard source fields to different supported Shopify target fields while keeping the values unchanged. |
| Extend an Add-on beyond Standard scope | Custom Service review | Tailored or Custom Add-on work is reviewed and quoted through Custom Service when the fixed Standard capability cannot produce the accepted result. |
A supported Product condition or compatible field remapping can fit those controls. Interpreting subscription state, rebuilding a Product builder, unsupported extraction or bespoke relationships needs tailored review. Confirm the supported destination before deciding how to preserve an external identifier.
Advanced Database Mapping is unavailable with Shopify as Target. Source eligibility and Shopify API access do not override that boundary. A supported field destination or agreed tailored requirement may address the data need; metafield definitions, metaobjects and app behavior retain their own implementation responsibilities.
Custom Service: Tailored Requirements
Custom Service needs review when supported record migration, Add-ons and Shopify configuration cannot safely produce the required outcome. Group the source requirements by what needs interpretation:
- Catalog and buying logic: structures without an acceptable target representation; bundles, kits, build-your-own Products, personalization, options, subscriptions or Product relationships controlled by unsupported source logic.
- Discovery: collections, menus, filters and merchandising driven by source extensions, code, layered navigation or external systems.
- App and custom data: plugin, module or extension records; fields or metafield-like values beyond supported mapping scope.
- External references: identifiers needed by ERP, PIM, WMS, fulfillment, reporting, support or analytics when supported handling is insufficient.
- Customer treatment: groups, loyalty, wholesale, subscription state, accounts or customer-specific pricing requiring special handling.
- Order context: custom statuses, operational notes, external references, unsupported custom fields or source-specific rules.
- Regional and source architecture: bespoke catalog, content, URL, pricing, domain or market behavior; Custom Platform or heavily customized sources.
Tailored work may be narrow, such as a particular external Product ID, or broad, such as interpreting extension-owned subscriptions for Shopify. The accepted scope must distinguish data to migrate, app setup, manual rebuild and exclusion.
Custom Service can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Service; the included standard file workflow covers Products only. Agree other Data Types explicitly. A supported platform's File Upload connection method is a different case, and a Product export alone does not establish complete Shopify scope.
Standard Service: Customer-Led Execution
Standard Service can fit when the selected path supports the required data and representation, the Shopify design is clear, and the customer can perform available actions and verify the result. Useful indicators include:
- Supported records: the required Products, variants, collections, Customers, Orders, images, CMS Pages, Blog Posts, Reviews, Coupons and other selected Data Types fit the active path.
- Accepted representation: representative options and variants are understandable; Categories or equivalent structures have clear destinations; priority URLs have a destination or redirect plan.
- Ordinary history: Customer and Order data serves reference, service, reporting or support, without critical app-owned source meaning left unresolved.
- Review capacity: the customer can interpret the limited Demo before Full Migration and separately qualify enhanced or custom requirements.
- Clear boundaries: no Custom Platform source, unsupported app data or bespoke source logic controls the core result.
Standard Service is a supported-scope choice, not a low-capacity tier. It avoids unnecessary custom work when the representation fits. It does not recreate source applications, business logic, themes, checkout-adjacent workflows or external-system processes.
Managed Service: Expert-Led Execution
Managed Service uses the same supported capability as Standard Service and supplies expert execution of agreed Migration Actions. Large variant families or extensive Order history can increase execution work without making the scope custom.
It can fit when:
- internal time or operational pressure makes customer-led execution impractical;
- many catalog, Customer, Order, content, redirect or market-specific samples need coordinated execution and stakeholder review;
- an active source and launch schedule require agreed actions at defined times;
- the customer wants expert execution while reviewing standard Demo findings and accepting the final result.
The customer retains manual access, supplies business meaning and approves variant identity, collections, custom references, history and URLs. Expert execution does not restore unsupported app data or broaden capability.
Wider coordination, validation services, project management, app setup and launch work need explicit agreement. Tailored requirements belong to Custom Service, whose Self-Execute or Expert Handle choice is separate from the nature of that scope.
Match Evidence to Demo and Paid Scope
Demo Migration examines a limited representative sample available in the supported path. Add-ons and Customization are unavailable; Reviews and Coupons are excluded. It can expose a requirement without proving its enhanced or tailored output.
Use these contexts to distinguish standard sample evidence, paid proof and Target Store implementation:
| Demo Migration sample | What it should prove | Escalation signal |
|---|---|---|
| Variant-heavy Product | Available standard variant values and relationships remain understandable; live stock and purchase behavior need target acceptance | Source option logic cannot be represented without bespoke transformation or an app-dependent design |
| Category or collection sample | Available standard classification values have an accepted destination; menus, filters and storefront discovery need separate target proof | Layered navigation or rule-driven merchandising has no accepted target structure |
| Customer and exceptional Order | Historical account and transaction context remains useful | Loyalty, subscription, wholesale, tax, fulfillment, or external-system meaning is missing |
| App-owned or custom-data record | Available standard values expose a supported destination or gap; Add-on/custom output requires agreed paid proof | Business-critical app records are assumed to appear through ordinary migration |
| Market-specific content or URL | Available standard content and URL values reveal assumptions; Markets, domains and public redirects need separate acceptance | Regional content and URL behavior remain undefined |
| High-value content page or Blog Post | Content, metadata, links, and media remain usable | Theme or app markup makes the transferred content operationally weak |
Classify a gap as a supported-data issue, enhancement, tailored requirement or target setup responsibility. Expert execution does not expand Demo capability. Agreed Add-on and custom output needs paid proof; apps, live commerce, storefront behavior and public routes keep their implementation owners.
Separate Entity Points from Complexity
Entity Points size eligible Products, Customers, Orders and Blog Posts when each first migrates successfully within the same purchased migration and fixed Source-to-Target path. Counted capacity does not make variants, custom references, app state, collections or Markets separate independently counted Data Types.
| Planning input | Entity Points relevance | Shopify complexity that remains separate |
|---|---|---|
| Products | Eligible Product records can consume capacity when migrated for the first time | Variant design, bundles, subscriptions, personalization, and app-owned Product data |
| Customers | Eligible Customer records can consume capacity when migrated for the first time | Account activation, loyalty, wholesale, consent, and external identities |
| Orders | Eligible Order records can consume capacity when migrated for the first time | Refund, fulfillment, tax, subscription, payment, and integration usefulness |
| Blog Posts | Eligible Blog Posts can consume capacity when migrated for the first time | Theme rendering, internal links, media, localization, and URL continuity |
Already counted records do not consume points again merely because another action processes them on that same purchased path. Newly eligible records consume capacity on first successful migration. Selling identity, typed references, app ownership and historical usefulness still need their own scope decisions.
Plan Paid Actions and Source Windows Separately
The Source Store may remain active while the Shopify result is reviewed. Choose the paid action from whether the accepted rules remain valid, configuration must change or a distinct target result is required. Demo findings inform the first paid configuration; Demo alone is not an earlier paid result.
| Migration Action | When it fits Shopify | What must be revalidated |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid; choose the required source-data window separately. | New Products and variants, Customers, Orders, Blog Posts, changed content, URLs, and a regression sample from earlier migrated records. |
| Continue the Migration with a New Configuration | Review of the earlier paid result or revised target requirements shows that filtering, supported field mapping, content scope, collection handling, Customer handling, or URL rules must change. | Every Product family, field, collection destination, Customer or Order sample, content item, metafield-ready value, and URL affected by the change. |
| Perform a New Migration | Use for the first paid run or a distinct result on the same purchased path; define target effects without assuming a store reset or protected-data erasure. | The complete accepted data scope, protected target data, Products, Customers, Orders, content, URLs and app- or integration-sensitive outputs. |
The first paid run uses Perform a New Migration. Either continuation needs an earlier paid migration, and the purchased Source-to-Target path stays fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Revalidation follows the change:
- Saved configuration: selected records and a regression sample under accepted rules.
- New configuration: the changed rule and combined earlier/later output.
- Distinct result: broader acceptance of its defined target effect.
Choose the source-data window independently:
- “Migrate only newly added entities” selects records added after the last successful run, not edits to existing records.
- “Continue the previous migration” applies to the appropriate previous migration state.
Neither option is implied by an action name. When configuration changes, verify the combined earlier and later output without assuming that protected target data is erased.
Migration Actions update migration output; they do not complete Shopify implementation. The following retain Target Store or separately scoped owners:
- Storefront and identity: themes, customer-account configuration and Markets.
- Transactions: payments, shipping, taxes and discounts.
- Extensions and systems: apps, Shopify Functions and external integrations.
Compare Requirements Across Service Choices
One project can mix supported core records, Data Filter for approved Data Type conditions and tailored handling for a critical app dataset. Decide by requirement rather than forcing the entire Store into one category:
| Requirement | Standard Service | Managed Service | Add-ons | Custom Service |
|---|---|---|---|---|
| Ordinary Products, variants, Customers, Orders, and content | Suitable when supported and customer-led review is practical | Expert execution of agreed actions; the customer owns approval | Optional for bounded supported adjustments | Not normally required |
| Complex source categories and navigation | Suitable when an accepted Shopify structure is already defined | Expert execution of accepted data scope; content and SEO acceptance remains customer-owned | Can filter or map supported values | Needed when bespoke transformation or unsupported source logic controls discovery |
| Metafields and compatible custom values | Suitable when supported destinations are agreed | Expert execution of agreed actions; field owners verify meaning and references | Can support bounded mapping or configuration | Review for unsupported extraction, reference handling or bespoke transformation; target definitions and design need their own owner |
| Subscription, loyalty, reviews, bundles, or product-builder data | Suitable only for the supported native portion | Expert execution alone does not restore unsupported app-owned state | Add-ons are not a substitute for unsupported data handling | Appropriate when business-critical data requires tailored review |
| Markets and localized storefront assumptions | Suitable when target setup is designed separately and migrated data fits | Expert execution of agreed actions; regional owners approve results | Can support bounded content or field handling | Needed when source structures require non-standard splitting, merging, or transformation |
| ERP, PIM, WMS, OMS, CRM, or marketplace identifiers | Suitable when supported fields preserve reference value | Expert execution of agreed actions; integration teams own operational review | May map supported identifiers | Needed when required extraction, representation or relationships exceed supported handling; live reconnection remains separate |
The matrix is not a promise that every listed item is supported for every migration path. The Source Platform and Target Platform determine available capability. It is a decision framework for separating supported records, execution burden, bounded adjustments, and tailored migration requirements.
Confirm the Approach Before Full Migration
Use limited standard samples and the paid proof needed for enhanced or custom output to establish the following choices:
| Migration situation | Recommended path |
|---|---|
| Compatible source data, clear Shopify target store model, and customer confidence in self-performing migration steps | Standard Service with representative Demo Migration review. |
| Compatible source data, limited internal capacity, launch pressure, or need for included expert-led execution | Managed Service with defined review responsibility. |
| Compatible data requiring data-type-specific selection, expression-based value changes, or compatible target destinations for supported source fields | Standard Service or Managed Service with Data Filter, Data Transformation, or Advanced Data Mapping. |
| App-owned data, custom product logic, complex source categories, external identifiers, subscriptions, loyalty, wholesale records, Custom Platform source context, or bespoke transformation | Custom Service review before approving scope. |
| Active source platform with new records or updates expected before launch | Plan the suitable Migration Action and define the required revalidation scope. |
| Changed mapping, corrected Shopify configuration, revised scope, or intentionally refreshed earlier migrated results | Choose between Continue the Migration with Last Saved Configuration, Continue the Migration with a New Configuration, or Perform a New Migration for the same migration path. |
Approve the Shopify representation, supported data path, execution responsibility and acceptance evidence together. Keep capacity, source windows and Target Store implementation explicit; one service name cannot establish every part of launch.
Conclusion
A sound Shopify migration approach preserves the required business meaning, then assigns who executes the agreed work. Supported scope, eligible Add-ons and tailored requirements answer a different question from customer-led or expert-led execution.
Use the Shopify preparation checklist to assemble the inputs and Shopify validation priorities to define evidence. Keep Demo, paid proof, counted capacity and Target Store implementation distinct as the project moves toward launch.
Common Questions
Is Standard Service enough for a Shopify migration?
Standard Service can fit when the selected path supports the required records and representation and the customer can execute available actions and verify the result. A limited standard Demo can reveal variant, collection, history or content gaps.
Enhanced or custom output needs paid proof; apps, Markets and live storefront behavior need target acceptance.
When should a Shopify project use Managed Service?
Use Managed Service when experts should execute the agreed Migration Actions within supported Shopify capability. The customer retains manual access, supplies business meaning and verifies the final result.
Broader coordination, validation services, app setup and launch management require explicit agreement.
Are Add-ons the same as Custom Service?
No. Standard Add-ons perform supported filtering, expression-based transformation and compatible mapping. Mapping preserves the source or already transformed value, and combining supported Add-ons does not itself make the scope custom.
Shopify does not support Advanced Database Mapping as Target. Unsupported data, bespoke interpretation or migration logic needs tailored Custom Service review.
Should Migration Actions be planned before Shopify launch?
Yes, when the source remains active or supported configuration may change. The first paid run uses Perform a New Migration; either continuation requires an earlier paid migration.
Choose the source-data window separately, distinguish newly added records from existing edits and verify combined output without assuming protected target data is erased.
Does Custom Service automatically include complete migration execution?
Custom Service defines the agreed tailored migration requirement and can use Self-Execute or Expert Handle. Expert Handle includes expert execution of its agreed Migration Actions; Self-Execute leaves those actions with the customer.
Final verification remains customer-owned. Wider project management, validation services or Shopify implementation must be included explicitly.
Does copying a metafield label preserve a metaobject reference?
Not necessarily. A typed reference points to another defined record; a displayed label is only text. Identify the value type, referenced record, target definition and intended consumer.
Confirm supported handling, separately owned Shopify setup or agreed tailored work before treating the reference as preserved.
Does a Shopify B2B feature make its source data part of standard migration?
No. Shopify B2B availability depends on the actual plan and configuration and is not categorically limited to Plus. Native companies, catalogs or pricing features do not establish Next-Cart coverage.
Review the exact source structures and target representation, then assign supported migration, tailored handling and commercial setup separately.