The wrong Next-Cart Migration Service is rarely chosen because the service names are unclear. It is usually chosen because the decision is made too early. Store size, price, timeline pressure, or a general desire for help takes the place of evidence about the data, target representation, execution workload, and acceptance standard.
A defensible choice follows a different sequence. First establish what the migration must preserve. Then determine whether the requirement fits supported behavior, whether a bounded Add-on is enough, and who can responsibly coordinate execution. Price becomes useful only after those questions have produced a credible service direction.
This order matters because the three Next-Cart Migration Services solve different problems. Standard Service supports customer-led execution within supported scope. Managed Service includes expert-led execution within supported scope. Custom Service addresses tailored requirements and may be customer-led or include Expert Handle.
Define the Outcome Before Comparing Services
Service fit begins with the business result, not the service label. The project should identify which outcomes must remain true after migration, such as:
- Products remain understandable and buyable;
- Customer identity and segmentation remain useful;
- Order history supports service and reporting needs;
- content and URLs preserve their intended value;
- critical relationships remain connected;
- external identifiers continue to support dependent systems;
- the Target Store can be validated against agreed evidence.
These outcomes reveal what must be examined in the source data. A supported migration path may still contain custom tables, application-owned records, or target limitations that change the required representation. Without an outcome definition, those differences can be discovered only after the service choice has already set expectations.
The decision should also separate migrated data from Target Platform implementation. A requirement to transfer an identifier is a migration question. A requirement to deploy and operate the integration that consumes it is implementation work unless expressly included. Mixing the two can make every project look custom or create an incomplete custom scope.
Keep Capacity Outside the Service-Fit Decision
Entity Points answer how much counted Product, Customer, Order, and Blog Posts capacity is required. They do not measure:
- structural complexity;
- custom logic;
- third-party dependencies;
- internal execution capacity;
- target implementation effort;
- validation burden.
A Store with 200,000 predictable records may fit Standard Service when the team can lead execution. A Store with 500 records may need Custom Service if a small set of records carries proprietary pricing or fulfillment logic. Capacity and service fit should be calculated separately, then combined in the final purchase decision.
This distinction also prevents price from driving scope. Selecting a lower-capacity plan can reduce price only when the counted requirement genuinely fits. It cannot remove a custom data dependency or change who is prepared to execute the work.
Test Whether the Requirement Is Supported
The first service-fit question is whether available migration behavior can produce the intended result.
A requirement is more likely to remain within supported scope when:
- the migration path is supported;
- important records use predictable platform structures;
- source meaning can be represented through available target fields and relationships;
- standard configuration and Attribute Mapping cover the required alignment;
- any extra filtering, value transformation, or field redirection fits a Standard Add-on;
- acceptance evidence can be defined without bespoke migration logic.
Custom Service should be considered when the expected result depends on:
- a Custom 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 or external-system identifiers;
- bespoke transformation, restructuring, or relationship logic;
- a Standard Add-on that must be modified;
- a new project-specific Add-on;
- a target representation that must be designed and agreed individually.
The strongest evidence is specific. “The Store has custom data” is too vague. “Contract prices are stored in a custom table keyed by Customer group and Product SKU, and the Target Store must preserve that commercial relationship” identifies the data, ownership, relationship, and intended outcome.
Decide Whether a Standard Add-on Is Enough
An Add-on can keep a supported project within Standard or Managed Service when the problem is bounded and the available behavior fits.
| Required control | Standard Add-on direction | Boundary to verify |
|---|---|---|
| Filter which records are migrated by applying field-based conditions to a data type | Data Filter | The data type, source field, condition, and inclusion or exclusion rule are supported |
| Remap a supported source field to a compatible target field | Advanced Data Mapping | Source and target value types, relationships, and downstream uses remain valid; Tax is excluded |
| Map supported fields or underlying database columns to compatible target fields or columns | Advanced Database Mapping | Both the Source Platform and Target Platform are open-source, and field/column, value type, relationship, and downstream-use requirements remain supported; Tax is excluded |
| Transform selected target field values during migration | Data Transformation | The expression, input values, and target-compatible results are defined |
The Add-on test should ask whether the expected output can be described and produced through the available capability. If the capability itself needs modification, it becomes a Tailored Add-on under Custom Service. If no Standard Add-on addresses the requirement, a Custom Add-on or broader custom scope may be needed.
Using an Add-on is not evidence that a project is custom. Needing to change the Add-on, interpret unsupported data, or create project-specific behavior is the stronger custom signal. Several Standard Add-ons may be combined when one outcome needs multiple supported stages; the combination itself does not make the Migration Service custom.
Evaluate the Real Execution Burden
Once supported or tailored scope is understood, the project can decide who should perform the agreed migration actions.
Customer-led execution requires more than the ability to start an action. The team must be able to:
- prepare required access and source information;
- understand configuration decisions;
- select representative Demo evidence;
- coordinate the migration window;
- respond to failures or unexpected results;
- involve business, SEO, technical, and operational reviewers;
- document final acceptance.
If the migration remains supported and the internal team can carry that workload, Standard Service may fit. If supported scope remains suitable but execution should be included, Managed Service may fit.
If tailored work is required, Custom Service applies regardless of who executes. The project can remain customer-led or include Expert Handle. Expert Handle should be selected because execution responsibility must be included, not because the word “custom” is assumed to mean fully managed.
Use Demo Migration to Challenge Assumptions
Demo Migration is most valuable when it tests the assumptions that would change the service decision. A sample made only of simple Products and routine Orders may confirm basic transfer behavior while leaving the real risk untouched.
Representative evidence might include:
- a Product with complex variants or custom attributes;
- a Customer whose group affects pricing or visibility;
- an Order with refunds, unusual status history, or external references;
- content with important URL or SEO value;
- records likely to reveal filtering, transformation, or mapping needs;
- a custom field or third-party record whose required handling must be tested against supported mapping or tailored-scope boundaries.
Demo Migration cannot validate configured Add-ons or Customization because those capabilities are unavailable within the Demo. It can still reveal the requirement and show where further evidence is needed.
The interpretation should be disciplined:
- a predictable supported result strengthens the case for Standard or Managed Service;
- a supported result plus insufficient internal execution capacity strengthens the case for Managed Service;
- unsupported structure, bespoke transformation, or unresolved relationship logic strengthens the case for Custom Service;
- an unrepresentative sample does not support any confident service decision.
Compare the Services After the Evidence Is Developed
Only after scope and execution have been examined does a comparison table become useful.
| Evidence pattern | Likely direction | Reasoning |
|---|---|---|
| Supported path and structures; Standard Add-ons are sufficient; team can execute and validate | Standard Service | Customer-led supported migration is credible |
| Supported path and structures; Standard Add-ons are sufficient; expert-led execution is required | Managed Service | Execution responsibility is the unmet need |
| Tailored or non-standard handling is required; team can execute and validate | Customer-led Custom Service | Custom capability is needed without Expert Handle |
| Tailored or non-standard handling is required; expert-led execution is also required | Custom Service with Expert Handle | Both custom scope and execution responsibility must be included |
This is a decision framework, not an automatic scoring system. A single critical custom dependency can outweigh many standard records. A strong internal team can make Standard Service appropriate for a large supported migration. Evidence quality matters more than the number of boxes that appear to favor one option.
Review Pricing Only After Service Fit
Pricing combines Entity Points capacity, Migration Service, purchased Add-ons, and custom-scoped work. Comparing displayed amounts before service fit is established can create a false economy.
A useful order is:
- calculate realistic Entity Points capacity;
- establish whether the result is supported or custom;
- assign execution responsibility;
- identify Standard, Tailored, or Custom Add-ons;
- review the applicable plan price and custom quote.
Custom Service displays the Standard Service price for the selected Entity Points Plan as a starting floor. The final amount depends on the agreed custom work, purchased Add-ons where applicable, Expert Handle when included, and other agreed scope-specific costs. The starting amount should not be compared with a fixed Standard or Managed price as though all three figures describe identical included work.
The upgrade path should also inform the choice without replacing evidence. Standard can later move to Managed or Custom, and Managed can later move to Custom. A purchased Migration Service cannot be downgraded. An allowed upgrade becomes part of the same migration and charges the additional difference, but it does not change the fixed path or extend the one-year duration.
Record Why the Choice Is Defensible
A service decision should survive later scrutiny. The rationale should capture:
- the required business outcomes;
- why the migration path and important structures are considered supported or custom;
- which bounded requirements fit Standard Add-ons;
- which requirements need tailored work;
- who will perform the migration actions;
- what Demo Migration proved and what it could not prove;
- which Target Platform implementation remains separate;
- what evidence will support final acceptance.
This record is valuable when the project changes. If new evidence reveals custom data or the internal team loses execution capacity, the service can be reconsidered against the original rationale. The decision changes because the evidence changed, not because the project drifted toward a different label.
Conclusion
The right Next-Cart Migration Service is the result of evidence, not a shortcut based on Store size, price, or perceived service level. Define the intended outcome, separate capacity from complexity, test supported scope, determine whether a Standard Add-on is sufficient, and assign execution responsibility.
Choose Standard Service for customer-led execution within supported scope. Choose Managed Service when supported scope remains suitable and expert-led execution is required. Choose Custom Service when the expected result requires tailored handling, with Expert Handle included only when execution responsibility also needs to be part of the accepted custom scope.
Common Questions
Can a large Store use Standard Service?
Yes. A large Store can fit Standard Service when the path and requirements remain supported and the customer can coordinate execution and validation.
When is Managed Service more suitable than Standard Service?
Managed Service is more suitable when the migration remains within supported scope but expert-led execution of the agreed migration actions is required.
What is the strongest signal that Custom Service is needed?
The strongest signal is a required outcome that cannot be produced through supported migration behavior and available Standard Add-ons, such as bespoke logic, unsupported data, or a project-specific target representation.
Can Add-ons replace Custom Service?
Only when the bounded requirement fits the available Standard Add-on scope. Several Standard Add-ons can work together without Custom Service when each operation remains supported. Modified Add-ons, new Add-on behavior, unsupported records, and bespoke relationships require Custom Service review.
Do Entity Points determine the Migration Service?
No. Entity Points determine counted capacity. The Migration Service depends on supported scope, execution responsibility, Add-on needs, tailored requirements, and acceptance evidence.
Should price be compared before Demo Migration?
Price can be estimated earlier, but it should not determine the service choice until representative evidence has tested the assumptions that affect supported scope and execution responsibility.
Can the Migration Service be changed after purchase?
Only upward. Standard can move to Managed or Custom, and Managed can move to Custom. The customer pays the additional difference, while the path and original service duration remain unchanged.