A purchased Next-Cart Migration can require more than one migration activity. The Source Store may continue receiving Orders, Customers, Products, or content. Validation may show that a mapping or filter should change. An earlier target result may also need to be replaced rather than extended.
Migration Actions answer the project-level question: how should the next migration activity relate to the result and configuration that already exist?
The three concepts are:
- Perform a New Migration
- Continue the Migration with Last Saved Configuration
- Continue the Migration with a New Configuration
The difference is not simply whether another migration can run. Each action changes what is carried forward, what must be reconsidered, and what evidence is needed before the next result can be accepted.
Start With the Result That Should Exist After the Next Activity
The most reliable action choice begins with the desired target state rather than with the easiest available path.
| Project intent | Migration Action | What remains the basis of the next activity |
|---|---|---|
| Replace the earlier migrated basis with a distinct fresh result | Perform a New Migration | The project starts a fresh migration cycle rather than treating the earlier result as the basis |
| Preserve the earlier result and reuse the accepted setup | Continue the Migration with Last Saved Configuration | The most recently saved configuration remains the operating assumption |
| Preserve useful earlier work but change supported configuration | Continue the Migration with a New Configuration | Earlier work remains relevant, but configuration is reopened for deliberate changes |
Before a paid Migration has produced an earlier result, Perform a New Migration is the applicable concept because there is no saved paid configuration to continue. After migration history exists, the choice depends on whether the previous result and its assumptions should remain authoritative.
Perform a New Migration When the Earlier Result Should No Longer Be the Basis
Perform a New Migration fits when the project needs a distinct fresh migration result.
Typical reasons include:
- an earlier migrated result was created for testing and should be replaced;
- the approved scope changed substantially;
- validation found coordinated defects that make continuation unreliable;
- the project needs to reconsider data selection, configuration, and target preparation from the beginning;
- the earlier target result should not determine how the next result is built.
A fresh migration is a project decision, not a blanket deletion instruction. Target clearing, replacement scope, manually created records, application-created records, and other protected data still require their own decisions.
Entity Points history also remains independent. Performing a new migration does not make an already successfully migrated counted record new again. Within the same purchased Migration and fixed Migration Path, a counted record that already migrated successfully does not consume Entity Points again merely because another Migration Action processes it.
Continue With the Last Saved Configuration Only When Its Assumptions Still Hold
Continue the Migration with Last Saved Configuration is appropriate when the previous result remains useful and the accepted configuration still describes the intended next outcome.
This action avoids unnecessary reconfiguration, but it depends on a strong assumption: nothing material has changed in the rules that produced the accepted result.
Before relying on the last saved configuration, confirm that:
- selected data types are still appropriate;
- mappings still represent the intended business meaning;
- filtering rules still describe the intended record scope;
- Add-on settings remain suitable;
- approved Custom Migration behavior still applies;
- Source and Target structures have not changed in a way that alters the expected result;
- earlier validation did not leave an unresolved configuration defect.
The value of this action is continuity. The risk is carrying forward a configuration that is familiar but no longer correct.
Continue With a New Configuration When the Result Still Matters but the Rules Must Change
Continue the Migration with a New Configuration fits when earlier migration work remains useful but the next activity needs different supported settings.
Examples include:
- adding or removing supported data types;
- changing a filter;
- revising Attribute Mapping;
- changing an Add-on configuration;
- correcting a configuration issue discovered during validation;
- adapting the next activity to a changed launch scope.
The central advantage is controlled adaptation. The project preserves useful prior work without pretending that the old configuration remains valid.
The main risk is coexistence. Records produced under the earlier configuration can remain beside records produced under the revised configuration. Validation should therefore examine both the newly processed records and the combined Target Store state. A revised Customer Group mapping, for example, should be checked across Customers migrated under both configurations rather than only against the newest records.
Keep Migration Actions Separate From Source Platform Options
The three Migration Actions control the project-level relationship to the previous result and configuration. They do not by themselves define which Source records the next activity should read.
Source Platform Options handle that source-data window separately. Continue the previous migration is used when the activity should continue from applicable previous migration state, such as a verified interruption point. Migrate only newly added entities is the distinct option for a supported source window limited to records added after the last successful run; existing records are not included merely because their values were updated.
For example, if new Orders were added after the last successful run and the intended scope is only those additions, the relevant source-window control is Migrate only newly added entities. If an earlier activity stopped and the project must continue from the verified previous state, Continue the previous migration addresses that recovery boundary instead. The Migration Action is still chosen separately according to whether the previous configuration should be reused, revised, or replaced.
This is also different from Entity Points counting. Entity Points depend on whether a counted record already migrated successfully within the same purchased Migration and fixed Migration Path, regardless of which later Migration Action or Source Platform Option processes it.
Apply Entity Points Independently From the Action Choice
Migration Actions do not reset Entity Points history.
| Counted-record situation | Entity Points effect |
|---|---|
| Eligible record migrates successfully for the first time | Consumes Entity Points according to its locked weight |
| The same counted record is processed again after it already migrated successfully under the same purchased Migration and fixed Migration Path | Does not consume the weight again |
| A genuinely new eligible counted record is migrated later | Consumes Entity Points when it succeeds for the first time |
This rule applies to all three Migration Actions. The action determines how the next migration activity relates to prior work. Prior successful migration within the same purchased Migration and fixed Migration Path determines whether counted capacity has already been consumed.
That distinction matters when the Source Store remains active. Remaining Entity Points capacity should be planned around genuine new Products, Customers, Orders, and Blog Posts, not around the assumption that every later action recounts the entire source.
Keep Commercial Changes Separate From Migration Actions
Migration Actions are execution choices inside the purchased Migration. Upgrades and extensions are commercial changes.
- an Upgrade can add capacity, move to an eligible higher Migration Service, or add supported scope without deciding which Migration Action should be used next;
- an Extend order renews an expired Migration and restores eligible access without changing the fixed Migration Path;
- neither commercial action automatically selects a Migration Action.
For example, purchasing more Entity Points increases available counted capacity but does not decide whether the next migration should reuse the last saved configuration, reopen configuration, or start a fresh migration cycle.
Match Validation to the Action's Purpose
Every Migration Action requires validation, but the evidence should match the reason the action was selected.
| Migration Action | Primary validation question |
|---|---|
| Continue the Migration with Last Saved Configuration | Did the accepted configuration remain valid, and did the next result preserve the expected continuity? |
| Continue the Migration with a New Configuration | Did the revised settings produce the intended result without creating inconsistency with earlier migrated records? |
| Perform a New Migration | Does the fresh result reflect the approved scope, replacement boundaries, and target expectations without relying on an earlier result that should have been retired? |
Completion proves processing state, not business correctness. Representative Products, Customers, Orders, relationships, mapped values, Add-on outputs, URLs, and custom-scoped data should be rechecked according to what the action changed.
Use a Decision Sequence Instead of Treating the Actions as Synonyms
A practical decision sequence is:
- Decide whether the earlier migrated result should remain useful.
- If it should not, use Perform a New Migration.
- If it should remain useful, decide whether the last saved configuration is still correct.
- If the configuration is still correct, use Continue the Migration with Last Saved Configuration.
- If the result remains useful but the configuration must change, use Continue the Migration with a New Configuration.
- Define the source-data window separately. Use Continue the previous migration only for applicable previous migration state, or Migrate only newly added entities only when the intended scope is records added after the last successful run.
- Confirm Entity Points capacity and revalidate the result according to the action and source-window purpose.
This sequence prevents two common errors: using a fresh migration when only configuration needs to change, and reusing a saved configuration after its assumptions have stopped being true.
Conclusion
Next-Cart Migration Actions represent three different relationships to earlier migration work. Perform a New Migration starts a fresh migration cycle when the earlier result should no longer be the basis. Continue the Migration with Last Saved Configuration preserves continuity when the accepted setup is still correct. Continue the Migration with a New Configuration preserves useful prior work while deliberately changing supported configuration.
The strongest action choice is based on the intended next result, not convenience. Entity Points history, Source Platform Options such as Continue the previous migration and Migrate only newly added entities, upgrades, extensions, and validation remain separate decisions that interact with the selected action without redefining it.
Common Questions
When should Perform a New Migration be used?
Use it when the project needs a distinct fresh migration result and the earlier migrated result should no longer be the basis for the next cycle.
When should the last saved configuration be reused?
Use Continue the Migration with Last Saved Configuration when the previous result remains useful and the accepted data selection, mappings, filters, Add-ons, custom behavior, and target assumptions are still correct.
When is a new configuration more appropriate?
Use Continue the Migration with a New Configuration when earlier work remains useful but supported configuration must change before the next activity.
Does Perform a New Migration reset Entity Points history?
No. A counted record that already migrated successfully within the same purchased Migration and fixed Migration Path does not consume its Entity Points weight again merely because another Migration Action processes it.
Do the Continue actions automatically process only newly added records?
No. Migration Actions and Source Platform Options solve different problems. A Continue action does not automatically select a newly-added-only window. When the intended supported scope is limited to records added after the last successful run, use Migrate only newly added entities; use Continue the previous migration only when the activity should continue from applicable previous migration state.
If new Orders were added after the last migration, what concept matters?
First choose the Migration Action based on whether the previous configuration should be reused, revised, or replaced. If the intended source window is only Orders added after the last successful run, Migrate only newly added entities is the separate source-reading control. Continue the previous migration applies instead when processing must continue from an applicable previous migration state.
Does an Upgrade or Extend order choose the next Migration Action?
No. Upgrade and Extend are commercial changes. The Migration Action is still chosen according to the intended relationship between the next result, the previous result, and the saved configuration.
Do later Migration Actions require validation again?
Yes. Every later action changes the evidence set. Validation should focus on the records, configuration, relationships, replacement boundaries, and business outcomes affected by that action.