CRM Data Migration: How to Move Your Data Without Moving the Mess
How to run a CRM data migration: what not to move, the field mapping table, test migrations, five post-migration checks and when to switch the old system off.
CRM data migration is the riskiest task in switching from one CRM to another. Most teams treat it as a technical transfer and move everything as-is. The outcome is predictable: every bit of mess in the old system arrives in the new one, with mapping errors on top. Migration is not a moving job — it is a filtering job.
The question to answer before you start
Start with "what will we not move" rather than "what will we move". Things that typically should not travel:
- Records with no activity for more than two years.
- Cards for companies that have closed or merged.
- Invalid email domains and test records.
- Custom fields no longer in use — usually about a third of all fields.
- Old stages with no equivalent in the new process.
Do not delete these; export an archive from the old system and keep it. The new system then starts clean while you retain a fallback.
Write the field mapping table first
This is where the real work happens. For every old field, record four things: old field name, new field name, data type and transformation rule. The transformation rule is the critical column — it defines how a free-text city field becomes a fixed list, and how old stage names map to new ones.
No field moves without a mapping entry. The rule looks strict, but it eliminates most post-migration problems before they start.
Run a test migration first
- Select 5 percent of records, covering every record type.
- Load them into a test environment.
- Open 20 records at random and compare them against the old system by hand.
- Reconcile record counts, total values and stage distribution across both systems.
- Update the mapping table for every error found, then rerun the test.
Do not proceed to the real migration without two consecutive clean tests.
Post-migration verification checklist
- Count check: Do record totals match for every object type?
- Value check: Is the total value of open opportunities identical in both systems?
- Relationship check: Are contacts linked to the right companies, opportunities to the right contacts?
- Ownership check: Confirm every record is assigned to an active user.
- History check: Did activity and note history transfer with original dates intact?
Run all five within 48 hours of go-live. Problems found early can be fixed; correcting them after the team starts working in the new system costs far more.
Do not switch off the old system immediately
Keep the old CRM available in read-only mode for at least three months. Post-migration questions are almost always of the form "what did this record used to say". Without access, those questions go unanswered and the team's confidence in the new system erodes. Track who looks at the old system and how often, too: frequently consulted areas are exactly what the migration failed to carry over.
The common mistake: leaving migration to the technical team alone
The technical team can move fields, but the sales team knows which data actually earns its place. Do not start until at least one person from sales has signed off on the mapping table. Otherwise you end up with a technically flawless, practically unusable system — and the team never adopts the new CRM.
Practical tip: treat migration as a chance to redesign
Migration is a once-in-several-years opportunity to rethink your field structure. Decide here which fields will be mandatory and which stage transitions require which information. Adding rules after migration is always harder, because by then the team's habits are already set.
To make sure fields are complete from day one in the new system, Closync lets reps enter records by speaking.
