A 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, 12-month access period, 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. Successful payment for the initial purchase begins the migration’s first 12-month access period, 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 change the expiration of the active access period. An expired migration must be extended before further eligible activity can continue. Successful payment for an extension renews the same migration for a new 12-month access period measured from the extension settlement time.
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 |
| Access period | When does the active 12-month period begin and expire? | Whether an upgrade changes expiration or an extension renews access |
| 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. Self-Execute keeps execution of the agreed migration actions with the customer, while Expert Handle includes expert-led execution as part of the accepted 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, active access period, 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.
How the initial commercial commitment is finalized depends on whether the scope is already bounded. Standard and Managed Service have fixed plan prices, so their service subtotal can be determined once the migration path, Entity Points Plan, applicable Add-ons, and execution responsibility are known, before order-specific adjustments such as taxes or discounts. Custom Service requires the non-standard requirements to be assessed and itemized before the final custom amount can be established. That difference is not merely a payment detail; it reflects the additional information needed to price bespoke work against a defined functional outcome.
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: the retained package remains the renewal basis, and successful extension settlement starts a new 12-month access period for the resulting migration package.
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.
- Data Transformation changes supported values on the active dataset through supported expressions.
- Advanced Data Mapping routes supported source or transformed values to compatible target fields without changing them during mapping.
- Advanced Database Mapping routes supported data through eligible database tables, fields, or columns only when the selected Source setup and Target Platform both support the Add-on and the requested database locations are compatible.
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 active 12-month access period establish the operating 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 access period?
No. A purchased upgrade is integrated into the same migration. The fixed path remains unchanged, and the upgrade does not change the current expiration. A successful extension payment is the separate event that begins a new 12-month access period.
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 use Self-Execute when the customer will perform the agreed migration actions. Expert Handle is included only when expert-led execution 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.
How does a Next-Cart migration engagement begin?
Begin by defining the fixed Source Platform-to-Target Platform path, the Migration Service that matches the execution model, and the Entity Points capacity required for the counted data. Add-ons or approved Custom scope are then considered only when the requirement needs them. A Demo Migration can be used as an early validation checkpoint before the full paid migration is relied on for production planning.
Can a test-to-production change be assumed to stay within the same migration purchase?
No. A purchased migration is tied to a fixed migration path and can lock the Source Store, Target Store, or both. A staging or test environment should therefore be planned with the intended production identity in mind. Do not assume that an arbitrary new Target Store can replace the originally locked Target without checking the current Store Identity and service rules.
Does support for a platform mean every edition, direction, and data structure is supported?
No. Support is directional and can vary by platform edition, Source versus Target role, connection method, available data types, and the target representation of a source structure. A platform name by itself is not proof that every version or feature is supported. Qualify the exact Source-to-Target path and the required data before treating a capability as available.