Selection among Next-Cart Migration Services is often reduced to a simple ladder: Standard for a small project, Managed for a larger one, and Custom for the most complex. That shortcut is unreliable. Store size describes volume, not the structure of the requirement. Price reflects capacity and included work, not an automatic quality tier.
The three Next-Cart Migration Services become clearer when the decision is separated into two axes. The first is scope: does the expected result fit supported migration behavior, or does it require tailored handling? The second is execution: will the customer perform the agreed migration actions, or should expert-led execution be included?
Standard, Managed, and Custom Migration occupy different positions across those two axes. Understanding that relationship prevents unsupported requirements from being placed into Managed Migration and prevents predictable migrations from being escalated to Custom Migration merely because the Store is large.
Some migration paths resolve the Service before this comparison begins. Selecting CSV, XLS, or XML as the Source Platform requires Custom Migration, so Standard Migration and Managed Migration are not available for that path. A migration to a Target Platform outside the supported Target Platform list is also handled through Custom Migration. Entity Points still determine capacity, while technical scoping determines the final Custom Migration scope and quote.
Start With Scope, Then Assign Execution
Supported scope means the migration path, data structures, available configuration, and Standard Add-ons can produce the intended result without project-specific migration logic. Tailored scope means some part of the requirement needs individual analysis, modification, transformation, or handling beyond that supported behavior.
Execution responsibility answers a different question. A supported migration can be customer-led or expert-led. A custom migration can use Self-Execute or Expert Handle. The person or team performing the actions does not change whether the data requirement itself is supported.
This framework produces four practical positions:
| Scope and execution position | Migration Service | Central reason |
|---|---|---|
| Supported scope with customer-led execution | Standard Migration | Available migration behavior is sufficient, and the customer can coordinate the actions |
| Supported scope with expert-led execution | Managed Migration | Available migration behavior is sufficient, but execution responsibility should be included |
| Tailored scope with customer execution | Custom Migration with Self-Execute | Non-standard work is required, while the customer can perform the agreed actions |
| Tailored scope with expert-led execution | Custom Migration with Expert Handle | Both tailored work and expert-led execution are required |
The table is not a qualification form. It is a way to avoid mixing two decisions that should be reasoned about separately.
Standard Migration: Supported Scope With Customer Ownership
Standard Migration fits when the migration path is supported, the important source structures are predictable, and available configuration or Standard Add-ons can produce the required result. The customer prepares the required access, reviews the configuration, performs the migration actions, coordinates findings, and validates the Target Store.
This does not make Standard Migration a basic or low-capacity option. A Store with a large number of Products and Orders can still fit when the data model is well understood and the internal team has the capacity to manage execution. Entity Points determine how much counted data the plan can support; they do not determine whether Standard Migration is appropriate.
A strong Standard Migration case normally has:
- a supported Source Platform-to-Target Platform path;
- clear ownership of important data and relationships;
- no requirement for bespoke migration logic;
- bounded Add-on needs that fit available behavior;
- internal capacity to coordinate execution and validation;
- acceptance criteria that can be applied to representative results.
The main trade-off is ownership. Customer-led execution provides direct control over timing and configuration decisions, but it also requires enough attention to interpret evidence and respond when assumptions are wrong.
Managed Migration: Supported Scope With Expert-Led Execution
Managed Migration applies when the migration remains within supported scope but expert-led execution of the agreed migration actions is required. The service distinction concerns responsibility, not a broader data capability.
This can be valuable when the internal team is constrained by a fixed timeline, competing operational work, limited migration experience, or the need for coordinated execution across several stakeholders. The data itself may be predictable; the project still benefits from shifting the execution burden.
Managed Migration does not absorb unsupported application data, custom tables, bespoke transformations, or modified Add-on logic. If those requirements exist, the scope must first be treated as custom. Assigning expert execution to a non-standard requirement does not convert it into supported behavior.
The customer remains responsible for supplying accurate project information and validating the outcome. Expert-led execution can reduce operational effort, but it cannot decide whether migrated records preserve the business meaning that merchandising, finance, customer service, SEO, or compliance teams require.
Managed Migration does not remove customer access to the migration. The customer can still review, configure, and perform available migration activity manually. Expert-led execution is an included responsibility position, not exclusive control of the purchased migration.
Custom Migration: Tailored Scope Defined by the Required Result
Custom Migration becomes relevant when the expected migration outcome cannot be produced through supported behavior and available Standard Add-ons alone. The need should be defined through the data or behavior that requires tailored handling, not through a vague statement that the Store is unusual.
Common signals include:
- a Custom Platform as Source Platform or Target Platform;
- custom fields, tables, or database structures whose required handling exceeds supported migration or Standard Add-on scope;
- data owned by applications, plugins, modules, or extensions;
- third-party records outside the supported platform model;
- external identifiers that must preserve another system relationship;
- bespoke transformation or restructuring;
- non-standard Product, Customer, Order, content, or relationship logic;
- an available Add-on that must be modified;
- a new project-specific Add-on.
The custom scope should identify the source meaning, intended target representation, transformation or relationship rules, affected records, and evidence required for acceptance. Without those elements, "custom" remains a label rather than an actionable migration requirement.
Custom Migration also differs in how the final commercial scope is established. The Entity Points Plan supplies the capacity floor, but the non-standard requirements need to be assessed and itemized before the final custom price can be established. A strong itemization makes the relationship between the requirement, expected result, and quoted work clear enough to support later acceptance.
Expert Handle Changes Execution, Not the Nature of Custom Work
Custom Migration does not automatically include Expert Handle. Execution responsibility is a separate decision.
Custom Migration with Self-Execute
Self-Execute keeps execution of the agreed migration actions with the customer after the approved tailored work is ready. This can fit teams that need bespoke capability but retain the operational capacity to coordinate execution and validation.
Custom Migration with Expert Handle
The agreed tailored work and expert-led execution of the accepted migration actions are included. The customer still supplies the required business context and performs final verification.
The accepted scope should state execution responsibility explicitly. Otherwise, the project may correctly define the custom output while leaving an avoidable gap over who performs the actions needed to produce it.
The same access principle applies to Custom Migration. Whether the project is customer-led or includes Expert Handle, the customer can still access and perform available migration activity manually. When expert-led execution is included, Next-Cart technical specialists can perform the agreed migration actions on request within the active service and accepted scope. The service choice defines included responsibility and tailored scope, not a lockout from the migration.
Keep Target Implementation Separate From Migration Execution
Migration execution and Target Store implementation are different responsibilities. Installing the Target Store, installing Target Store extensions, and pointing the production domain to the Target Store are not automatic entitlements of Standard, Managed, or Custom Migration.
Those implementation or launch tasks become part of the purchased work only when they are explicitly included in an accepted Custom Migration scope, quote, or other order-specific agreement. Expert-led execution under Managed Migration or Custom Migration with Expert Handle concerns the agreed migration actions; it should not be read as an automatic promise to build or launch every part of the Target Store.
Support Runs Alongside the Migration Service
Support is included throughout the Migration validity period, including a renewed period, under the applicable Service Level Agreement. That support relationship is separate from execution responsibility. Standard Migration does not become Managed Migration because support is available, and support does not expand a supported requirement into custom scope.
AI Help provides automated guidance, while human assistance is available through the supported ticket, email, and Support Agent channels under defined service windows and response and resolution commitments. The exact service hours, escalation path, and support procedure belong in Documentation and the Service Level Agreement rather than in the service-selection model.
This distinction matters when comparing services. Support helps investigate supported migration questions and issues. Managed Migration and Custom Migration with Expert Handle additionally include expert-led execution responsibility for the agreed migration actions.
Add-ons Do Not Form a Fourth Migration Service
Standard Add-ons address bounded supported needs. They can accompany Standard, Managed, or Custom Migration when the available behavior fits the requirement.
For example, selecting Orders that meet an approved Order-field condition may fit Data Filter. Transforming a supported value through an approved expression may fit Data Transformation. Routing a supported source or transformed value to a compatible target field may fit Advanced Data Mapping. Database-level routing may fit Advanced Database Mapping only when the selected Source setup and Target Platform both support the Add-on and the requested database locations are compatible. Several Standard Add-ons can be combined without making the migration Custom Migration when each operation remains within its supported boundary.
The boundary changes when the Add-on itself needs modification or when no Standard Add-on can produce the required result:
- a modified Standard Add-on becomes a Tailored Add-on under Custom Migration;
- a project-specific Add-on is reviewed as a Custom Add-on under Custom Migration;
- unsupported data or bespoke relationships require broader Custom Migration analysis even if filtering or mapping is also involved.
An Add-on describes a focused capability. The Migration Service describes the wider scope and responsibility arrangement.
Customer Validation Is a Separate Responsibility
Every Migration Service ends with customer validation. This is sometimes misunderstood as a limitation of expert-led execution. It is better understood as a division of knowledge.
Execution can be assessed against the accepted configuration and service scope. Business acceptance requires knowledge that sits with the customer: which Products must remain sellable, how Orders must support service operations, which Customer distinctions matter, whether SEO paths are acceptable, and whether the Target Store is ready for the intended next step.
A useful acceptance record identifies:
- the critical outcome being reviewed;
- representative records or scenarios;
- the reviewer responsible for the decision;
- the expected result;
- any accepted limitation;
- the Pass, Watch, or Block decision.
Target Platform implementation should also remain visible as a separate layer. Theme reconstruction, application installation, payment or shipping setup, integration deployment, and operational configuration are not automatically included merely because migrated data must later participate in them.
Use Evidence to Upgrade the Initial Service
The initial Migration Service may need to change when new evidence alters a central assumption. Demo Migration may reveal unsupported structures. A data inventory may uncover external identifiers or custom tables. A Standard Add-on may prove too limited. Internal capacity may fall below what customer-led execution requires.
After purchase, service changes move only upward:
| Purchased service | Permitted later service |
|---|---|
| Standard Migration | Managed Migration or Custom Migration |
| Managed Migration | Custom Migration |
| Custom Migration | No service downgrade |
A service upgrade is appropriate when the evidence changes. Move from Standard to Managed when supported scope remains suitable but execution responsibility must change. Move from Standard or Managed to Custom Migration when tailored work is required. Within Custom Migration, Expert Handle can be included when the tailored scope is correct but expert-led execution also needs to be part of the accepted work.
The migration cannot move from Managed to Standard or from Custom to Managed or Standard. This asymmetry makes the initial decision important, even though an upward correction remains possible. A bounded Standard Add-on that fully solves the requirement does not by itself require a service upgrade.
The service upgrade becomes part of the same purchased migration and is charged through difference-only pricing. It does not create a new path or change the expiration of the active access period. This evidence-based approach is more reliable than treating the three services as reversible tiers of increasing size or quality.
Conclusion
Next-Cart Migration Services are distinguished by scope and execution responsibility. Standard Migration is customer-led within supported scope. Managed Migration includes expert-led execution within supported scope. Custom Migration addresses tailored or non-standard requirements and can use Self-Execute or include Expert Handle.
Entity Points should be used for capacity, Add-ons for bounded supported enhancements, and customer validation for business acceptance. Once those decisions are separated, service selection becomes a reasoned project choice rather than a shortcut based on Store size, displayed price, or perceived service level.
Common Questions
Is Standard Migration only suitable for small Stores?
No. Standard Migration can support a large migration when the path and requirements remain supported and the customer can coordinate execution and validation.
What is the main difference between Standard and Managed Migration?
Both address supported migration requirements. Standard Migration is customer-led, while Managed Migration includes expert-led execution of the agreed migration actions.
Does Managed Migration cover custom fields or unsupported records?
Not automatically. Managed Migration changes execution responsibility within supported scope. Tailored handling for custom or unsupported requirements belongs in Custom Migration.
Does Custom Migration always include Expert Handle?
No. Self-Execute keeps the agreed migration execution with the customer. Expert Handle is included when expert-led execution is part of the accepted custom scope.
Can a Standard Add-on be used with Managed Migration?
Yes. Standard Add-ons can accompany Standard, Managed, or Custom Migration when their available behavior fits the requirement.
Who approves the final migration result?
The customer remains responsible for final verification under every Migration Service because business acceptance depends on the intended commercial, operational, SEO, and compliance outcomes.
Can customers still perform migration activity under Managed or Custom Migration?
Yes. Every Migration Service remains accessible for manual customer activity. Managed Migration and Expert Handle define included execution responsibility; they do not remove customer access.
Can a purchased Migration Service be downgraded?
No. Standard can be upgraded to Managed or Custom, and Managed can be upgraded to Custom. A purchased Migration Service cannot move downward.
Is technical support the same as Managed Migration?
No. Managed Migration changes execution responsibility for agreed migration actions within supported scope. Technical support addresses migration-service questions and issues through the supported channels; it does not transfer migration execution responsibility or expand the accepted scope. A new bespoke requirement or expanded non-standard scope is a separate scoping question and may require Custom Migration rather than being treated as ordinary support.
How can a customer get support during a migration?
Use AI Help for automated guidance and access to human assistance when needed. Use a Support Ticket when an issue requires project-specific investigation, evidence, attachments, or a persistent case record. A Support Agent can handle human follow-up during the applicable support window. These support channels do not change the selected Migration Service, transfer execution responsibility, or expand the accepted migration scope.
Which Migration Services include expert-led execution?
Managed Migration includes expert-led execution for agreed migration activity that remains within supported scope. Custom Migration can also include expert-led execution when Expert Handle is part of the accepted tailored scope. Standard Migration and Custom Migration with Self-Execute keep the agreed migration actions customer-led. Technical support is a separate support function and should not be used as a substitute for selecting the Migration Service that matches scope and execution responsibility.