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 Migration supports customer-led execution within supported scope.
- Managed Migration includes expert-led execution within supported scope.
- Custom Migration addresses tailored requirements and may be customer-led or include Expert Handle.
Before comparing those three options, check whether the migration path fixes the Service automatically.
CSV, XLS, and XML Source Platform selections require Custom Migration, as does any migration to a Target Platform outside the supported Target Platform list.
The included CSV/XLS/XML workflow covers Products only; other data types require explicitly approved and developed Custom scope.
In those cases, the useful decision is the required Entity Points capacity and Custom Migration scope, not whether Standard or Managed might be preferable.
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.
Illustrative examples:
- A Store with 200,000 predictable records may fit Standard Migration when the team can lead execution.
- A Store with 500 records may need Custom Migration 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 Migration 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.
Illustrative requirement: "Contract prices are stored in a custom table keyed by Customer group and Product SKU, and the Target Store must preserve that commercial relationship."
That statement identifies the data, ownership, relationship, and intended outcome.
Use the custom-requirements guide to turn that evidence into a testable request.
Decide Whether a Standard Add-on Is Enough
An Add-on can keep a supported project within Standard or Managed Migration 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 |
| Transform supported values before routing | Data Transformation | The expression, input values, and target-compatible results are defined |
| Route a supported source or transformed value to a compatible target field | Advanced Data Mapping | Source and target value types, relationships, and downstream uses remain valid; Tax is excluded |
| Route supported data through eligible database tables, fields, or columns | Advanced Database Mapping | The selected Source setup and Target Platform both support the Add-on, the requested database locations and Value Types are compatible, and downstream-use requirements remain valid; Tax is excluded |
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 Migration. 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 Migration may fit. If supported scope remains suitable but execution should be included, Managed Migration may fit.
If tailored work is required, Custom Migration applies regardless of who executes.
- Self-Execute keeps execution with the customer.
- Expert Handle includes expert-led execution.
Under Managed Migration and Custom Migration with Expert Handle, Next-Cart technical specialists can perform the agreed migration actions on request within the active service and accepted scope. The customer still retains access to perform available migration activity manually.
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 Migration;
- a supported result plus insufficient internal execution capacity strengthens the case for Managed Migration;
- unsupported structure, bespoke transformation, or unresolved relationship logic strengthens the case for Custom Migration;
- 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 Migration | Customer-led supported migration is credible |
| Supported path and structures; Standard Add-ons are sufficient; expert-led execution is required | Managed Migration | Execution responsibility is the unmet need |
| Tailored or non-standard handling is required; team can execute and validate | Custom Migration with Self-Execute | Custom capability is needed without Expert Handle |
| Tailored or non-standard handling is required; expert-led execution is also required | Custom Migration 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 Migration 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, including Self-Execute or Expert Handle when Custom Migration applies;
- identify Standard, Tailored, or Custom Add-ons;
- review the applicable plan price and, for Custom Migration, the scoped quote after the non-standard requirements are itemized.
Selecting Custom Migration changes not only the amount but how the final amount is established. Standard and Managed prices can be evaluated directly once capacity, applicable Add-ons, and execution responsibility are known. Custom Migration starts from the Standard Migration price for the selected Entity Points Plan, then the non-standard requirements are assessed and itemized before the final quote is established.
The final Custom Migration 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 scoping step is a consequence of tailored work, not evidence that Custom Migration is a higher-quality tier.
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 the expiration of the active access period.
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.
Review the available routes in the migration service overview once scope and execution responsibility are clear.
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 Migration for customer-led execution within supported scope.
- Choose Managed Migration when supported scope remains suitable and expert-led execution is required.
- Choose Custom Migration when the expected result requires tailored handling, using Self-Execute when the customer will perform the migration actions or Expert Handle when execution responsibility also needs to be included.
Common Questions
Can a large Store use Standard Migration?
Yes. A large Store can fit Standard Migration when the path and requirements remain supported and the customer can coordinate execution and validation.
When is Managed Migration more suitable than Standard Migration?
Managed Migration 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 Migration 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 Migration?
Only when the bounded requirement fits the available Standard Add-on scope. Several Standard Add-ons can work together without Custom Migration when each operation remains supported. Modified Add-ons, new Add-on behavior, unsupported records, and bespoke relationships require Custom Migration 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 fixed path and current expiration remain unchanged.