Duplicate Data

Duplicate Data

Determine whether the target contains true duplicate records, an approved target-specific representation, duplicate source records, or the combined result of separate migration, import, integration, or manual activity. Establish record identity and creation history before deleting data or starting another migration activity.

Use this page when the same Product, Category, Customer, Order, Review, Coupon, CMS Page, Blog Post, or related record appears more than once in the intended target store.

Do not use target-data clearing as a generic deduplication method

Clear data on Target Store before Migration can permanently delete existing records for selected data types, including records not created by Next-Cart. Do not enable it, bulk-delete records, or remove related data until the duplicate set, protected records, relationship impact, and recovery method are documented.

Confirm that the result is a true duplicate

Observable result	What it usually means
One source identifier maps to two or more separate target records with the same business meaning	The target likely contains true duplicates that require activity and identity analysis.
Similar Products are actually variants, option combinations, translations, site-specific records, or target-required child records	The target data model may be representing one source concept through several approved records. This is not automatically a duplicate.
Two target Customers share an email or name, but two source Customer records also existed	The duplication may originate in the source and require an approved merge or coexistence decision.
The same record appears twice in a storefront list but only once in the target admin	Theme, search index, cache, sales-channel, or presentation behavior may be duplicating the display rather than the stored data.
Duplicates appeared after more than one migration activity	The selected migration action, source-reading options, earlier result, target state, or activity overlap may not have matched the intended result.
Duplicates appeared after a fresh migration result	Earlier migrated, manual, test, or application-created records may have remained in the affected target scope.
Only related records are duplicated	A parent record, relationship key, preserved identifier, mapping, or integration may be creating or associating more than one target representation.
Similar records exist in different target stores, sites, or languages	Confirm whether they are intentional environment or localization records before treating them as duplicates.

Preserve the evidence

Before changing the target store, record:

• the purchased service and fixed migration path;
• the target store, site, language, and environment;
• the affected data type and approximate duplicate scope;
• several duplicate sets with source identifiers and every corresponding target identifier;
• target creation and update times where available;
• the migration History entries that overlap those times;
• the migration action used for each relevant activity;
• whether Continue the previous migration or Migrate only newly added entities was enabled;
• whether Clear data on Target Store before Migration was enabled;
• any configuration changes between activities;
• manual imports, application synchronizations, bulk edits, or staff activity affecting the same records;
• protected target-only records and relationship dependencies;
• the expected single or approved multi-record target representation.

Use masked customer information where possible. Do not collect customer passwords, secret keys, payment-card data, or unrelated personal data.

Diagnose how the duplicates were created

1. Stop further writes to the affected scope when safe

   Pause avoidable imports, synchronizations, manual creation, and additional migration activity that could add more records. Do not interrupt a live business process without the project owner’s approved hold plan.

2. Match one source record to every target candidate

   Use stable identifiers such as source ID, SKU, email, Order number, coupon code, source URL, or an approved fallback field. Compare business meaning and relationships, not only names or titles.

3. Check whether the target representation is expected

   Determine whether the records represent variants, translations, store views, site-specific records, historical snapshots, or another target-model structure approved by the acceptance criteria. Stop the duplicate investigation when the representation is intentional and correct.

4. Compare the source for pre-existing duplicates

   Search the source using the same identifiers and fields. Confirm whether multiple source records existed, whether identifiers changed, or whether records were merged, recreated, or imported in the source before migration.

5. Build the target creation timeline

   Compare target creation times with Next-Cart History entries, manual imports, application activity, and staff changes. Classify each target record as earlier migrated, created by the relevant activity, manual, test, integration-created, or unknown.

6. Reconstruct the migration decisions

   For each relevant activity, identify whether the customer selected Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration, or Perform a New Migration. Review Continue the previous migration and Migrate only newly added entities separately because they control source reading rather than the migration action.

7. Review existing-target and replacement behavior

   Confirm which earlier migrated records should have remained, which records should have been replaced, and whether target-data clearing was intentionally enabled for the affected data types. Identify target records that were outside the approved replacement scope.

8. Check identifiers, mappings, and relationships

   Review preserved Customer or Order IDs where applicable, source-to-target identifier changes, Advanced Data Mapping or Advanced Database Mapping destinations, site or language mappings, and relationship keys. Confirm whether the duplicate records also created duplicate Categories, variants, Customers, Orders, Reviews, or other dependent relationships.

9. Classify the root cause before cleanup

   Record whether the issue is a target display problem, approved target representation, source duplicate, pre-existing target conflict, separate migration-result conflict, interrupted-state or source-window mismatch, mapping or identifier issue, external integration activity, manual creation, or an unexplained migration result.

Choose the correction by cause

Confirmed cause	Safest corrective path
Storefront or search displays one stored record more than once	Correct the target theme, index, cache, channel, or presentation condition. Do not delete the underlying record.
Multiple target records are an approved platform representation	Document the expected structure and validate relationships and usability. No deduplication is required.
Duplicate records already exist in the source	Define whether they must remain separate, merge, or be excluded. Correct the source or approved filtering strategy before future processing.
Manual, test, import, or integration records conflict with migrated records	Assign record ownership, pause the conflicting process, and use the target platform’s approved merge or cleanup method with a recovery plan.
Earlier migrated records remained when a fresh result was intended	Compare the selected action and replacement scope. Protect target-only records and obtain an approved cleanup or replacement plan before another migration activity.
The wrong migration action was selected	Do not choose another action solely to counteract the duplicates. First define the intended surviving result and cleanup responsibility, then use Compare Migration Action Options for future activity.
Continue the previous migration was used without a compatible interrupted state	Preserve the activity evidence and target timeline. Confirm the affected scope with support before processing more records.
Migrate only newly added entities did not match the intended source window	Correct the future source-reading plan. Investigate identifier or existing-target behavior for the current duplicates rather than assuming this option deletes or updates existing records.
Preserved or fallback identifiers conflict	Identify the authoritative target record, protected relationships, and approved identifier behavior before any merge, replacement, or removal.
Mapping or Customization creates more than one destination	Correct the applicable mapping, Advanced Data Mapping, Advanced Database Mapping, or approved Customization rule and test normal, boundary, and exception records.
The target contains unexplained duplicates associated with one migration activity	Submit a ticket before destructive cleanup. Include the complete duplicate set, source and target identifiers, activity evidence, configuration, and expected result.

Cleanup must preserve relationships

Removing a duplicate Product, Customer, Category, or Order can break variants, inventory, Reviews, addresses, Order history, URLs, or integration references. Use the target platform’s supported cleanup or merge process only after the authoritative record and every dependent relationship are known.

Verify the correction

Verification area	Pass condition
Record identity	Each sampled source record has one approved target representation, unless an accepted target-model rule requires more than one.
Authoritative record	The surviving target record is documented and searchable by the required identifier.
Relationships	Categories, variants, inventory, Customers, Orders, Reviews, URLs, and other dependencies point to the correct surviving record.
Historical integrity	Order history, dates, financial values, and historical snapshots remain intact.
Target-only data	Required manual, test, and application-created records were preserved or removed only as approved.
Presentation	Target admin, storefront, search, and channel views no longer show unexplained duplicate results.
Activity control	The next migration action and source-reading options match the intended result and source-data window.
Side effects	Cleanup did not create Missing Data, invalid redirects, broken references, or new duplicate records.

Repeat the same sample checks after cache refresh, indexing, synchronization, or target cleanup completes. Keep the issue open until the corrected target state remains stable through the relevant operating cycle.

Escalate before destructive or uncertain cleanup

Use Tickets when:

• the activity that created the duplicate set cannot be identified;
• a duplicate set includes Customers, Orders, financial history, preserved IDs, or complex Product relationships;
• the target platform has no safe supported merge or cleanup path;
• History and target evidence associate the same source identity with unexplained separate records from one migration action;
• cleaning one record could remove protected target-only data or break dependencies;
• repeated duplicates appear after a verified correction;
• Custom Service or platform-specific analysis is required.

Include the service, migration path, target environment, relevant History entries, actions and source-reading options, duplicate source and target identifiers, creation times, screenshots, relationship impact, expected surviving record, and recovery evidence. Do not send passwords, full secret keys, payment-card data, or unnecessary customer data.

Prevent additional duplicates

• classify existing target records before migration activity;
• decide whether the earlier result remains useful before selecting a migration action;
• review source-reading options independently from the action;
• do not combine a restricted source window with destructive target clearing without verifying the complete outcome;
• pause or coordinate imports, synchronizations, and manual creation that affect the same scope;
• preserve stable source-to-target identifiers and document fallback fields;
• test representative normal and edge-case records after configuration changes;
• validate the affected scope immediately after each approved migration activity;
• keep a target backup, export, snapshot, or other approved recovery method before cleanup.

Next step

After the duplicate set is corrected, use Validate Results After a Migration Action to confirm the intended result and unchanged scope.

When cleanup causes absent records or broken relationships, return to Missing Data and classify the affected scope before further activity.