How to deduplicate before, during and after a CRM migration

A CRM migration brings records from systems that never checked each other into one database. Duplicates in each source move too, and new ones form wherever the same customer exists on both sides. The safest order is to clean each source first, agree on the field that identifies each record, and check again once the data lands. If you've already migrated and the new CRM is full of duplicates, you can still fix it with a few extra precautions. In this post, you'll see why migrations create duplicates, what to do at each stage, and how to merge two CRMs after an acquisition.

Why CRM migrations create duplicates

Every migration is different, but a few situations come up in most of the ones I've seen:

• Two systems that never checked each other: a customer in both the old CRM and the new one arrives twice, once from each side.
• Different IDs: every system has its own record IDs, so the old ID means nothing to the new CRM. Without a shared key, the import can't tell two records belong to one customer.
• Field mapping: an email in a secondary field, a phone in another format, or a split company name stops matching once mapped.
• Imports without an identifying field: rows with no email, domain or ID usually become new records instead of updating existing ones.
• Duplicates already in the source: whatever the old CRM held, the new one inherits.

Built-in deduplication also behaves differently on bulk loads. In one CRM, duplicate rules show no alert on imports and API loads, and matching rows just aren't saved, so check what was rejected after each load. In another, import rows with no email, domain or record ID become new records, and companies created through the API aren't checked by domain.

As of October 2026, from Salesforce Help: Duplicate rules and HubSpot's knowledge base: Deduplication of records.

Clean the data before you move it

Cleaning in the old system is easier than cleaning in the new one. Nothing in the new CRM depends on those records yet, and no workflows, sequences or reports run on them.

Deduplicate each source on its own first

Clean inside each system before you compare them. If a customer appears three times in the old CRM and twice in the new one, merge each side first. Then you're matching one record against one.

Then match the two systems against each other

Export both systems and match them on the fields you trust most. Email for people and website domain for companies are common starting points. Phone, name with company, and address help when those are missing.

Merge the matches you're most certain of first. Review near matches, such as the same name at the same company with a different email, before deciding.

Decide which value wins

When the same customer exists in both systems, each record holds part of the truth. Decide per field which wins: the newest value, the most complete one, or the one from the system you trust there.

Owner, lifecycle stage and email opt-out deserve the most attention. A wrong owner starts a commission dispute, and a lost opt-out means emailing someone who asked you to stop.

Leave behind what you don't need

Test records, bounced contacts and companies with no activity in years don't have to move. Every record you leave behind is one fewer to match. Keep an archive export in case someone asks for them later.

Agree on the field that identifies each record

Before the first import, agree on the field that says "this is the same record" for each object. Your imports, integrations and forms should all use it.

Carry the old system's record ID into a field on every migrated record, whatever the object. It's your link back to the source once the record has a new ID. It also lets a second import update records instead of creating new ones.

Keep duplicates out during the move

Most duplicates that form during a migration come from the same record arriving more than once. These principles help:

• Load a test batch first, then look for duplicates in the new CRM before loading the rest.
• Import in order: companies before people, and people before deals, so each record links to one that already exists.
• Keep a list of the forms, syncs and integrations that write to the new CRM during the cutover.
• Run every import on the field you agreed on, so a second pass updates records.
• Avoid two-way syncs between the old and new CRM unless you've decided which side owns each field.

Merging two CRMs after an acquisition

Bringing two companies' CRMs together adds problems a single migration doesn't have. Both sides hold real, active records for the same customers, often with different owners and different histories.

• Decide which system is the source of truth for each object, or for each field.
• Agree on ownership before merging, including which rep keeps an account both teams worked.
• Keep regional offices and subsidiaries apart when they share a name or a domain. A broad match on name can merge them into one record.
• Map the two sets of stages, picklist values and naming conventions before you match.

These are business decisions as much as data ones. Get sales leadership to agree on ownership before the first merge.

If you already migrated with duplicates

Teams often find the duplicates weeks after go-live, when reports count customers twice or two reps call the same person. The data can be fixed. The difference is that the new CRM is live now, so every merge touches running work.

Find what's still creating them

Look for a sync still running from the old system, an import repeated by mistake, or a form that skips the field you agreed on. Knowing these sources tells you which new records to watch.

You can clean while they keep running. Merge the backlog in stages, and merge new duplicates automatically as they come in.

Find them by where they came from

Migrated records usually share a creation date or an import batch. Searching on the old system's ID or the import date narrows the work to the records most likely to be duplicated.

Check what depends on record IDs

Merging can change record IDs. In one CRM, the merged record gets a new ID. In another, the surviving record keeps its ID and the others go to the Recycle Bin for 15 days.

Any integration, report or spreadsheet that stores IDs needs updating after a large merge.

As of October 2026, from HubSpot's knowledge base: Merge records, and Salesforce Help: Account merge considerations and Recycle Bin.

Merge in stages

Start with the duplicates you're surest of, such as the same email or the same old record ID. Keep the original values before each round, since merges in many CRMs can't be undone.

As of October 2026, from HubSpot's knowledge base: Merge records, and Pipedrive's support center: Merge duplicates.

Plan deduplication into the migration

Migration duplicates come from each source and from customers who exist on both sides, so deduplication deserves its own time in the plan. Clean sources and one agreed field for identifying each record do most of the work before the first import.

If the new CRM already holds duplicates, the same principles apply to live data. You find them by where they came from, check what depends on record IDs, and merge in stages while the sources keep running.

Frequently asked questions