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.

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.

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.

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

It’s tempting to treat data cleaning as a tooling problem — find the right de-duplication software and the work handles itself. 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.