A CRM migration can carry duplicate records into a new system with cleaner field names and the same underlying confusion. One person becomes several contacts. Two businesses with similar names become one account. Activities land on the wrong record because cleanup changed the identifier after the migration mapping was built.
Deduplication needs its own plan before cutover. The goal is a defensible identity map, not the smallest possible export. This guide uses HubSpot's documented matching and merge behavior to explain what to check. The workflow recommendations also help when HubSpot is the source of a move to another CRM.
Separate formatting cleanup from identity decisions
Trimming whitespace and agreeing a country format are different jobs from deciding whether two records represent the same person. Keep normalized comparison fields beside the original values. That lets reviewers compare records without losing what the source actually held.
Write matching rules for each object separately. For contacts, an email can be useful evidence, but a name alone should only open a review. For companies, decide how subsidiaries, parent companies and shared domains should be represented. These are operating decisions for your business, not decisions an AI model should make silently.
Give uncertain cases an explicit status. A record can be a confirmed duplicate, confirmed separate entity or unresolved pair. Do not force the last category into a merge just because the migration date is approaching. Assign an owner and keep the reason visible.
Export a baseline with source identifiers
Before editing records, retain a raw extract with Record IDs and the fields used for matching. Preserve a separate representation of the relationships and activities needed for the move. Record the extract time and the selection rules. A spreadsheet of names and email addresses is not enough to reconstruct the migration identity map.
Create a cleanup log that links each original ID to the approved post-cleanup identity. Include the decision, reviewer and reason. If the target already contains data, add its identifier in a separate column. Never replace a source identifier with a target identifier just because both fields are labelled ID.
| Decision | Evidence to inspect | Output to retain |
|---|---|---|
| Same person | Email, identity context and associated work | Original IDs and approved contact mapping |
| Same company | Domain, business identity and account structure | Company mapping and relationship decision |
| Conflicting property | Source, recency and field ownership | Chosen value and reason |
| Uncertain pair | Missing or contradictory evidence | Review owner and blocked merge status |
Understand HubSpot import matching
HubSpot documents automatic contact deduplication using email and company deduplication using company domain names. Its import behavior also supports Record ID and custom properties that require unique values. Choose the intended matching key explicitly instead of assuming that every import follows the same rule.
For example, HubSpot states that an imported contact with a matching email updates the existing contact rather than creating another one. Only mapped properties are updated. For companies, a custom unique value property can be selected instead of domain matching. Check the exact mapping in your test import before relying on it for the full load.
A particularly important exception is the blank identifier. When a HubSpot import includes a Record ID column, rows without a value in that column create new records. Separate create rows from update rows and reject unexpected blanks before the file reaches the importer.
Review duplicate suggestions before merging
HubSpot's duplicates manager compares multiple contact and company properties to surface potential matches. Tool access and bulk actions depend on the account's subscription and permissions. Confirm availability in the account that will do the work rather than planning around a screen your operator cannot access.
Treat a suggestion as a candidate for review. Inspect the properties, associated records and business context before merging. Decide which properties should survive, especially where ownership or relationship context differs. A high similarity score is not an instruction to erase the distinction between two legitimate accounts.
Check what happens to IDs and history
HubSpot documents default merge behavior that creates a new Record ID, alongside a public beta that preserves the primary record's ID. Check which behavior your account uses. After each test merge, read the actual resulting identifier and the Merged record IDs property instead of trusting the identifier you expected to survive.
The merge documentation describes combined activities, associations and property history, with object-specific exceptions. It also notes that property value timestamps changed by a merge show the merge time rather than the original source timestamp. These details matter if the migration uses modified times to select changed records.
Refresh your mapping after cleanup. Every note, activity and relationship selected for migration should resolve through the approved source identity map. If an old ID no longer resolves the way the migration expects, stop and repair the mapping before loading related data.
Choose field values deliberately
A rule such as newest wins is easy to automate but can select the wrong business value. Assign authority by field. A verified address, a salesperson's ownership decision and a contact preference need different review rules. Preserve unresolved conflicts rather than filling the target with a value nobody approved.
Check contact preferences and exclusions independently from ordinary profile fields. Do not turn a cleanup operation into a new outreach audience. Record the intended treatment with the destination system owner so a later import cannot quietly undo the decision.
Validate the cleaned migration extract
- Reconcile the raw record count with approved merges, exclusions and unresolved records.
- Check that every selected source record has a destination decision.
- Load a representative test containing duplicates and conflicting properties.
- Verify activities and associations against the resulting identity map.
- Repeat the same test import and confirm that updates do not create new records.
- Review changed records after cleanup before preparing the final delta.
Counts alone will not catch a note attached to the wrong person. Ask record owners to inspect examples they recognize. Include a parent company, a person with several email addresses and an account with active work. Record the expected result before the test so the importer is checked against a decision, not against its own output.
Mistakes to avoid
- Merging on name alone to make an export smaller.
- Discarding source IDs after cleaning a spreadsheet.
- Assuming every account preserves the primary ID after a merge.
- Using blank update identifiers without treating them as exceptions.
- Testing contact counts but not their associated work.
- Letting later imports overwrite approved contact preferences.
How Remqa prepares CRM data for migration
Remqa handles CRM migrations and the data migration work around them. Start with a sample export, the target object model and a few disputed duplicate pairs. We can define matching rules, build the ID map and test the load before cutover. The broader CRM migration checklist covers the surrounding scope and handoff decisions.