CRM data migration is the planned move of accounts, contacts, leads, opportunities, and activity history into a new CRM. It is not a Friday-afternoon spreadsheet paste. The new system will only be as trustworthy as the file you load and the checks you run afterwards.
Field-to-field mapping, as a general integration idea, is explained in what is data mapping. This guide covers the migration project around that mapping: cleaning, trial loads, reconciliation, acceptance, and rollback.
Scope before files
Decide what moves, and what stays behind:
- Open leads and opportunities, or full history
- Closed deals for reporting, and how many years
- Activities and emails, which are often large and low value
- Attachments
- Users and ownership, including people who have left
If a former employee still owns hundreds of accounts, map that owner to a queue or a current manager before import. Otherwise the new CRM is full of dead users.
Clean, then map, then test
Cleaning happens on a copy of the source, not only inside the new CRM. Typical work:
- One row per account and per contact, with stable IDs from the old system
- Normalised phones and states
- Duplicate review, using the approach in duplicate CRM records
- Stage names translated through a written crosswalk
- Required fields in the new CRM filled or deliberately defaulted
Load a small batch first: 50 accounts, their contacts, and their open opportunities. Check that relationships survived. A contact without an account, or an opportunity pointing at the wrong company, means the keys are wrong. Fix the file. Do not “patch it in production” as the plan.
Migration sequence
- Freeze the scope and export source IDs
- Clean duplicates and map fields and stages
- Trial import and fix relationship errors
- Reconcile counts and sample records
- Users accept the sample, then you load the rest
Reconciliation
Compare counts by type: accounts, contacts, open opportunities, pipeline amount. Then sample 20 records a salesperson knows well. Ask:
- Is the owner right?
- Is the stage the agreed equivalent?
- Are the phone and address usable?
- Did open tasks come across?
A matching row count with wrong owners is a failed migration.
User acceptance and rollback
People who will use the CRM should run user acceptance testing on the trial data: find a customer, log a call, move a stage, and confirm they are not looking at a duplicate. Sign-off is about those tasks, not about a green import message.
Keep the source export and the old system read-only until the new CRM has been used for an agreed period. Rollback means returning users to the old system, not hoping an undo button exists. After go-live, new edits in the old system will diverge. Set a cutoff time and stick to it.
A practical example
A team leaving a shared spreadsheet imports accounts first, using a column “Old ID.” Contacts load second, matched on that ID. Opportunities load third, with stages renamed from “Hot / Warm / Cold” to the new pipeline crosswalk. The first trial shows 30 contacts without accounts because of trailing spaces in the ID. They trim the file and reload the trial. Only then do they import the full set, on a weekend, with the spreadsheet locked.
Key takeaways
- Keep source IDs so you can reload and reconcile.
- Trial a small related set before the full file.
- Match counts and a human sample.
- Accept the result with real users, and keep the old system read-only until cutoff.
FAQ
Should we import every email?
Usually no. Import open tasks and recent notes. Bulk email archives are slow, sensitive, and rarely searched.
Can we migrate while people are still selling?
Only with a cutoff. Changes after the export must be listed and applied, or they are lost. A short freeze is safer than a clever delta no one tests.
What if the old CRM cannot export?
Then the scope is whatever can be extracted, even if that is a report to CSV. Record the gaps. Do not invent missing history in the new system.