Within Next-Cart Migration Services, Additional Migration Options support projects that continue after the first broad result. The Source Store may remain active while the Target Store is reviewed. New Orders and Customers may appear. Validation may reveal that a mapping or filter should change. A test result may need to be replaced before launch.
These situations look similar because each requires more migration activity. Their intended outcomes are different. One preserves continuity with a trusted configuration. Another continues the project but changes the configuration. A third creates a distinct fresh migration result.
Next-Cart Additional Migration Options should therefore be selected from intent, not convenience. The wrong choice can reuse assumptions that are no longer valid, replace a result that should have been preserved, or create false expectations about which source records will be read.
Define the Next Result Before Choosing the Action
The first question is not “Which option is available?” It is “What should remain true after the next migration activity?”
Three intents should be distinguished:
- Continuity: the previous result remains useful, and the same configuration should continue.
- Controlled change: the previous result remains useful, but filters, mappings, selected data types, Add-ons, or other configuration should change.
- Fresh result: the earlier migrated result should no longer be the basis of the project.
These intents correspond to three exact actions:
| Intended result | Migration action | Central implication |
|---|---|---|
| Continue from a trusted setup | Continue the Migration with the Last Used Configuration | The recorded configuration is reused |
| Continue while changing the setup | Continue the Migration with a New Configuration | Configuration is reviewed or revised before execution |
| Produce a distinct fresh result | Perform a New Migration | Earlier migration activity is not treated as the basis for the new result |
A first migration has no recorded configuration to reuse. Later action availability depends on applicable migration history and an active service duration. If the one-year duration has expired, the migration must be extended before an eligible later action can be performed.
Reuse the Last Configuration Only When Its Assumptions Still Hold
Continue the Migration with the Last Used Configuration is appropriate when the earlier configuration remains valid and the previous Target Store result is still useful.
This action can reduce repeated decision work, but its efficiency depends on a strong assumption: the last configuration still represents the intended outcome.
Before reusing it, confirm that:
- selected data types remain appropriate;
- mapping decisions still fit the target;
- filtering rules still describe the intended record scope;
- Add-on configuration remains suitable;
- source and target structures have not changed in a meaningful way;
- the previous validation did not reveal an unresolved configuration defect;
- the intended source-record window is still correct.
Reusing a configuration because it worked once is not enough. The project context may have changed. A new source field, revised target structure, or different launch scope can make the earlier setup inappropriate even when the migration path is unchanged.
The validation after this action should prove both continuity and change. The existing Target Store result should remain usable, and the newly processed records should follow the same accepted rules.
Continue With a New Configuration When the Goal Has Changed
Continue the Migration with a New Configuration fits when earlier migration activity remains useful but the next execution needs different supported settings.
Typical reasons include:
- filtering must include or exclude a different record set;
- standard mappings need revision;
- selected data types have changed;
- an Add-on must use different settings;
- validation exposed a configuration issue;
- the next project stage has a different scope;
- target expectations changed without requiring a completely fresh result.
The central advantage is controlled adaptation. The project can preserve useful prior work while changing the decisions that govern the next activity.
The risk is unintended coexistence. Records produced under the earlier configuration may remain alongside records produced under the new one. Validation should therefore examine whether the two configurations create duplication, conflicting mappings, inconsistent field use, or different business meaning.
For example, changing a Customer-group mapping should prompt review of Customers migrated under both configurations. The question is not only whether the new mapping worked. It is whether the combined Target Store remains coherent.
Perform a New Migration When the Earlier Result Should Not Continue
Perform a New Migration is appropriate when the project needs a distinct fresh migration result rather than a continuation of earlier work.
This may be justified when:
- the earlier migrated result was created for testing;
- the previous configuration no longer reflects the intended scope;
- validation found coordinated defects that make continuation unreliable;
- target preparation requires a clean migration basis;
- the project wants to reconsider scope and configuration from the beginning.
A new migration should be chosen because the result needs to be fresh, not merely because another execution is possible.
Replacement and clearing decisions require care. This action can affect records previously created by migration within the selected scope, but it does not by itself authorize removal of every Target Store record. Manually created records, application-created records, test records, and operational data should be identified before any clearing or replacement decision.
The validation standard should be broader than for continuation. The project should confirm the fresh configuration, the resulting data set, the treatment of earlier migrated records, and the protection of records outside the approved replacement scope.
Separate the Migration Action From the Source-Record Window
The three actions determine the relationship to the earlier configuration and result. They do not independently determine which source records are read.
Source-reading behavior answers a different question:
- should interrupted processing resume from the point already reached;
- should only records added after the last successful migration be read;
- should the selected source scope be read again under the chosen configuration.
This distinction prevents a common mistake. Continuing with the last configuration does not automatically mean that only newly added records will be processed. Perform a New Migration does not automatically define how the source window is selected.
An existing record updated after the previous activity is also different from a newly added record. If changed existing records need to be reconsidered, the source-reading and configuration decisions should state that requirement explicitly.
The action and source-record window should be planned together, but they should not be treated as one setting.
Apply Entity Points by Record Status
Additional migration activity does not consume Entity Points merely because another action occurs. Consumption depends on the counted records involved.
| Counted record situation | Entity Points effect |
|---|---|
| Product, Customer, Order, or Blog Posts record is migrated successfully for the first time | Points are consumed using the applicable locked weight |
| The same counted record was already counted within the purchased migration and fixed path | It does not consume points again merely because another action processes it |
| A new eligible record is added and migrated later | Points are consumed when it is migrated successfully for the first time |
| A new migration includes previously counted eligible records | Those records do not consume points again |
This rule applies across all three actions. Perform a New Migration does not automatically recount every previously recorded Product, Customer, Order, and Blog Posts record.
Capacity planning should focus on genuine new counted data. If the Source Store remains active, expected Product, Customer, Order, and Blog Posts growth should be compared with the remaining Entity Points capacity before the next action.
Separate Migration Actions From Commercial Changes
An Additional Migration Option determines how the next migration activity relates to the earlier result. An upgrade changes the purchased package, and an extension restores an expired migration. These are related decisions, but they are not interchangeable.
For example, purchasing more Entity Points increases capacity but does not decide whether the next activity reuses the last configuration, changes the configuration, or produces a fresh result. Upgrading from Standard to Managed changes execution responsibility but does not choose the migration action. Extending an expired migration restores service from the latest retained package, after which the appropriate action still depends on the intended result.
Keeping these decisions separate prevents a commercial order from being mistaken for a migration instruction. It also preserves the fixed migration path: upgrades and extensions affect the same purchased migration rather than creating a different Source Platform-to-Target Platform direction.
Keep Migration Service Responsibility Visible
An Additional Migration Option does not replace the purchased Migration Service.
Under customer-led execution, the customer performs the selected action and validates the result. Under expert-led execution, the agreed action is performed within the accepted service scope, while the customer supplies required information and approves the outcome.
If the later activity introduces tailored requirements, the service scope may need to change. A new custom field, modified Add-on, or bespoke transformation should not be hidden inside a continuation action simply because the migration path already exists.
The project should therefore review two questions separately:
- Which action matches the intended relationship to the earlier result?
- Does the existing Migration Service still cover the required scope and execution responsibility?
Match Validation to the Purpose of the Action
Every action requires validation, but the evidence should reflect its intent.
| Action | Primary validation focus |
|---|---|
| Continue the Migration with the Last Used Configuration | The configuration remained valid, the intended source window was processed, and continuity was preserved |
| Continue the Migration with a New Configuration | The revised settings produced the intended result without creating inconsistency with earlier migrated records |
| Perform a New Migration | The fresh result reflects the approved scope, earlier migrated data was treated correctly, and protected Target Store records remain intact |
Representative review should include business-critical Products, Customers, Orders, Blog Posts, CMS Pages, Reviews, Coupons, URLs, filtered records, mapped values, Add-on outputs, and custom-scoped data where relevant.
The selected action is successful only when the Target Store supports the intended next business step. Action completion is not acceptance.
Avoid Intent Errors
Reusing configuration after the requirement changed
The last configuration may be familiar but no longer valid. Reuse should follow evidence that mappings, filters, Add-ons, and target expectations remain suitable.
Choosing a new migration when configuration adjustment is enough
A fresh result can create unnecessary replacement risk. If earlier work remains useful and only supported settings must change, continuing with a new configuration may be more precise.
Assuming continuation reads only new records
The action and source-record window are separate. The source-reading behavior must be planned explicitly.
Treating a new migration as permission to clear every Target Store record
Replacement must stay within the approved scope. Records created manually or by applications need separate protection and ownership decisions.
Skipping validation because the earlier result passed
New source records, changed configuration, and a fresh result each create new evidence requirements. Earlier acceptance cannot be transferred automatically.
Conclusion
Next-Cart Additional Migration Options represent three different project intents. Continue the Migration with the Last Used Configuration preserves continuity when the earlier setup remains valid. Continue the Migration with a New Configuration preserves useful prior work while allowing controlled change. Perform a New Migration creates a distinct fresh result when the earlier migration should no longer be the basis of the project.
The action should be coordinated with source-record selection, Entity Points capacity, Migration Service responsibility, replacement boundaries, and purpose-specific validation. Choosing from the intended outcome keeps later migration activity controlled and prevents an available action from becoming a substitute for project reasoning.
Common Questions
When should the last used configuration be reused?
Reuse it when the previous configuration, source-record intent, Add-ons, mappings, and target expectations remain valid.
When is a new configuration more suitable?
Use a new configuration when earlier migration work remains useful but filters, mappings, selected data types, Add-ons, or other supported settings must change.
When should a new migration be performed?
Use Perform a New Migration when the project needs a distinct fresh result and the earlier migrated result should no longer be the basis of the project.
Do continuation actions automatically read only newly added records?
No. The migration action and source-record window are separate decisions.
Do previously counted records consume Entity Points again?
No. Counted records already counted within the purchased migration and fixed path do not consume points again merely because another action processes them.
Does Perform a New Migration clear every Target Store record?
No. Clearing and replacement must follow the approved scope, with manually created, application-created, and other protected records identified separately.
Does an Additional Migration Option change the Migration Service?
No. A Migration Service upgrade is a separate commercial change. It can alter scope or execution responsibility, but it does not decide which Additional Migration Option fits the next result.
What must be validated after a later action?
Validation should confirm the intended source window, configuration behavior, Entity Points effect, treatment of earlier results, protected records, and business usability of the Target Store.