CRM Data Cleaning Before Migration: What 'Clean Enough' Actually Means

“Clean enough” gets treated as a vague, subjective standard, which is exactly what makes data cleaning easy to skip or half-finish before a migration. It doesn’t need to be vague. Clean enough for migration means three specific things, each checkable: duplicate records identified and resolved at the source, picklist and dropdown values standardized to a single spelling per value, and every field your reporting depends on sitting above a completeness threshold your team has explicitly agreed is acceptable. Nothing more, and nothing less — a genuinely spotless database doesn’t exist at any real company, and chasing one delays a migration without proportional benefit.

This guide covers the mechanics of getting to that bar, as a companion to the broader CRM migration guide, which covers the migration project end to end. If you haven’t yet decided whether a migration is the right move at all — versus remediating your current platform — that guide’s opening section is worth reading first.

Why cleaning has to happen before export, not after

Data migration typically runs 15-35% of total implementation budget depending on destination platform, and dirty source data is the single biggest reason that percentage lands at the high end rather than the low end. The reasoning for cleaning before export rather than after is practical, not just tidy: your de-duplication tools, your team’s familiarity with the data, and your intuition for what “looks wrong” are all stronger in the system you’ve used for years than in a platform you’re still learning. A duplicate that’s obvious to a rep who’s worked with that account for two years in the old CRM is much less obvious once it’s an unfamiliar record ID in a new interface.

Duplicates that migrate over don’t just sit there quietly, either. They compound — automations fire twice, one for each copy of a contact; reports double-count revenue or activity; reps update the wrong copy of a record and wonder why their change didn’t stick. The cost of an unresolved duplicate goes up, not down, once it’s live in a new system that’s still being trusted and adopted.

Third-party data-quality research puts a number on that compounding effect. A 2026 analysis from Cleanlist and a separate estimate from Verum both put the direct, per-record cost of a bad contact record — wasted sends, enrichment fees, a rep’s time chasing a dead lead — at roughly $10 to $100, with the wide range reflecting how much lost productivity and missed pipeline gets counted alongside the obvious costs. Gartner-cited research aggregated by Landbase puts the annual organization-wide cost of poor B2B data quality at $12.9 million on average across the companies it studied — a figure that’s mostly relevant to enterprises, but the per-record math scales down cleanly to a smaller database.

Step 1: Quantify the problem before you start fixing it

Before any cleanup work begins, run a structured audit: pull a random sample of 200-500 records (more for very large databases) and manually check for duplicates, inconsistent picklist values, and missing data in fields your reports depend on. Extrapolate the sample rate to your full database to get real numbers — “roughly 30% of contacts are duplicates” and “40% of deals are missing a close date” are actionable; “our data’s kind of messy” is not.

This audit is also the moment to decide, explicitly, what “clean enough” means for your specific migration. Write down: the acceptable duplicate rate after cleanup (zero is unrealistic; a low single-digit percentage caught by ongoing hygiene processes is a reasonable target), which fields are report-critical and need a high completeness bar, and which fields are lower priority and can tolerate more gaps. This document becomes the checklist you validate against before go-live, rather than a subjective judgment call at the end.

Step 2: Define your duplicate-matching rule before you deduplicate

“Duplicate” needs a definition before cleanup starts, or different people doing the work will apply inconsistent judgment. For contacts, a common rule is: same email address (exact match, always a duplicate), plus a secondary check on name and company for records that don’t share an email but look similar. For companies, matching on domain name and normalized company name (stripping “Inc,” “LLC,” punctuation differences) catches most cases; manual review handles the genuine edge cases — two people who happen to work at companies with very similar names, or a company that legitimately has separate divisions tracked as separate accounts on purpose.

Automated de-duplication tools handle the obvious, high-confidence matches well and should be your first pass. The remaining ambiguous cases — the ones the tool flags as “possible” rather than “certain” matches — need a human to actually look at both records and decide. Budget real time for this manual review step; it’s usually a smaller volume of records than the automated pass handles, but it’s the part that actually requires judgment rather than pattern matching.

A concrete example of the kind of case that needs a human: two contact records for “Mike Chen,” same company domain, different job titles, one with a phone number and one without. That could be one person whose title changed and who has a duplicate lingering from before an update, or it could be two different people who share a common name at a mid-size company. An automated tool sees two similar strings and flags a possible match; only someone who can check the deal history, the email thread, or just ask the account owner can actually resolve it. Multiply that one case by a few hundred similar judgment calls in a database with real tenure, and it becomes clear why this step needs a person with context, not a lower confidence threshold on the matching algorithm.

How do native de-duplication tools compare across platforms?

They compare unevenly, and knowing where your source (or destination) platform’s tool falls short changes how much manual review time you need to budget. None of the major CRMs auto-merge duplicates without a human confirming the merge — that safeguard exists everywhere for good reason — but how much work the tool does before it hands you a confirmation screen varies a lot.

HubSpot’s Manage Duplicates tool, available on Professional and Enterprise tiers, scans the whole database once a day and compares contact records on first name, last name, email, phone, zip code, and company name, then ranks likely pairs by a confidence score for review. The catch is that it isn’t real time: a duplicate created by a form submission or a CSV import this morning won’t show up in the duplicates queue until the next scan cycle, which means a manual spot-check right after any bulk import is still worth doing rather than trusting the tool to catch it immediately.

Salesforce splits the job into two separate configuration layers — Matching Rules, which define what counts as a match (exact match on email, fuzzy match on account name, and so on), and Duplicate Rules, which define what happens when a match is found (block, alert, or allow with a warning). Out of the box, Salesforce ships three standard matching rules covering Accounts, Contacts, and Leads, which catches the common cases, but any variation outside those default rules — a different field combination, a custom object — needs a rule built by an admin. That’s more configurable than HubSpot’s approach, but the configuration burden falls entirely on your team rather than being handled by an out-of-the-box scan.

Pipedrive takes the most proactive approach among the platforms aibrevo migrates into and out of most often: it warns you at the point of entry, when you’re adding a new person or organization, if a likely duplicate already exists — closer to a guardrail than a cleanup tool, since it’s aimed at preventing new duplicates rather than surfacing the ones already in your database. It doesn’t replace a dedicated audit of existing records; it just makes new ones less likely once you’ve cleaned up the backlog.

What this means practically: if your source system is HubSpot, run a manual duplicates-manager pass and wait a full scan cycle before you consider the database clean, since yesterday’s imports won’t be flagged yet. If it’s Salesforce, check which matching rules actually exist in your org before assuming duplicates are being caught — a lot of Salesforce orgs run for years on only the three default rules and accumulate duplicates in exactly the field combinations those rules don’t cover. And regardless of platform, none of these tools replace the manual review pass on ambiguous cases described above — they narrow the queue, they don’t clear it.

What happens when two duplicate records disagree on data?

This is the case the matching rule doesn’t resolve for you: you’ve confirmed two records are the same person or company, but they don’t agree on every field — one has a phone number and the other doesn’t, one shows a job title from two years ago and the other is current, one has three logged activities and the other has twelve. Merging isn’t just clicking “combine”; it’s deciding, field by field, which value survives.

A few practical rules make this faster and more consistent across a team doing bulk cleanup:

• Most recently updated wins for point-in-time fields. Job title, company size, and similar fields that change over time should default to whichever record was updated more recently, not whichever record happens to be “primary” by some other rule.
• Non-empty beats empty, always. If one record has a phone number and the other field is blank, keep the phone number — this sounds obvious, but naive automated merges sometimes default to the “primary” record’s value even when it’s blank and the “secondary” record’s value is populated.
• Activity history should combine, not overwrite. Logged calls, emails, and notes from both records need to merge into one combined history, not get discarded from whichever record is treated as the duplicate. Losing activity history in a merge is one of the more common complaints from reps after a cleanup pass, because it erases the context they relied on.
• Ownership goes to whoever has the active relationship, not automatically to whichever record was created first. A record created five years ago by a rep who’s since left, merged with a newer record actively owned by the current account manager, should end up owned by the current account manager — not silently reassigned back to the older record’s owner just because it was “primary.”

Most native merge tools let you pick the surviving value field by field during the merge, which is the right level of control — the mistake is rushing through that screen on autopilot and accepting whatever the tool defaults to, rather than actually checking each field for a case where the non-primary record has the better data.

Step 3: Standardize picklist and dropdown values

Inconsistent picklist values are a quieter problem than duplicates because they don’t announce themselves — a workflow or report filtering on “Enterprise” simply won’t catch records tagged “enterprise” or “ENT,” and nothing throws an error to tell you records got silently excluded. Before migration, pull a distinct-values report on every picklist and dropdown field and look for near-duplicate values that should be one value: capitalization differences, abbreviations, trailing whitespace, and genuinely inconsistent terminology from different eras of data entry all show up here.

Standardize to one canonical value per option, update existing records to match, and — if your source system allows it — lock the field down to a defined picklist going forward rather than leaving it as free text, so the problem doesn’t recur immediately after migration.

Step 4: Map fields deliberately, not automatically

Every CRM structures data slightly differently, and a field-by-field mapping decision needs to be made for each source field: does it map directly to an equivalent destination field, does it need a format change or value normalization along the way, does it get combined with another field, or does it get intentionally dropped because it has no meaningful destination? A field-mapping document with a row per source field — destination field, transformation needed, decision owner, and status (mapped, pending, or intentionally dropped) — keeps this from becoming a guessing exercise mid-migration.

Critically, this decision should involve someone from the business side, not just whoever is running the technical migration. A field labeled “Secondary Phone” might look safely droppable to an admin doing a quick pass, but be load-bearing for how a specific team — say, an ops team that always calls the secondary number first for a certain account type — actually works. That’s a much cheaper conversation to have on a spreadsheet before migration than a support ticket after go-live.

What the numbers actually look like, by platform

How much of a migration’s cost sits in cleaning and mapping data — versus configuration, integration, and other phases — varies by destination platform, and it’s worth knowing where your project is likely to land before you scope it.

On HubSpot, data migration is one-fifth of the total budget — a meaningful phase, but not the dominant one, because HubSpot’s own onboarding pushes a fair amount of the effort into pipeline and property configuration instead. On platforms with a simpler underlying data model, like Pipedrive, migration complexity carries a proportionally larger share of the total (roughly a third of the budget, per the phase breakdown in the CRM migration guide) — precisely because there’s less customization work elsewhere to absorb the budget instead. Either way, the lesson is the same: cleaning data before it ever gets exported reduces this phase’s actual cost, regardless of which platform you’re migrating to.

Step 5: Validate at real volume before you trust it

A common mistake is validating a migration against a small sample — 200 records that all look fine — and declaring the data clean based on that sample alone. Run the actual migration into a sandbox or staging environment at realistic data volume, then have someone from the business side of the team review real records and pull the reports leadership actually uses weekly, checking that the numbers look right — not just that the record count matches the source. Problems that a 200-record sample would never surface — an edge-case picklist value that only appears in 2% of records, a field mapping that’s fine for 95% of cases but silently mangles the other 5% — show up reliably at real volume and essentially never show up in a small, hand-picked test.

Sources: this+that, CRM data decay statistics (2026); Gartner, cited via Landbase (2026); Gartner 2025 (agentic-AI project stall forecast).

Beyond duplicates: the quieter data quality issues

Duplicates and picklist inconsistency get most of the attention because they’re the easiest to demonstrate, but a handful of quieter issues cause just as much post-migration frustration if they’re not checked before export. Orphaned records — a deal with no associated contact, an activity logged against a company that was later deleted — migrate over as broken links that clutter reports and confuse anyone trying to trace a record’s history. Invalid or clearly fake email addresses (a placeholder like “test@test.com” entered years ago and never cleaned up) inflate marketing-contact counts on platforms that price by contact volume, quietly raising your subscription cost for records that were never real leads in the first place.

Ownership fields deserve a specific check too: records assigned to a rep who’s no longer with the company are common in any database with real tenure, and migrating them as-is means either an ex-employee’s name showing up in the new system’s reports, or an automation that tries to route a follow-up to someone who can’t act on it. Reassigning or clearing stale ownership fields before migration is a small task that prevents a recurring, slightly embarrassing problem in the new system’s first few weeks.

Deciding what to do with historical data

Not every record needs the same cleaning rigor. A useful distinction: active and recently-closed records (the last 12-24 months, roughly, though the exact window depends on your sales cycle) get full de-duplication and standardization treatment, since they’re what your team will actually work with daily in the new system. Older historical data is a separate decision — many teams export it and archive it outside the live CRM rather than fully cleaning and migrating years of stale records that will rarely be queried again, and even more rarely justify the cleanup cost when they are.

This isn’t about discarding history — archived exports remain available if someone needs to look something up — it’s about not spending scarce cleaning time and effort achieving the same standard for records nobody will act on versus the records your team depends on every day. Deciding this tradeoff explicitly, rather than defaulting to “migrate everything” or “migrate nothing old,” is worth a specific conversation during the audit phase described above.

Manual review versus automated tooling: use both, deliberately

Neither automated tools nor manual review alone gets this right; the efficient approach uses both, deliberately, for different parts of the job. It’s tempting to treat data cleaning as a pure tooling problem, find the right de-duplication software and the work handles itself, but that undersells how much of the job is judgment rather than pattern matching. Automated tools are genuinely useful for the high-confidence, obvious cases: exact email matches, clearly identical company names. They’re much weaker at the ambiguous cases that actually require judgment: two contacts with similar names at the same company who might be the same person or might be two different people, or a company record that shows two different addresses because it genuinely has two office locations, not because someone made a data-entry error.

The efficient approach uses automated tooling for the first pass — clearing the obvious, high-confidence duplicates and standardizations — and reserves manual review time for the smaller volume of genuinely ambiguous cases the tool flags but can’t confidently resolve on its own. Skipping the manual pass entirely and trusting automated matching completely tends to either under-merge (leaving obvious duplicates that just missed the tool’s matching threshold) or over-merge (incorrectly combining two genuinely different records that happened to share a name), and both mistakes are more expensive to unwind after they’ve propagated through the new system than they would have been to catch with a human review pass beforehand.

The bottom line

“Clean enough” is a bar you can define and check against, not a feeling. Resolve duplicates using an agreed matching rule, standardize picklist values to one spelling each, map every field with an explicit and business-informed decision, and validate the result at real data volume before cutover. Do that, and the migration itself — covered step by step in the CRM migration guide — moves faster and causes far fewer surprises in the first month after go-live than migrating data nobody has actually looked at.