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 Service occupy different positions across those two axes. Understanding that relationship prevents unsupported requirements from being placed into Managed Service and prevents predictable migrations from being escalated to Custom Service merely because the Store is large.
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 also be customer-led or include 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 Service | Available migration behavior is sufficient, and the customer can coordinate the actions |
| Supported scope with expert-led execution | Managed Service | Available migration behavior is sufficient, but execution responsibility should be included |
| Tailored scope with customer-led execution | Custom Service | Non-standard work is required, while the customer can perform the agreed actions |
| Tailored scope with expert-led execution | Custom Service 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 Service: Supported Scope With Customer Ownership
Standard Service 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 Service 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 Service is appropriate.
A strong Standard Service 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 Service: Supported Scope With Expert-Led Execution
Managed Service 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 Service 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 Service 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 Service: Tailored Scope Defined by the Required Result
Custom Service 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.
Expert Handle Changes Execution, Not the Nature of Custom Work
Custom Service does not automatically include Expert Handle.
Customer-led Custom Service
The agreed tailored work is included, while the customer performs the available migration actions and validates the result. This can fit teams that need bespoke capability but retain the operational capacity to coordinate execution.
Custom Service 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 Service. Whether the project is customer-led or includes Expert Handle, the customer can still access and perform available migration activity manually. The service choice defines included responsibility and tailored scope, not a lockout from the migration.
Add-ons Do Not Form a Fourth Migration Service
Standard Add-ons address bounded supported needs. They can accompany Standard, Managed, or Custom Service when the available behavior fits the requirement.
For example, selecting Orders that meet an approved Order-field condition may fit Data Filter. Remapping a supported source field to a compatible target field may fit Advanced Data Mapping. When both the Source Platform and Target Platform are open-source, supported field or database-column mapping may fit Advanced Database Mapping. Transforming a selected target field value may fit Data Transformation. Several Standard Add-ons can be combined without making the migration Custom Service 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 Service;
- a project-specific Add-on is reviewed as a Custom Add-on under Custom Service;
- unsupported data or bespoke relationships require broader Custom Service 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 Service | Managed Service or Custom Service |
| Managed Service | Custom Service |
| Custom Service | 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 Service when tailored work is required. Within Custom Service, 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 extend the one-year service duration. 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 Service is customer-led within supported scope. Managed Service includes expert-led execution within supported scope. Custom Service addresses tailored or non-standard requirements and may remain customer-led 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 Service only suitable for small Stores?
No. Standard Service 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 Service?
Both address supported migration requirements. Standard Service is customer-led, while Managed Service includes expert-led execution of the agreed migration actions.
Does Managed Service cover custom fields or unsupported records?
Not automatically. Managed Service changes execution responsibility within supported scope. Tailored handling for custom or unsupported requirements belongs in Custom Service.
Does Custom Service always include Expert Handle?
No. Custom Service may be customer-led. Expert Handle is included when expert-led execution is part of the accepted custom scope.
Can a Standard Add-on be used with Managed Service?
Yes. Standard Add-ons can accompany Standard, Managed, or Custom Service 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 Service?
Yes. Every Migration Service remains accessible for manual customer activity. Managed Service 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.