النسخة العربيةAR
Let’s talk

A good partnership starts with a conversation.

Customer relationship management

Agreeing on Duplicate Rules Before a CRM Migration

Deduplication is more than removing similar names. Before migrating CRM data, define identity, matching evidence, surviving field values and relationships, then test decisions on a sample and explicit exceptions.

5 min read
A customer-service professional using a headset and laptop and taking notes against a blue and yellow background

Similar names may belong to different people, while different names may represent the same person. A proposal line promising duplicate cleaning does not explain what gets merged, which value survives or who can explain a missing detail after migration.

Agree reviewable decision rules before moving customers into CRM. Distinguish identifying similarity from approving and executing a merge; each may require different data, permissions and tools. The goal is correct records with explainable relationships and history, rather than the smallest possible final count.

Define record type before matching

A fictional hospitality-supplies distributor has sales and accounting files. They contain a customer company, a contact and two opportunities for different branches. A duplicate person does not make the opportunities duplicates or establish that branches should share one account.

Define accounts, contacts, opportunities and branches for this project. Retain source identifiers and source-file or system references in the migration mapping. A changeable row number should not become permanent identity without agreement and verification.

A sample decision table

ObservationProposed review decisionApproval needed
Same old identifier in two filesVerify that type and source namespace are the same.Which version and fields should update?
Similar name, different contact detailsFlag for review rather than merge by name alone.Further evidence confirming or rejecting the match.
Shared phone numberCheck whether it identifies a company, reception or person.Keep independent records for different people.
One person linked to two companiesReview the relationships instead of deleting an account.A model supporting the required relationships.
Many empty identity fieldsSeparate incomplete cases or complete them through an agreed process.Do not treat blank values as proof of one identity.

These are proposed example decisions, not universal automation rules. Microsoft's documentation shows how criteria, record type and empty values affect detection. HubSpot documents identifiers and differences between imports and API creation. Test the actual entry route instead of assuming identical behaviour across methods.

Once matched, decide which information survives

Two confirmed records may disagree on job title, account owner or last-contact date. Define source precedence for important fields rather than letting the last file win. A recently produced file may repeat old information.

The distributor might rely on accounting for account identity and sales for current follow-up details. Identify who resolves conflicts, records reasons and retains references to prior records. File import order should not decide business-data ownership.

Test relationships beyond the contact card

Select a sample person with linked opportunities, notes and activities. After test-environment processing, inspect every relationship and its context. Confirm that deduplicating the person did not merge independent opportunities or move an activity to the wrong account.

Ask about attachments and fields absent from the new system. Are they migrated, transformed or retained outside scope under a recorded decision? A record count cannot establish historical completeness if users cannot find needed information.

Accept the sample before the large batch

Include a confirmed match, similar records that must remain separate, incomplete identity, conflicting values and multiple relationships. Record expected results before running a tool. The data owner reviews outcomes and adjusts rules, then retests the same sample and reasonable additional cases.

Request counts of created, updated, review-pending and excluded records with explained reasons and traceability to sources. A high success percentage is insufficient without its calculation and exclusions.

Agree rollback boundaries

Before real merging, request an explanation of the chosen product's rollback capabilities and limits, a suitable backup or export plan and before-and-after mappings. Some operations have no one-click reversal. Deleting an import result may not restore all previous values and associations.

Also agree edit-freeze or change-capture arrangements during transition and who approves using the new system. These are project decisions, not an instruction to stop business or delete live data for experimentation.

The CRM implementation proposal guide covers broader scope; the lead-routing guide covers follow-up ownership. When discussing CRM implementation with Nextwave, include identity definitions, a de-identified sample and expected decisions so migration pricing reflects understood work.

Sources and limits

HubSpot deduplication documentation, updated October 2026 and Microsoft duplicate-detection rules were opened on 3 November 2026. They establish differing mechanisms, not universal matching accuracy or reversible merging. The original example and worksheet were prepared with AI assistance and review of the content and sources.

FROM INSIGHT TO ACTION

Turn an idea into something that works.

Explore Nextwave software, business systems and application services for your next step.

Explore our services