Next-Cart Migration Service is easy to underestimate when it is viewed as one payment and one transfer. The customer purchases a migration that remains the organizing unit for the service. Its fixed migration path, one-year service duration, counted capacity, execution responsibility, supported enhancements, and any tailored requirements work together to shape the result.
Those decisions are connected, but they are not interchangeable. A large Store may have predictable data and fit a customer-led migration. A smaller Store may depend on custom fields or third-party records whose required handling falls outside supported migration or Standard Add-on scope. An Add-on can solve a bounded mapping need without changing the entire Migration Service. Entity Points can cover the counted data volume without proving that the target representation will be usable.
The most useful overview of Next-Cart Migration Services therefore treats the purchased migration as a set of coordinated layers. Each layer answers a different project question. Later upgrades become part of that same migration instead of creating unrelated services, so the migration remains the stable context for planning, execution, and validation.
Begin With the Migration Outcome
The migration path defines a fixed one-way direction from a Source Platform to a Target Platform. That direction is more than a routing detail. It establishes which platform structures must be interpreted, which connection requirements must be prepared, and which target limitations may affect the result.
Before considering capacity or price, the intended outcome should be clear. The project may need Products to remain buyable, Customer histories to remain useful, Orders to retain service context, content to preserve SEO value, or external identifiers to remain connected to another system. These outcomes determine what the migration must preserve and what evidence will be needed later.
One purchased migration covers one Source Platform-to-Target Platform path. The path cannot be changed after purchase. The service remains available for one year from the initial purchase time, subject to the selected capacity, Migration Service, purchased Add-ons, agreed custom scope, and validation responsibilities.
Upgrading a component does not create a new path or restart the one-year duration. The upgrade changes the existing migration, while the original purchase time continues to define the service period. An expired migration must be extended before further eligible activity can continue.
Separate the Decisions Inside One Purchased Migration
A purchased migration normally brings together several planning decisions. The following table is most useful after the outcome and migration path are understood, because it shows which question each component is designed to answer.
| Component | Project question it answers | What it does not decide |
|---|---|---|
| Migration path | Which fixed Source Platform-to-Target Platform direction is covered? | Whether the data model is simple or the result is acceptable |
| Service duration | How long does the purchased migration remain active from its initial purchase? | Whether an upgrade changes the path or restarts the duration |
| Entity Points Plan | How much counted Product, Customer, Order, and Blog Posts capacity is available? | Whether the project needs Managed or Custom Service |
| Migration Service | Who is responsible for execution, and does the requirement remain supported or need tailored handling? | How much counted capacity is required |
| Add-ons | Can a bounded filtering, field or database mapping, or target-value transformation need be handled through a supported enhancement? | Whether broader unsupported or bespoke work is covered |
| Agreed custom scope | Which non-standard data, logic, relationships, or outputs require tailored work? | Target Platform implementation unless expressly included |
Confusion usually begins when one row is used to answer another row’s question. Store size is used as a substitute for service fit. A low Entity Points estimate is treated as proof of simplicity. An Add-on is expected to solve a custom data model. Managed Service is assumed to include every non-standard requirement. None of those conclusions follows from the component itself.
Capacity Describes Volume, Not Complexity
Entity Points translate four counted data types into weighted capacity:
- Product;
- Customer;
- Order;
- Blog Posts.
The selected Entity Points Plan must provide enough capacity for the realistic counted requirement. That is a volume decision. Complexity can still arise from Products with unusual option structures, application-owned records, custom Customer attributes, external Order identifiers, multilingual relationships, or target-side limitations.
Consider two Stores with the same Entity Points estimate. The first uses standard platform records and predictable relationships. The second stores contract pricing in custom tables and relies on an external identifier to connect Orders with an ERP. Their counted capacity may be equal, but their migration requirements are not. Capacity planning should therefore be completed alongside, not instead of, structural analysis.
The detailed weight calculation and consumption rules belong in Entity Points. Plan capacities, upgrade pricing, and extension pricing belong in Entity Points Plan and Migration Pricing.
Responsibility and Scope Are Different Axes
Migration Service selection combines two distinct questions:
- Does the expected result remain within supported migration behavior, or does it require tailored work?
- Who should perform the agreed migration actions?
Standard Service and Managed Service both address supported migration requirements. Their principal difference is execution responsibility. Standard Service follows a customer-led approach. Managed Service includes expert-led execution of the agreed migration actions within supported scope.
Custom Service addresses tailored or non-standard requirements. It may remain customer-led, or Expert Handle may be included when execution of the agreed actions also needs to be part of the custom scope.
This distinction prevents a common mistake: treating Managed Service as the answer to unsupported data. Expert-led execution does not make a custom structure standard. Conversely, a custom requirement does not automatically mean expert-led execution is needed.
Standard, Managed, and Custom Migration Services develops these definitions. Choose the Right Migration Service explains how to make the decision from project evidence.
Treat the Migration as the Service Record
The purchased migration and the payments related to it answer different questions. The migration represents the current service state: its fixed path, selected Migration Service, Entity Points Plan, Add-ons, accepted custom work, service duration, and migration history. Orders provide the commercial record of how that state was purchased, upgraded, or extended.
The initial purchase creates the migration. A later plan, service, Add-on, or custom-work upgrade becomes part of that same migration once purchased. This distinction explains why a migration can have several related orders without becoming several unrelated migration services.
It also clarifies later pricing. An upgrade is measured against the value already paid for the migration, so the customer pays the additional difference rather than repurchasing the complete package. Extending an expired migration is different: extension restores service from the latest retained migration state, including applicable components already integrated into it.
For service planning, the distinction matters because migration continuity follows the purchased migration, while each payment remains traceable to the commercial change it records.
Use Add-ons for Bounded Problems
Add-ons are most useful when the migration path is supported but a defined part of the result needs additional control. The four Standard Add-ons address different kinds of bounded requirements:
- Data Filter chooses which records migrate by applying field-based conditions to each data type.
- Advanced Data Mapping remaps supported source fields to compatible target fields.
- Advanced Database Mapping maps supported fields and underlying database columns to compatible target fields or columns, including platform-specific and custom fields, only when both the Source Platform and Target Platform are open-source.
- Data Transformation transforms selected target field values as records are migrated from Source Store to Target Store.
The boundary matters. Standard Add-ons are compatible with all three Migration Services when an available Add-on already fits the requirement. If the Add-on itself must be modified, the requirement becomes a Tailored Add-on under Custom Service. If no Standard Add-on fits, a Custom Add-on or broader Custom Service review may be needed.
The decision should begin with the required outcome, not the Add-on name. “Move only Orders after an approved date” describes a filterable result. “Preserve a proprietary pricing engine” describes a broader custom problem whose meaning, relationships, and target behavior must first be defined.
Turn Early Results Into Evidence
Demo Migration can provide representative early evidence before broader migration activity. Its value depends less on seeing records appear and more on choosing samples that expose meaningful differences.
A strong sample may include a Product with variants and special attributes, an Order with unusual status history, a Customer used in a real segmentation workflow, or content with important URL value. Simple records can show that a basic path works; difficult records show whether the migration assumptions are strong enough.
Demo Migration has defined limits, and Add-ons and Customization are unavailable within it. The result can reveal a likely need for supported enhancement or tailored work, but it cannot prove how that later configuration will behave. Demo Migration explains how to select evidence and interpret its limits.
Keep Execution Separate From Acceptance
Execution produces a migration result. Validation establishes whether that result is usable for the business.
Final review should examine more than record presence. It should confirm that important Products retain purchasing meaning, Customers and Orders remain useful, content and URLs support the intended journey, relationships still connect the right records, and any Add-on or custom output matches the accepted scope.
The customer remains responsible for final verification under every Migration Service. This is not a transfer of execution responsibility back to the customer. It reflects a different type of ownership: only the business can confirm that the Target Store supports the intended commercial, operational, SEO, and compliance outcomes.
Target Platform configuration, theme work, application installation, integration deployment, and other implementation work should be identified separately unless they are expressly included in the agreed scope. A correct migrated record does not by itself configure the system that will use it.
Use the Section as a Decision System
The service articles are designed to answer different questions:
| Decision to resolve | Article |
|---|---|
| How does the migration move from preparation to validated result? | How the Migration Process Works |
| What can representative early evidence prove? | Demo Migration |
| How is counted capacity calculated and consumed? | Entity Points |
| Which plan and price apply? | Entity Points Plan and Migration Pricing |
| Can a bounded supported requirement be handled by an Add-on? | Add-ons |
| How do the three Migration Services differ? | Standard, Managed, and Custom Migration Services |
| Which tailored requirements belong in Custom Service? | What Custom Service Handles |
| Which Migration Service fits the project evidence? | Choose the Right Migration Service |
| Which later action matches continuity, changed configuration, or a fresh result? | Additional Migration Options |
This reading route is not a required sequence. It is a way to isolate the decision that remains uncertain without collapsing capacity, service responsibility, custom scope, and validation into one question.
Conclusion
A Next-Cart migration is best understood as a durable purchased service rather than a single transfer or payment. Its fixed migration path and one-year duration establish the boundary. Entity Points provide counted capacity. The Migration Service defines supported or tailored scope and execution responsibility. Add-ons solve bounded supported requirements. Custom Service addresses non-standard needs. Related orders record purchases, upgrades, and extensions without fragmenting the migration itself. Validation determines whether the result is fit for business use.
Keeping these layers separate produces clearer estimates, more defensible service choices, and better acceptance evidence. It also prevents a common planning error: assuming that one component, such as Store size, price, or an Add-on, can explain the entire migration.
Common Questions
What does the migration path define?
It defines the fixed one-way direction from the Source Platform to the Target Platform covered by the purchased migration.
Does an upgrade create a new migration or restart the service duration?
No. A purchased upgrade is integrated into the same migration. The fixed path remains unchanged, and the one-year duration continues from the initial purchase time.
Why can one migration have several related orders?
The initial order creates the migration. Later orders can record upgrades or an extension while the migration remains the service being managed.
Does a larger Entity Points Plan require Managed or Custom Service?
No. Entity Points determine counted capacity. Migration Service selection depends on supported scope, execution responsibility, Add-on needs, and tailored requirements.
Can an Add-on be used with Standard Service?
Yes. A Standard Add-on can accompany Standard, Managed, or Custom Service when its available behavior fits the bounded requirement.
Does Custom Service always include Expert Handle?
No. Custom Service may remain customer-led. Expert Handle is included only when expert-led execution of the agreed migration actions is part of the accepted custom scope.
Why is customer validation required after expert-led execution?
Execution confirms that migration activity was performed within the agreed scope. Customer validation confirms that the resulting Products, Customers, Orders, content, relationships, and business outcomes are acceptable for the Target Store.