Shopify Plus identifies the intended Shopify environment, not an exact current Next-Cart Target selection. First resolve the actual supported Shopify selection and path, or agree a Custom Platform workflow where needed. Then use company, catalog, store and integration ownership to define the required migration scope and who performs its agreed actions.
Selecting the right Shopify Plus migration approach means matching service responsibility to enterprise operating complexity. Shopify Plus belongs to the Shopify family, but the migration decision changes when the target environment includes organization-level management, expansion stores, B2B companies, Markets, localized content, custom apps, automation, and integrations with systems such as ERP, PIM, OMS, WMS, CRM, tax, shipping, loyalty, or subscription platforms.
Choose a proportionate service arrangement after the actual path and data outcome are defined. Standard Migration is customer-led supported execution; Managed Migration provides expert execution of agreed Migration Actions within that capability. Eligible Add-ons refine supported operations, while tailored requirements use Custom Migration with Self-Execute or Expert Handle. The Plus plan alone establishes none of these migration entitlements.
For Shopify Plus, decide scope before execution: identify the supported records, eligible enhancements or tailored requirements, then choose who performs the agreed Migration Actions. The customer supplies business meaning, retains manual access and verifies the final result even when execution is expert-led.
Start With Enterprise Scope, Not Record Count
Record count is only one planning signal. A Shopify Plus migration with fewer records can still be complex if those records represent B2B companies, regional catalogs, product restrictions, multi-store content, ERP-controlled pricing, localized URLs, or custom data. A larger migration can remain straightforward when the source data fits supported Shopify structures and review ownership is clear.
Distinguish a company, its locations and buyers, a catalog’s assignment and the resulting commercial behavior. Shopify B2B is available across several plans with plan and configuration differences; direct company or company-location catalog assignment is a current Plus distinction. Confirm the actual contract and store configuration rather than treating all B2B as Plus-exclusive. Native availability still does not prove Next-Cart coverage or implement pricing and account rules.
Begin by classifying the enterprise scope:
| Scope area | Approach question | Service-path implication |
|---|---|---|
| Organization and stores | Is the migration going into one store, multiple expansion stores, or separate B2B/D2C stores? | Multi-store scope often increases sequencing and validation needs even when records are supported. |
| B2B | Do companies, buyers, catalogs, price lists, payment terms, or restricted products need to be represented? | B2B structures can require careful mapping, Shopify setup, integrations, or Custom Migration review. |
| Markets and localization | Are countries, currencies, domains, languages, and localized content part of launch? | International scope increases URL, content, pricing, and validation complexity. |
| Product governance | Are products controlled by PIM, ERP, merchandising rules, bundles, subscriptions, or custom fields whose required handling exceeds supported mapping scope? | Supported data may fit Add-ons; app-owned or bespoke logic may require Custom Migration. |
| Order and fulfillment context | Are historical orders needed for finance, support, B2B account management, or external-system reconciliation? | Readability and external references may affect scope. |
| Apps and integrations | Which systems own business-critical data or workflows? | External-system ownership often determines whether standard migration is enough. |
The migration approach should follow the hardest business-critical scope area. Shopify Plus planning fails when the easiest data type controls the service decision while B2B, localization, or integration complexity is left for later.
Treat expansion stores as actual store identities, not merely catalog partitions. Agree each store’s Source-to-Target path, records and acceptance owner. A plan’s multi-store capability does not turn a purchased migration into automatic execution across different stores; a different Source or Target path requires its own purchased Migration Service.
When Standard Migration May Be Enough
Standard Migration may be suitable when the project resolves to a supported migration path, the selected data types are supported, the Shopify Plus target structure is already clear, and the customer can perform available migration actions and review results without intensive coordination.
Standard Migration is usually realistic when:
- the migration is focused on supported products, variants, collections, customers, orders, CMS Pages, Blog Posts, images, reviews, coupons, or other supported data types;
- the target uses one store or a clearly scoped set of stores;
- B2B structures are not central to the migration result or are being configured separately in Shopify Plus;
- Markets, domains, localized content, and redirects are straightforward or handled outside migration scope;
- app-owned data and custom fields are not business-critical migration requirements;
- customer and order history is mainly needed for reference;
- the customer can review Demo Migration and Full Migration results confidently;
- no unsupported source structures or bespoke transformations control the launch outcome.
Standard Migration can still be used in a Shopify Plus environment when the project uses a supported Target selection and migration path. The Plus plan alone does not require a custom approach. The deciding factor is whether the required result stays within supported behavior and whether the customer can own execution and validation responsibility.
When Managed Migration Is Safer
Managed Migration fits a resolved supported path when experts should execute the agreed Migration Actions. A Shopify Plus environment may have many customer stakeholders across merchandising, B2B, finance, SEO and integrations. Those owners still define business meaning and approve the final result; multiple teams do not automatically add project management or validation services.
Managed Migration is especially useful when:
| Managed Migration signal | Shopify Plus context |
|---|---|
| Multi-store launch | Agree separate actual store paths and actions; customer owners verify each result. |
| Complex catalog review | Experts execute agreed supported actions; customer owners approve catalog and reference meaning. |
| B2B/D2C mix | Customer owners define company and catalog context; execution covers only agreed supported data. |
| International rollout | Agree supported action scope; regional owners separately accept Markets, domains and public routes. |
| Limited internal bandwidth | The customer needs included expert-led execution while internal teams validate results. |
| High launch sensitivity | Agree who performs each action and who verifies final output; wider launch coordination needs explicit scope. |
Managed Migration does not convert unsupported data into supported data. If the need involves app-owned records, custom fields that cannot be handled through supported mapping, external identifiers, bespoke transformation, or unsupported source structures, Custom Migration should be reviewed even when Managed Migration is also useful for execution support.
Where Add-ons Fit in Shopify Plus Migration
Add-ons fit when the requirement is supported, specific, and bounded. They should not be used as a general label for enterprise customization. Within a supported migration path for a Shopify Plus project, the relevant controls can include record filtering with field-based conditions for each data type, expression-based field-value transformation, and source-field remapping.
For an actual Shopify Target selection, Advanced Database Mapping is not available. Shopify Plus has no independent exact selector or database-mapping entitlement. If an agreed Custom Platform route is required, assess its exact Source setup, Target role and eligible compatible schema separately; neither plan name nor API access establishes availability.
| Add-on type | Shopify Plus example | Boundary check |
|---|---|---|
| Data Filter | Apply supported Product, CMS Page, Order, or Blog Post field conditions so only matching records migrate. | Filtering should not remove records needed for B2B support, SEO, finance, or compliance review. |
| Data Transformation | Apply expressions to transform supported field values into defined Shopify Plus-compatible results. | Expressions cannot recreate unsupported app behavior or external-system logic. |
| Advanced Data Mapping | Remap supported standard source fields to different supported Shopify target fields while keeping the values unchanged. | Mapping cannot create unsupported target structures or application behavior. |
| Tailored or Custom Add-on need | A Standard Add-on function needs project-specific modification, or bespoke Add-on functionality is required. | This work is reviewed and quoted through Custom Migration rather than treated as Standard Add-on scope. |
The clearest test is whether the requirement can be described as a supported adjustment. If yes, an Add-on may fit. If the requirement depends on unsupported data, custom application behavior, external-system identity, or a unique transformation rule, Custom Migration is the safer framing.
When several Standard Add-ons are selected, processing follows Data Filter, Data Transformation, Advanced Data Mapping, then Advanced Database Mapping. Filtering selects records; transformation changes supported values; mapping routes the source value, or an already transformed value, without changing it during mapping. Combining supported Add-ons does not by itself require Custom Migration. Tax is excluded from both mapping Add-ons.
When Custom Migration Becomes Necessary
Custom Migration should be considered when the Shopify Plus migration depends on requirements outside supported standard behavior. The trigger is not simply enterprise size. The trigger is a business-critical expectation that needs custom evaluation, bespoke handling, unsupported data interpretation, custom migration logic adjustment, Custom Platform handling, or external-system alignment.
Common Shopify Plus Custom Migration triggers include:
- B2B companies, locations, catalogs, pricing, or payment terms that come from custom source structures;
- ERP, PIM, OMS, WMS, CRM, loyalty, subscription, or marketplace identifiers that must remain usable after migration;
- app-owned records that are not part of ordinary source exports;
- custom fields whose required destination or transformation exceeds supported mapping and Data Transformation scope, such as values that must be reorganized into app-owned structures or external systems;
- multi-store source data that must be split, merged, or reorganized in a non-standard way;
- localized content, URL structures, or regional catalogs that require bespoke interpretation;
- custom product logic such as bundles, kits, subscriptions, personalization, build-your-own products, or quoting workflows;
- Custom Platform source data with no supported structure;
- migration output that must align with external integration rules.
Custom Migration should be scoped through examples, not vague enterprise labels. The customer should provide representative products, companies, customers, orders, URLs, custom fields whose required handling exceeds supported mapping scope, integration identifiers, and target expectations. Without examples, Custom Migration discussions can sound precise while the real requirement remains undefined.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Selecting CSV, XLS or XML as the Source Platform requires Custom Migration; the standard included file workflow covers Products only. Other required data types must be agreed explicitly. This differs from a supported platform’s File Upload connection method, and a Product export alone does not establish the complete Shopify Plus scope.
What Demo Migration Should Decide
Demo Migration can examine a limited representative sample available in the active supported path and reveal gaps in the proposed Shopify Plus approach. Add-ons and Customization are unavailable in Demo, and Reviews and Coupons are excluded. Use the contexts below to identify standard sample checks and requirements needing separate proof. Validate enhanced or tailored output through the agreed paid scope, and assign storefront, extension and live-operation checks to target implementation.
| Demo Migration sample | Decision it should support |
|---|---|
| Variant-heavy product | Whether product options, variants, SKUs, images, and inventory remain usable. |
| B2B company or customer sample | Whether available standard Customer values reveal company or catalog gaps; enhanced/custom output and B2B behavior require paid or target-side proof. |
| Market-specific product or content | Whether localization, URL, visibility, and pricing assumptions are understood. |
| High-value redirect | Whether available standard URL values have intended destinations; live redirects require separate acceptance. |
| Custom-data sample | Whether available standard values expose a supported destination or gap; reference or app-owned output needs agreed paid proof where enhanced or custom. |
| Integration-owned record | Whether a required external reference has a supported destination or tailored requirement; live reconnection remains separately owned. |
| Exception order | Whether refunds, discounts, fulfillment, payment context, tax, and external references remain readable. |
| Expansion-store sample | Whether actual store identity, supported assignment and acceptance owner are clear; separate stores need separately agreed paths and proof. |
Use limited standard Demo findings to correct supported scope or identify an enhancement, tailored requirement or setup gap. Hold unresolved business-critical company, catalog or store meaning before Full Migration. Paid scope must prove enhanced/custom output, and Shopify implementation and integrations must establish their own live behavior.
Entity Points and Shopify Plus Planning
Entity Points size eligible Products, Customers, Orders and Blog Posts on their first successful migration, once within the same purchased migration and fixed Source-to-Target path. Company structures, catalog assignments, Markets and store governance still affect scope without becoming additional independently counted Data Types. Different actual store paths must be assessed separately.
For Shopify Plus, this means Entity Points should be interpreted alongside the operating model. A modest number of B2B companies or custom product records can require more planning than a large set of simple products. A large order history may be manageable when it is needed only for reference, but more complex when finance, support, ERP identifiers, and B2B account context rely on historical records.
| Planning signal | What it helps estimate | What it does not decide |
|---|---|---|
| Product count | Migration volume and possible Entity Points usage. | Variant meaning, B2B visibility, market availability, or app logic. |
| Customer count | Buyer-record volume. | Company structure, buyer roles, permissions, or external IDs. |
| Order count | Historical volume. | Payment, fulfillment, finance, and integration usefulness. |
| Blog Posts count | Content volume. | Localization, URL strategy, internal links, or SEO value. |
Entity Points should support planning, not replace service-path evaluation.
Migration Actions and Launch Timing
Shopify Plus launch windows often require follow-up migration activity because Products, Customers, Orders, Blog Posts, B2B records, Markets content, and integration references may continue changing while several teams validate the target organization. These actions apply after a paid migration has produced an earlier result. The selected action should reflect whether its recorded configuration remains valid, supported rules need revision, or the target result needs a fresh basis. Demo findings inform the first paid configuration; they do not create a paid configuration to reuse.
| Migration Action | When it fits Shopify Plus | What must be revalidated |
|---|---|---|
| Continue the Migration with Last Saved Configuration | An earlier paid configuration remains valid on the actual purchased path; select the source-data window independently. | New Products and variants, Customers, Orders, Blog Posts, URLs, market-sensitive content, and a regression sample from earlier migrated records. |
| Continue the Migration with a New Configuration | Review of the earlier paid result or revised enterprise requirements shows that filtering, supported mapping, store scope, content scope, B2B field handling, or localization rules must change. | Every affected Product family, company or Customer sample, market-specific value, URL, Order, content type, metafield-ready value, and integration identifier influenced by the new configuration. |
| Perform a New Migration | Use for the first paid run or a distinct result on the same purchased path; define target effects and separately scope any store, B2B or Markets redesign. | The accepted data scope, protected target data, Customer and agreed B2B context, Products, Orders, content, URLs and integration-sensitive outputs. |
Previously counted eligible records do not consume points again within the same purchased migration and fixed path. Newly eligible counted records consume points on first successful migration. This rule does not combine distinct store purchases or establish coverage for company, catalog, market or B2B structures.
Standard Migration and Custom Migration with Self-Execute leave agreed Migration Actions with the customer. Managed Migration and Custom Migration with Expert Handle provide expert execution of agreed actions. The customer retains manual access and final verification. B2B setup, catalog rules, Markets, themes, Functions, apps, integrations and wider project or launch management remain separately owned unless expressly agreed.
The first paid run uses Perform a New Migration. Either continuation action requires an earlier paid migration; Demo alone does not establish a paid configuration. These actions keep the purchased Source-to-Target path fixed. A different Source Platform or Target Platform requires a separate purchased Migration Service.
Choose the source-data window separately from the action. “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, check the combined earlier and later output; a new action does not automatically erase protected target data.
Shopify Plus Enterprise Decision Matrix
Shopify Plus service selection should be made against enterprise responsibilities, not the plan name alone. Shopify Plus can support B2B through companies, locations, catalogs, pricing, payment and shipping customization, and it can tailor market experiences by currency, language, product availability, domains, taxes, and theme content. Those capabilities increase the number of target decisions, but they do not automatically make every record custom.
| Enterprise concern | Lighter path is realistic when | Escalation signal |
|---|---|---|
| B2B companies and buyers | Source data is ordinary, the target company model is designed, and setup is handled separately | Company hierarchies, buyer roles, catalogs, payment terms, or external IDs need non-standard migration handling |
| Markets and localization | Product, content, currency, language, domain, and URL expectations are documented and supported | Regional structures need bespoke splitting, merging, or transformation |
| Several stores or business units | Each store has clear ownership, scope, and review responsibility | Source data must be reorganized across stores through non-standard logic |
| Apps and Shopify Functions | App behavior is rebuilt separately and migrated records have supported destinations | App-owned data or workflow state must be interpreted and preserved |
| ERP, PIM, OMS, WMS, or CRM continuity | Supported identifiers can be preserved and integration teams own reconnection | Identifiers or relationships require custom transformation to remain operational |
| Enterprise validation | Catalog, B2B, Markets, finance, support, SEO, and integration owners can approve samples | No team owns acceptance, or critical output requires enhanced/custom paid proof or target checks beyond standard Demo |
Choose expert execution for supported agreed actions through Managed Migration. Review unsupported meaning or tailored transformation through Custom Migration and its Self-Execute or Expert Handle choice. Company, catalog and store governance need customer acceptance owners in either arrangement; approval and sequencing work beyond agreed actions must be scoped explicitly.
Signals That the Approach Is Too Light
A Shopify Plus approach is too light when it treats enterprise governance as ordinary Shopify record transfer. The warning signs usually appear in review responsibility, target structure, and unsupported expectations.
| Warning signal | Likely response |
|---|---|
| Multi-store data ownership is unclear. | Clarify actual store paths, acceptance owners and agreed expert-executed actions. |
| B2B companies, buyers, catalogs, or pricing cannot be explained through examples. | Prepare B2B evidence and review Custom Migration if needed. |
| Markets, localized URLs, currencies, or languages are treated as post-launch details. | Add market planning and validation before Full Migration. |
| App-owned or external-system fields are business-critical. | Confirm supported field destinations first; review unsupported extraction, app-owned state or bespoke relationships through Custom Migration. |
| Demo Migration samples are approved by only one team. | Assign review owners for merchandising, B2B, localization, operations, finance, and integrations. |
| Entity Points are used as the main complexity measure. | Reframe scope around operating meaning and validation burden. |
| Later migration activity has no revalidation plan. | Define action type, affected records, and post-action review. |
These signals should be resolved before Full Migration. Waiting until launch makes it harder to separate migration issues, Shopify Plus setup gaps, integration timing, and unsupported expectations.
Conclusion
Choose the approach after resolving the actual supported Target selection and purchased path. Company relationships, catalog assignment, store identity and external ownership define the required data meaning. Standard Migration is customer-led; Managed Migration supplies expert execution of agreed supported actions. Add-ons and tailored Custom Migration address distinct data requirements rather than the Plus label alone.
Define each actual store’s scope, execution and final verification. Use standard Demo to reveal supported gaps and paid scope to prove enhanced/custom output; separately accept B2B commercial rules, Markets and integrations. Capacity and later Migration Actions stay tied to the purchased path, with source-data windows chosen independently.
Common Questions
Is Shopify Plus always a Custom Migration migration?
No. Shopify Plus does not automatically require Custom Migration. After the project resolves to a supported Target selection and migration path, Standard Migration or Managed Migration can be appropriate when the data is supported, the target structure is clear, and validation responsibility is realistic.
When is Managed Migration safer for Shopify Plus?
Managed Migration fits the resolved supported path when experts should perform the agreed Migration Actions. Customer owners still define and verify company, catalog, store, history and integration meaning. Broader review, project management or launch coordination requires explicit agreement; expert execution does not extend data coverage.
How are Add-ons different from Custom Migration for Shopify Plus?
Supported Add-ons perform bounded filtering, expression-based transformation and compatible mapping. Eligibility follows the actual selected path, not the Plus plan; Shopify as Target does not support Advanced Database Mapping. Tailored requirements use Custom Migration with Self-Execute or Expert Handle. Target apps, commercial rules and implementation remain separately owned.
Why should Migration Actions be planned before launch?
Active source stores can add records or change requirements during review. The first paid run uses Perform a New Migration; either continuation needs an earlier paid migration on the same path. Select the source window separately, distinguish newly added records from existing edits and verify combined output without assuming protected target data is erased.
How should the Custom Migration starting price be interpreted?
The Custom Migration starting price is the Standard Migration price for the selected Entity Points Plan. The final total depends on the agreed customization, purchased Add-ons where applicable, Expert Handle when included, and other agreed scope-specific costs.
Is Shopify Plus a separate Next-Cart Target selection?
No exact Shopify Plus Target selection is present in the current model. Resolve the actual supported Shopify selection and purchased path, or agree a Custom Platform workflow where required. Evaluate coverage and Add-on eligibility from that actual route; the Plus plan does not create an independent migration entitlement.
Does one migration automatically cover every expansion store?
No. Identify each actual Source and Target Store and agree its records, actions and acceptance owner. Different store paths require separately purchased Migration Services. Shopify Plus multi-store capability does not automatically combine migration scope, Entity Points accounting or execution across those stores.