The Next-Cart migration process should do more than move records from one Store to another. It should progressively reduce uncertainty. Early assumptions about access, scope, mapping, and target representation need to become testable decisions. Execution then produces a broader result, and validation determines whether that result is usable for the business.
This perspective changes how the process is managed. Connection is not merely a technical handshake. Configuration is not a minor setup task. Demo Migration is not final proof. A completed Full Migration is not automatic launch approval. Each stage produces a different kind of evidence, and the quality of the final decision depends on how those handoffs are understood.
Within Next-Cart Migration Services, the execution context is chosen before connection or configuration begins. A Demo Migration and a paid migration use the same broad pattern of connecting, configuring, running, and validating, but they do not expose the same capabilities. The complete project also includes preparation before execution and later migration decisions when the Source Store continues changing.
Define the Outcome Before Data Starts Moving
The process begins with a fixed migration path from a Source Platform to a Target Platform. That path establishes the platform structures, access requirements, and target limitations that must be considered.
The project should then define what a usable result means. Record totals alone are rarely enough. Products may need to retain buyable variants. Customers may need to remain identifiable by group. Orders may need historical status and line-item context. Content may need to preserve important URLs. External identifiers may need to remain connected to another system.
These outcomes become acceptance criteria. They guide which records should be sampled, which configuration decisions deserve closer review, and which Target Store results should be treated as Pass, Watch, or Block.
Preparation should also identify:
- important data types and relationships;
- source records owned by applications, plugins, modules, or extensions;
- custom fields, tables, or external-system identifiers;
- content and URLs with commercial or SEO value;
- expected Source Store activity during the migration window;
- Target Platform implementation that remains separate from data migration;
- owners for configuration, execution, and final validation.
The process becomes unstable when these issues are discovered only after a broad migration has already been treated as authoritative.
Choose the Migration Context Before Configuration
Next-Cart does not require the customer to configure a migration first and decide later whether the work is a Demo or a paid run. The execution context is selected first. That choice determines which configuration capabilities are available inside the migration that follows.
A Demo Migration is a limited test context. It can be reopened or started as a new Demo, then connected, configured with the reduced Demo controls, run, and validated. A paid migration is opened from the purchased migration record, then connected, configured with the capabilities available to that purchased service, run, and validated.
This distinction matters because the same configuration concept can expose different controls. Demo uses reduced Data Selection and Additional Options, and it does not expose Add-ons or Custom selection. Paid migration work can expose those capabilities when they were purchased or approved.
Before a paid migration has run, Perform a New Migration is the only available Migration Action because there is no earlier paid configuration or result to continue. After the paid migration has run at least once, all three Migration Actions become available. Later activity can then use Continue the Migration with Last Saved Configuration, Continue the Migration with a New Configuration, or Perform a New Migration according to the intended outcome.
Connection Tests the Reachability Assumption
After the Demo or paid migration context has been selected, supported connection requirements depend on the selected Source Platform, Target Platform, and role-specific setup. Some paths use API authorization, some rely on File Upload, and supported self-hosted setups may use KitConnect. The practical purpose of connection is to establish whether the migration can reach the records and media needed for the approved scope.
Within Next-Cart Migration Services, KitConnect is the temporary server-side bridge used when a supported Store setup is assigned that connection method. Understanding KitConnect explains why this model exists, how Source and Target roles differ, and why connection success must not be confused with scope or final migration quality.
A KitConnect or API connection can be tested independently for the Source Store and Target Store. This separation is diagnostically important. A successful Source Store test confirms source reachability only, while a successful Target Store test confirms target reachability only. If one side passes and the other fails, the project can focus on the failing Store's access, credentials, endpoint, or installation conditions instead of treating the path as one undifferentiated connection problem.
A successful connection does not prove that every important business record is available. Some data may live in custom tables, application-owned structures, exported files, or external systems. Connection preparation should therefore compare the reachable data with the scope inventory.
This comparison can expose an early decision:
| Finding | Migration implication |
|---|---|
| Required records are reachable through supported access | Configuration can proceed with stronger scope confidence |
| Important records exist outside supported platform structures | Custom Migration review or separate implementation planning may be required |
| Media or content dependencies are incomplete | Preparation must be corrected before representative evidence is trusted |
| Target access exists, but the required target representation is unclear | Mapping and implementation responsibilities must be resolved before execution |
The value of this stage is not simply that two Stores can communicate. It is that the project can confirm whether the available data matches the migration promise.
Configuration Turns Scope Into a Testable Hypothesis
Configuration happens inside the migration context that was already selected. It translates the migration plan into concrete handling decisions. It identifies which supported data types are included, how standard attributes align, which settings apply, and whether purchased Add-ons are needed.
At this point, the project is effectively making a hypothesis:
If these records are selected, these mappings are used, and these configuration choices are applied, the Target Store should preserve the intended business meaning.
That hypothesis should be challenged before it governs broad execution. Important questions include:
- Do source and target fields carry the same meaning?
- Will Product options and variants remain buyable?
- Are Customer groups and Order statuses aligned appropriately?
- Are language, location, inventory, payment, or fulfillment values mapped correctly?
- Should all scanned records migrate, or is filtering required?
- Does a supported value need transformation?
- Does a supported source field need a different compatible destination?
- Does any requirement exceed available Add-on behavior?
Entity quantities entered for purchase support Entity Points estimation and pricing. They are not migration filters. All scanned records within the selected supported data types are migrated by default unless filtering is configured. A selective scope should therefore be expressed through Data Filter using field-based conditions for each relevant data type, or reviewed as a custom filtering requirement when available behavior is insufficient.
Configuration quality matters because a record can be present and still be unusable. A Product with the wrong option relationship, an Order with a meaningless status, or a Customer assigned to the wrong group may increase the count while weakening the migration outcome.
Demo Migration Provides Early but Limited Evidence
Demo Migration is a separate execution context, not a stage chosen after a paid configuration has already been completed. It is most valuable when representative records are chosen to challenge the configuration hypothesis created inside the Demo itself.
Simple records can show basic transfer behavior. Difficult records can reveal whether source meaning survives. Useful samples often include Products with variants, Customers with meaningful group logic, Orders with unusual histories, content with important URLs, and records likely to expose filtering, mapping, or custom-data requirements.
Demo Migration has defined data and quantity limits. Add-ons and Customization are unavailable within it. The result can reveal that those capabilities may be needed, but it cannot validate their configured behavior.
The decision after Demo Migration should not be "records appeared, so the project is ready." It should be:
- which assumptions received support;
- which relationships or values remain uncertain;
- which requirement needs an Add-on or Custom Migration review;
- which samples should be tested again during paid migration activity;
- whether the selected Migration Service still fits the evidence.
Demo Migration develops these evidence and sample-selection decisions in detail.
Full Migration Produces the Broader Result
A paid migration is selected before its connection and configuration work begins. Full Migration then applies the accepted paid configuration to the selected supported scope. The first paid execution transfers all data included in that accepted scope from the Source Store to the Target Store. This is the point where planning and early evidence become a broader Target Store result.
At migration initiation, the system calculates the number of records to be migrated for each selected data type. That calculation establishes the source window for the activity: only records that exist when the migration begins are included in that same activity. Products or Orders added while processing is already in progress are not added retroactively to the running migration.
Within each data type, records are processed from the oldest record to the newest record, which normally corresponds to the smallest source ID before the largest source ID. This source-ID order is used so migrated records display in the same order on the Target Store as on the Source Store.
Store data is processed in a fixed data type processing sequence:
Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts
The migration processes selected data types in a defined sequence so dependent records can be handled in a stable order. Categories precede Products, for example, because Product placement depends on catalog structure.
The data type processing sequence should not be confused with Entity Points consumption. Entity Points apply only to Products, Customers, Orders, and Blog Posts capacity. Taxes, Manufacturers, Categories, Reviews, Coupons, and CMS Pages may be part of the migration without independently consuming Entity Points.
Execution can still produce Failed or Skipped records, mapping differences, or target behavior that requires interpretation. A completed run means processing reached its end. It does not establish that every intended outcome passed.
Validation Converts Output Into Acceptance Evidence
Validation should compare the Target Store with the acceptance criteria defined before execution. The question is not only whether data exists, but whether it supports the intended next business step.
Priority areas often include:
- Product identity, options, variants, attributes, prices, images, and purchasing behavior;
- Category and navigation relationships;
- Customer identity, groups, addresses, and account expectations;
- Order lines, totals, statuses, refunds, and service context;
- Reviews, Coupons, CMS Pages, and Blog Posts where relevant;
- URLs, redirects, metadata, and content continuity;
- results affected by filtering, mapping, value transformation, or Custom Migration;
- external identifiers and relationships needed by connected systems.
Representative evidence is more useful than indiscriminate checking. High-value, structurally difficult, and business-critical examples should be reviewed by the people who understand their intended meaning.
The customer remains responsible for final verification under every Migration Service. Execution responsibility may be customer-led or expert-led, but business acceptance remains a separate decision.
Correction and Review Form a Recovery Loop
Validation can reveal incorrect relationships, missing records, mapping differences, or another result that needs correction. When issues are found, the problem should be corrected and the affected migration activity performed again so the Target Store can be reviewed against the intended result.
Under Managed Migration or Custom Migration with Expert Handle, Next-Cart technical specialists can perform the agreed correction and migration actions within the purchased scope. Under customer-led execution, the customer remains the execution owner and can escalate the issue through the supported assistance channels when investigation or guidance is needed.
A paid migration remains active for 12 months from purchase or a successful extension. Support applies throughout that validity period under the Service Level Agreement, while the responsibility for performing migration actions continues to follow the selected Migration Service.
Later Actions Address a Changing Source Store
Many migration projects do not end with one execution. The Source Store may continue receiving Products, Customers, Orders, or content while the Target Store is being prepared and validated.
Later activity should begin with the intended result:
- preserve continuity by reusing a valid configuration;
- continue while changing configuration;
- create a distinct fresh migration result.
Those intents correspond to:
- Continue the Migration with Last Saved Configuration
- Continue the Migration with a New Configuration
- Perform a New Migration
A Continue action establishes how the next paid migration activity relates to the previous configuration. It does not define which Source records the activity should read. Source Platform Options control that source-data window separately: Continue the previous migration is used only when the activity should continue from applicable previous migration state, while Migrate only newly added entities limits supported processing to records added after the last successful run. Neither Source Platform Option is selected automatically by a Migration Action.
Interrupted execution is therefore a source-state problem rather than a new-data rule. Browser-dependent execution, background execution, and stopping or resuming an in-progress migration govern the state of an activity that is already running or has been stopped. When a later activity must recover an applicable interrupted state, Continue the previous migration can be relevant; when the requirement is only newly added records, Migrate only newly added entities is the distinct control. Exact execution and configuration procedures belong in Documentation.
Every later action requires validation aligned with its purpose. Reusing a configuration should prove that the earlier assumptions remain valid. Changing configuration should prove the revised behavior. A new migration should prove that the fresh result replaced only what the approved scope intended.
New source records belong to a later activity
When the Source Store receives new records after a migration activity begins, those records can be handled in a later paid activity. The applicable Migration Action determines whether the previous configuration is reused, revised, or replaced. The Source Platform Option is chosen separately: use Migrate only newly added entities only when the intended source window is limited to records added after the last successful run. Existing records that were merely updated are not newly added records, so a newly-added-only window is not appropriate when those updates must also be processed. Relationship continuity must then be validated against the resulting Target Store rather than inferred from the action name.
Responsibility Changes the Handoff, Not the Evidence Standard
The same process can be customer-led or include expert-led execution. What changes is who prepares and performs the agreed actions. The evidence required for a trustworthy result does not disappear.
| Responsibility position | Main process ownership | Required customer role |
|---|---|---|
| Customer-led execution | Prepare access and configuration, perform actions, coordinate findings | Validate the Target Store and approve the outcome |
| Expert-led execution | Perform the agreed migration actions within the accepted scope | Supply accurate requirements, review evidence, and approve the outcome |
Clear handoffs prevent two opposite failures. The first is assuming that expert-led execution transfers business acceptance. The second is treating customer validation as though it cancels the value of expert execution. They are different responsibilities and both are necessary.
Source Windows and Relationship Continuity
A migration project does not need to treat the first completed run as the final data snapshot. During the active service period, later migration activity can process additional supported Source data under an appropriate Migration Action and source-data window.
The important distinction is conceptual: the Migration Action controls how the next activity relates to the earlier result and configuration, while Source Platform Options control special source-reading behavior. Continue the previous migration addresses applicable previous migration state. Migrate only newly added entities is the separate newly-added-record window. Neither option creates bidirectional synchronization, and neither replaces the need to validate relationships between newly processed records and data already represented in the Target Store.
A reverse flow requires a separate Migration in the opposite direction. The operational procedure for selecting a Migration Action and Source Platform Options belongs in Documentation.
Conclusion
The Next-Cart migration process moves from uncertainty to evidence. Preparation defines the outcome. The customer then chooses the Demo or paid migration context before connection and configuration begin. Connection tests whether the required data is reachable, configuration turns scope into a testable hypothesis, execution produces a result, and validation determines whether that result is usable. After a completed paid run, later actions determine how the next migration activity should relate to the earlier result.
Treating each stage as an evidence checkpoint prevents a completed run from being mistaken for a completed migration outcome. It also makes failures easier to diagnose because the project can identify whether the weakness began in scope, access, configuration, execution, or validation.
Common Questions
What are the main parts of the migration process?
The purchased workflow centers on connection, configuration, and migration. The complete project also includes outcome definition, preparation, representative evidence, validation, and later migration decisions.
Do the data type quantities entered during purchase limit what migrates?
No. They support Entity Points estimation and plan selection. All scanned records within selected supported data types are migrated by default unless filtering is configured.
What is the fixed data type processing sequence?
The sequence is Taxes, Manufacturers, Categories, Products, Customers, Orders, Reviews, Coupons, CMS Pages, and Blog Posts.
Is the data type processing sequence the same as Entity Points consumption?
No. The data type processing sequence covers the order in which supported data is processed. Entity Points apply only to counted Product, Customer, Order, and Blog Posts capacity.
Does a completed Full Migration mean the Target Store is ready?
No. Completion means processing has ended. Validation must still confirm that records, relationships, content, and business outcomes meet the acceptance criteria.
How does a Continue action work with Continue the previous migration?
A Continue action determines whether the next paid activity reuses or changes the previous configuration. Source Platform Options are separate controls: Continue the previous migration is for an applicable previous migration state, while Migrate only newly added entities limits supported processing to records added after the last successful run. A Migration Action does not automatically select either source window.
What happens when a running migration is stopped?
Stopping prevents further processing but does not roll back records already written or restore data already removed by an approved operation. When the stopped execution state remains available, resuming it continues that same activity rather than creating a new Migration Action. If later recovery depends on previous migration state, Continue the previous migration may apply as a separate Source Platform Option. Newly added records are a different source-window decision handled by Migrate only newly added entities when that supported behavior matches the intended scope.
Can a migration continue after the browser is closed?
It depends on how the migration is executed. A browser-dependent Full Migration requires its active browser page to remain open; closing or leaving that page pauses processing. A Full Migration configured for background execution can continue after the browser closes or the computer is turned off. Demo Migration uses browser-dependent execution rather than background execution.