Data that moves into a new CRM dirty stays dirty — fixing it after migration, inside a live production system people are actively using, is consistently harder than fixing it beforehand. This checklist covers what to address before any records move, organized by the type of problem each item solves.

Duplicate Records

• Identify duplicate contacts, typically by matching email address
• Identify duplicate companies/accounts, typically by matching domain name or normalized company name
• Decide a consistent merge rule (most recently updated record wins, unless a specific field should be preserved from an older record)
• Document which records were merged, in case historical questions come up later

Inconsistent Formatting

• Standardize date formats across all source data
• Standardize phone number formatting
• Normalize status and stage values that mean the same thing but are written differently (“Closed Won” vs “Won” vs “closed-won”)
• Check for inconsistent capitalization in company and contact names

Missing Required Information

• Identify records missing fields your new CRM will require
• Decide whether to fill gaps before migration, flag them for cleanup after, or exclude incomplete records from the initial migration
• Check specifically for missing email addresses on contact records, since this often breaks automation and email-sync features post-migration

Stale and Dead Records

• Identify contacts or deals with no activity in an extended period (commonly 12+ months, adjusted to your sales cycle length)
• Decide whether stale records migrate, get archived separately, or get excluded entirely
• Flag deals marked as open that are actually dead, so they don’t distort pipeline reporting immediately after go-live

Ownership and Assignment

• Confirm every record has a clear, current owner — records orphaned by a departed employee are a common source of post-migration confusion
• Reassign records from former employees to current team members before migration, not after
• Check that ownership data reflects current territory or account assignments, not historical ones

Field Mapping Decisions

• Map every source field to a destination field explicitly — don’t leave any as “figure it out during import”
• Decide what doesn’t migrate at all, and document why
• For free-text fields, decide whether they migrate as-is or get restructured into the new system’s structured fields

Validation Before Go-Live

• Run a test import with a small sample and manually verify results
• Spot-check records from different sources/time periods, not just the first few rows of an export
• Confirm record counts match expectations (source count minus intentionally excluded records should equal imported count)
• Verify that automation or integrations referencing specific fields still work correctly against the newly migrated data

Why This Checklist Matters More Than It Looks

It’s tempting to treat data cleanup as a mechanical chore to get through quickly so the “real” implementation work can start. In practice, the condition of your migrated data shapes how people experience the new CRM from day one. A salesperson who opens the system and sees duplicate contacts, orphaned records, or inconsistent deal stages forms an immediate impression that the new system is unreliable — even if the underlying platform is sound and the problem is entirely upstream in the data that was migrated into it. That first impression is disproportionately hard to undo once formed, which is exactly why this checklist earns the time it costs before go-live.

A Priority Order When Time Is Limited

If you don’t have time to address everything on this checklist with equal depth, prioritize in this order:

1. Duplicate resolution — duplicates actively corrupt reporting and create confusing duplicate outreach
2. Ownership/assignment accuracy — orphaned or misassigned records cause immediate confusion for users
3. Required field completeness — missing required fields can break automation on day one
4. Formatting consistency — important, but less immediately damaging than the above three
5. Stale record handling — can reasonably be addressed in a post-launch cleanup pass if time is truly limited

Frequently Asked Questions

Is it ever acceptable to migrate data without full cleanup, planning to fix it after? Sometimes, particularly for lower-priority items like formatting consistency, where post-migration bulk-edit tools can reasonably address the issue. Duplicates and ownership problems are worth addressing before migration whenever possible, since they’re more disruptive to fix once the system is in active use.

Who should be responsible for working through this checklist? Ideally someone who understands both the data’s history (why certain inconsistencies exist) and the new system’s structure (what “clean” actually needs to look like for migration to succeed). This is often the same person who owns the overall implementation plan, sometimes paired with whoever has been informally maintaining the data up to this point.

How do we handle data that’s split across multiple source systems, not just one spreadsheet? Apply this checklist to each source separately first, then add a reconciliation step to resolve cross-system duplicates — the same contact existing in two different source systems — before the combined migration. This reconciliation step is often the most time-consuming part of a multi-source migration.

Should historical notes and activity logs go through the same cleanup process? Generally treat them more leniently — the goal for notes and logs is usually preservation, not perfect structure. It’s reasonable to migrate historical free-text content with lighter cleanup than you’d apply to structured fields like stage or status, which directly drive reporting accuracy.

How do we handle data cleanup when the team actively disagrees about what counts as a duplicate or a stale record? This is common enough to plan for explicitly rather than treat as an edge case. Appoint a single decision-maker for ambiguous cases rather than trying to reach full consensus on every borderline record — migration timelines stretch indefinitely when every judgment call becomes a group discussion. Document the decision rules that person applies (for example, “contacts with no activity in 18+ months are considered stale unless flagged by their owner”) so the logic is consistent and explainable later if questions come up.

Next Step

Work through the duplicate and ownership sections first, since they cause the most immediate post-migration confusion. Formatting and stale-record cleanup can reasonably happen in a focused effort during the weeks right after go-live if time before migration is tight.