What should you clean up before migrating data into a new CRM?

The most common CRM migration mistake isn’t a technical one — it’s treating the migration as a lift-and-shift instead of a filter. Everything from the old system gets exported and imported wholesale, on the theory that it can be cleaned up “later,” and later never comes because the new CRM now has exactly the same duplicate records, dead fields, and inconsistent values the old one did, just without the tribal knowledge of which records to trust. Migration is the one moment you have real leverage to fix that — do the cleanup before import, not after.

Step 1: Dedupe before you export, not after you import

Run a duplicate check on contacts, companies, and deals in the source system first. Merging duplicates after they’ve both landed in the new CRM means reconciling activity history, ownership, and custom fields across two records in an unfamiliar system — considerably harder than resolving the same duplicate in a system your team already knows well. This is also the right moment to decide on an ongoing dedup policy, not just a one-time pass — see keeping CRM data clean for what prevents the problem from recurring.

Step 2: Map fields deliberately — don’t import everything

Every field in the old CRM was created for a reason at some point, but many of those reasons no longer apply. Go through the source schema field by field and decide: does this still matter, does it map to an equivalent field in the new system, or does it get left behind? Importing every legacy custom field by default is how a new CRM inherits years of accumulated clutter on day one instead of starting clean.

Step 3: Standardize picklist and status values

Source systems accumulate inconsistent values over time — “Closed Won,” “closed-won,” and “Won (Closed)” all meaning the same thing to different reps. Reconcile these into one canonical set before import; the new CRM’s lead status and opportunity stage fields should launch with a clean, agreed taxonomy rather than importing whatever inconsistency existed before.

Step 4: Resolve ownership and orphaned records

Every record needs a current, valid owner — not a departed employee’s name still attached to two hundred accounts. Reassign or explicitly archive orphaned records rather than importing them as-is; an unowned record in a brand-new CRM is far less likely to get noticed and fixed than one in a system the team already scrutinizes daily.

Step 5: Back up the source system in full before cutover

Export a complete, unfiltered backup of the old system before migration begins, independent of whatever subset you’re importing. Migrations surface mapping errors you won’t catch until after go-live, and the only reliable fix at that point is being able to check the original record — not reconstruct it from memory.

What should you do next?

Build the checklist above into an actual pre-migration task list with an owner and a deadline for each step, run it fully in a source-system export before touching the new CRM, and only then schedule the import. A migration that skips the cleanup step to save a week upfront routinely costs more than a week cleaning up the same mess again inside the new system.