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.
Connection method is one of those path-specific requirements. API, File Upload, and KitConnect are connection mechanisms rather than Migration Services, and the supported method depends on the exact platform and role. Understanding KitConnect develops the Next-Cart-specific server-side bridge model for readers who need to understand why that method exists, what its reachability proves, and where its security and scope boundaries begin.
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 Migration |
| 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 Migration is assumed to include every non-standard requirement. None of those conclusions follows from the component itself.
Understand the Core Commerce Data Scope
A supported migration path carries more than record names. The core commerce scope can include the business fields and relationships that make those records usable:
- Products can include names, descriptions, prices, images, and variants;
- Categories can retain hierarchical structure and Product placement;
- Customers can include names, email addresses, and purchase history;
- Orders can include Order details, statuses, associated Products, and Customer information;
- Taxes can include tax classes, tax rules, and tax rates;
- Manufacturer, Brand, or Vendor data can remain linked to the relevant Products;
- Reviews can remain associated with the applicable Products and Customers when the migration path supports those relationships;
- Blog Posts and CMS Pages can preserve supported content and related metadata;
- Coupons can preserve supported promotional-code data and conditions when the Source and Target models can represent them.
The exact data types available are migration-path specific. The Documentation directory and active migration configuration remain the operational authority for a particular Source-to-Target path.
These examples describe migration data, not executable storefront functionality. Custom functionality and plugin behavior are not migrated automatically as working software. When an application, extension, plugin, module, or bespoke feature owns important data or behavior, that requirement needs a supported target representation or an accepted Custom Migration scope rather than an assumption that the functionality itself will be copied.
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 Migration and Managed Migration both address supported migration requirements. Their principal difference is execution responsibility. Standard Migration follows a customer-led approach. Managed Migration includes expert-led execution of the agreed migration actions within supported scope.
Custom Migration 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 Migration 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 Migration 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 Migration 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 Migration. If no Standard Add-on fits, a Custom Add-on or broader Custom Migration 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.
Guidance and Execution Are Separate Responsibilities
Customers can obtain guidance and assistance throughout the migration, but the selected service determines who performs the migration actions. Standard Migration is customer-led. Managed Migration and Custom Migration with Expert Handle include expert-led execution of the agreed migration actions. Custom Migration with Self-Execute keeps execution with the customer after the agreed tailored work is ready.
That assistance does not replace business acceptance. Under every service, the customer remains responsible for validating that Products, Customers, Orders, content, relationships, and target behavior satisfy the intended result.
Choose the Next Decision From the Migration Components
Different migration components answer different questions. Isolate the decision that remains uncertain, then continue with the topic that owns that decision:
| Decision to resolve | Next topic |
|---|---|
| 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 Migration? | What Custom Migration Handles |
| Which Migration Service fits the project evidence? | Choose the Right Migration Service |
| Which later action matches continuity, changed configuration, or a fresh result? | Migration Actions |
The topics do not need to be followed in sequence. Start with the unresolved decision without collapsing capacity, service responsibility, custom scope, and validation into one question.
What the Migration Service Does Not Automatically Reproduce
A successful data migration is not a complete rebuild of the Source Store. The service transfers supported data and relationships within the purchased Source-to-Target path, but it does not automatically reproduce every part of the source operating environment.
Common boundaries include:
- theme and storefront design: layouts, theme code, page-builder behavior, and visual customization need separate Target Store implementation;
- application and extension behavior: transferring a value owned by an app, module, or plugin does not recreate the executable logic, automation, subscription engine, wholesale rules, or user interface of that extension;
- unsupported custom structures: bespoke tables, custom relationships, third-party data, or non-standard logic require explicit Custom Migration scope when they are not covered by the supported migration path or an Add-on;
- external systems: ERP, PIM, CRM, marketplace, accounting, fulfillment, payment, and other integrations retain their own configuration and ownership after migration;
- target-platform constraints: data must fit the Target Platform's supported records, limits, and representation model. A source concept can require restructuring rather than one-to-one copying;
- live business configuration: payment gateways, shipping methods, taxes, domains, themes, apps, and launch configuration are separate from migrating historical data unless explicitly included in the agreed scope.
This boundary is why migration acceptance should test both record completeness and business meaning. A field can be present while the source behavior that consumed it is still missing.
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 Migration 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 Migration?
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 Migration?
Yes. A Standard Add-on can accompany Standard, Managed, or Custom Migration when its available behavior fits the bounded requirement.
Does Custom Migration always include Expert Handle?
No. Custom Migration 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. A Store URL lock is created only after the required connection setup succeeds, Connect Stores is saved, and the migration advances to Configuration. When the active Source setup includes a Store URL, the Source Store URL locks. When the Source setup has no Store URL and the Target setup includes one, the Target Store URL locks. If neither active setup includes a Store URL, no new URL lock is created. Entering a URL or running Test Connection alone does not create the lock, and later migration activity, configuration changes, upgrades, or extensions do not reset an established lock. A staging or test environment should therefore be planned with the intended production identity in mind.
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.