The CRM Migration Checklist: Clean Data First

The import worked. The data didn't.

It's Monday morning. The new CRM went live over the weekend and nothing errored out. At 9:15 a rep pings you because she can't find the Henderson account. It's there. It's there three times: "Henderson Group," "Henderson Grp.," and "HENDERSON GROUP LLC." The open deal is attached to the one nobody is looking at.

Nothing broke. Every record landed exactly where the mapping document said it should. That's the problem. The import was faithful, and what it was faithful to was a mess.

This is where most CRM moves go wrong. The tooling is the solved part. HubSpot and Salesforce both have serviceable importers, and if you're coming off a spreadsheet, the destination will happily accept whatever you hand it. Your old system will also happily export everything you ask for: all 47,000 contacts, including the ones from 2018 that bounced years ago, the duplicates created when your team merged with the acquisition's team, and the test records named "asdf test do not use."

Three failure patterns account for nearly all of it. First, the promise to "clean it up after we're live," which never survives contact with a go-live week. Second, trusting the export because it came out of a real system. Third, no reconciliation: no one ever proves the numbers on both sides match, so nobody notices when 1,100 activity records quietly fail to attach. A good crm migration checklist exists to close those three gaps before cutover, not after.

The four weeks before: audit, field inventory, sign-off

Give yourself four weeks of prep for a database under 50,000 records. Less than that and you'll be making mapping decisions at 11pm on cutover night, which is how "Industry" ends up dumped into a notes field.

Week one is the audit. You're establishing a baseline you'll compare against later, so write the numbers down somewhere permanent. It usually reveals the situation is worse than anyone assumed, which is far better to know now than during a stakeholder review.

• Record counts by object: contacts, companies, deals, activities, custom objects. Exact numbers, dated.
• Completeness rate per required field. What percentage of contacts actually have a phone? An owner? A lifecycle stage?
• Duplicate estimate on email, on company name, and on phone. Three separate numbers, because they'll disagree.
• Age distribution: how many records haven't been touched in 12, 24, or 36 months.
• Deal value totals by stage. This becomes your single best reconciliation check later.

Inventory every field, then make someone sign for it

Week two is the field inventory. Export a list of every field on every object, including the custom ones. For each field, record three things: fill rate, last modified date, and the person who claims it. Most teams find between a third and half of their custom fields have a fill rate under five percent and no living owner.

Those fields are your kill list. Anything under five percent fill with no named owner does not come across. Say so in writing, publish the list, and give people a week to object. Someone always objects to exactly one field, and they're usually right about that one.

Week three is sign-off. This is the step teams skip and regret. For each object, one named person confirms two things: the field mapping is correct, and the records being dropped can be dropped. Not a team. Not "sales." A person, with a date next to their name.

Week four is the test run, which gets its own section below. If you want the underlying method for the cleaning itself, our guide to cleaning CRM data covers the rules in more depth. Here we're focused on the sequence.

The checklist, grouped by what it fixes

Work in this order. Deduplication comes first because every record you merge is one you never have to standardize, fill, or validate. Validation comes last because its only job is to prove the other three worked.

All of it runs against the export, in a staging copy. Nothing here should touch the system you are about to leave.

Deduplicate

• Exact email matches first. They are free, and they shrink the pile before the hard part starts.
• Then the same person under a different address. "j.torres@" and "jtorres@" at one company, "Robert" and "Bob" on the same mobile number. Exact matching never catches these. SmartMatch scores them on similarity and hands you the pairs to confirm.
• Company duplicates, which do more damage than contact duplicates because they orphan deals. "Henderson Group," "Henderson Grp.," and "HENDERSON GROUP LLC" are one account carrying three sets of open opportunities.
• Write the survivor rule down before you merge anything: which record wins, what happens to the loser's open deals, and where its activity history lands. Merging without that rule is how history quietly disappears.

Standardize

• Phone numbers to E.164, everywhere, including the ones carrying an extension in the same field.
• One convention for states and countries, chosen once and applied to both objects. Codes or full names, not both.
• Company names keep their legal suffix, in its own field. "Acme Inc." and "Acme LLC" are sometimes two real entities, and deleting the suffix destroys the only evidence.
• Job titles are the trap. Do not force them into a taxonomy. Keep the raw title and put a seniority field next to it.

AutoFormat handles the mechanical passes. The value is less the time saved than the consistency: a rule applied by hand across 47,000 rows is a rule applied 46,000 times.

Fill

• Fill only the fields something downstream depends on. Record owner, lifecycle stage, and country for routing earn it. A custom field nobody has read since 2023 does not.
• Mark inferred values as inferred. SmartFill predicts from patterns already in your data, and a predicted industry is useful. A predicted revenue figure that a rep repeats back to a customer is not.
• Blank is a legitimate value. An invented value is a bug with a friendly face.

Validate

• Check email syntax and the domain's mail records, then flag rather than delete. Known bounces belong in a suppression field, not in the trash.
• Assert the required fields per object. If the new system needs an owner on every account, find the accounts without one now, while it is a spreadsheet filter and not an import error.
• Let LogicGuard flag what your rules never thought to ask about: deals that closed in 1970, negative amounts, a 14 digit phone number, one account holding 900 contacts.
• Then re-run the week one audit numbers. The gap between those two sets of numbers is the report you show the people who approved four weeks of prep.

If you want one number to track across that arc, the Clarity Score gives you a single figure per cleaning run, and its four sub-scores (Completeness, Consistency, Uniqueness, and Validity) map onto the four groups above.

Map every field before anyone opens the importer

Your old system's Industry dropdown has 47 values. The new one ships with 23. Somebody has to decide what happens to "Manufacturing, Heavy Equipment," and if that somebody turns out to be the importer, the answer is nothing and the field arrives empty.

The field mapping table is what prevents that. Four columns, one row per field, no exemptions for the boring ones.

The fourth column is the one teams leave blank, and it is the one that decides how the move actually goes. Every field has records that will not match cleanly. Settling their fate in advance turns a cutover night judgment call into a lookup.

Keep the table where the people doing the work can see it, and put the week three sign-off names next to the objects they signed for.

The test run, and the numbers that have to match

Week four. Move a sample, not the database.

Five hundred records is plenty, but choose them rather than sampling at random. Include the ugly cases on purpose: the account with 400 activities, the contact whose owner left last year, the deal in a currency nobody else uses, and a handful of records from every source feeding the move.

Then reconcile. This is the step that separates a move that worked from one that only looks like it did, and it is three counts per object, taken on both sides:

• Row counts. Contacts, accounts, deals, activities, custom objects.
• Deal value totals by stage. This is why you wrote the numbers down in week one.
• Relationship counts. Activities per contact, contacts per account, deals per account.

If a number is off by one, find the one. "Close enough" is how 1,100 activity records fail to attach and nobody notices until a forecast review in November.

Fix, reload the sample, reconcile again. Repeat until a run produces no surprises, then keep the reconciliation sheet. On go-live night it is the only thing standing between "the numbers match" and "it feels fine."

Cutover, and the rollback you hope you never use

Freeze the old system before the final export. Read only, at an announced time, announced more than once. Records created in a system you are halfway out of are the records that go missing.

Load in dependency order: accounts, then contacts, then deals, then activities. A failure at step three then leaves steps one and two intact and re-runnable instead of forcing a full reload.

The rollback plan is three things, written down before cutover rather than during it:

• A restorable export of the destination taken immediately before the load, so undo means delete and reload rather than repair in place.
• The old system kept read only for 30 to 90 days, with the renewal date and the budget line already settled. Nothing forces a bad decision faster than a contract expiring on Friday.
• A named decision maker and a stated trigger. "We roll back if reps cannot find their accounts by noon Monday" is a plan. "We'll see how it goes" is a four hour argument waiting for a room.

You will probably never use it. Writing it is still the cheapest insurance in the project, and the act of writing it usually surfaces one dependency nobody had thought about.

The first 30 days

The move is not finished when the import completes. It is finished when the people using it stop finding surprises.

• Week one: one channel for "I cannot find X," triaged the same day. Every report is either a mapping bug or a record you dropped on purpose, and those need very different answers.
• Week two: rebuild the five reports leadership actually opens, and check their totals against the pre-move numbers before anyone presents them.
• Week four: run the week one audit again. Duplicate estimate, completeness by field, age distribution. That is your new baseline, and the number you get to defend.
• Then keep the rules. The standards you applied to the export belong in the new system as validation on entry, or you will be working through a crm migration checklist again in 18 months for exactly the same reason.

None of the cleaning waits on a project date. Connect HubSpot, Salesforce, Shopify, Klaviyo, or Mailchimp through DataBridge, or hand CleanSmart the export you already have, and the dedupe, standardize, fill, and validate passes run in a few minutes with every change staged for review, and the result comes back as a clean file plus a change log, ready to load into the new system. Clean your export before you move it. The self-serve product demo runs the whole flow, and starting is free.

Working to a deadline? The printable CRM Migration Data Cleaning Checklist covers the same sequence with sign-off boxes for each phase.

Frequently Asked Questions

How long does data cleaning take before a CRM migration?

Four weeks is realistic for a database under 50,000 records: one week to audit, one to inventory fields, one for sign-off, one to test and reconcile. Add two to four weeks if you are combining multiple sources, because the merge creates duplicates that neither system had on its own.

Should I clean the data in the old CRM or after the export?

After the export, in a staging copy. Cleaning in production disrupts the team still working in it and leaves you with no before and after to compare. A staging copy gives you an audit trail and a safe place to be wrong.

What should I check first when records look wrong after cutover?

Counts, before spot checks. Compare row counts and deal totals by stage against the pre-move numbers, because a systematic gap (an object that never loaded, a relationship that did not attach) explains far more complaints than individual bad records do.