Most CRM migrations do not fail on the day of the move. They fail weeks earlier, when someone exports a CSV, imports it into the new system and assumes the job is done. Then sales opens a deal and the call notes are gone, the owner is wrong and half the contacts are duplicates. This checklist is the order we work in when moving between Salesforce, HubSpot, Pipedrive, Zoho and Attio. It works for a 5,000 record CRM and for one with a decade of history.
Why CRM migrations go wrong
A CRM is not one table. It is contacts, companies, deals, activities, emails, files, owners, pipelines and the links between all of them. A spreadsheet export flattens those links. If you move contacts and deals separately without carrying the relationships, you end up with records that exist but no longer connect to each other.
The other common failure is ownership. Nobody on the team owns the messy middle: the field mapping decisions, the cleanup, the checking. Sales wants the new tool, ops wants clean data and nobody has the week it takes to do both. That is the gap this checklist is meant to close.
Phase 1: Before you export anything
- Inventory every object. List the standard objects you use (contacts, companies, deals) and every custom object, custom field and picklist. Include objects only one team uses. Those are the ones that get forgotten.
- Decide what not to move. Closed-lost deals from six years ago, bounced contacts and test records may not be worth carrying. Archive them as a file instead of importing them.
- List your integrations. Forms, email tools, billing, support desks and enrichment tools all write into the CRM. Each one needs to be pointed at the new system, and some will create records you did not expect.
- Create users first. Owners are usually matched by email. If a rep does not exist as a user in the new CRM before import, their records land with no owner or with whoever ran the import.
- Pick a freeze date. Agree when the old CRM stops taking new edits. Without one, you will chase a moving target through every test run.
- Check API access. Large or history-heavy migrations usually go through APIs, not CSV files. Check whether your plan on both sides includes the API access and limits you need.
Phase 2: Build the field map
The field map is the single most important document in the migration. Every field in the old system gets a row: where it goes, how it transforms, or a note that it is being dropped on purpose. Get it signed off by the people who use the data, not only the admin.
| Source field | Target field | Transform | Owner sign-off |
|---|---|---|---|
| Opportunity Stage | Deal stage | Map each old stage to a new pipeline stage | Head of sales |
| Lead Source (picklist) | Original source (dropdown) | Merge near-duplicate values first | Marketing |
| Account Owner | Company owner | Match by user email | Sales ops |
| Legacy region field | Not migrated | Archived in export file | Sales ops |
Pay special attention to three kinds of fields. Picklists, because value lists rarely match between systems. Dates, because time zones and formats shift. And anything used in reports or automations, because a renamed field quietly breaks a dashboard.
Phase 3: Clean the data before it moves
Cleaning after import is harder, because the new system starts building automations and history on top of bad records. Clean in the source or in a staging copy.
- Merge duplicate contacts and companies. Decide the rule up front (newest record wins, most complete record wins, or a manual review list).
- Normalize company names, domains, phone formats and country values.
- Reassign records owned by people who have left.
- Fix orphans: contacts with no company, deals with no contact.
Phase 4: Do a test run
Run the full migration into a sandbox or a trial workspace before touching production. Not a sample of 50 records. The whole thing, or as close as your plan allows. Test runs surface the problems a sample hides: rate limits, file sizes, odd characters in names, and the one custom field with 4,000 distinct values.
Import in dependency order. Users first, then companies, then contacts, then deals, then activities, notes, emails and files. Each later object needs the IDs of the earlier ones so the associations hold.
Phase 5: Verify before anyone switches
- Counts. Compare record counts per object between old and new. Explain every difference.
- Spot checks. Open 20 to 30 real records chosen by the sales team, including their biggest accounts. Check fields, owner, associations, notes and files.
- Reports. Rebuild the two or three reports leadership actually looks at and compare the totals with the old system.
- Automations. Turn on workflows only after the data is in, or they will fire on thousands of imported records at once.
Phase 6: Cut over
- Freeze the old CRM, run a final delta import for anything changed since the last test run.
- Point every integration at the new CRM and test each one with a real form fill or sync.
- Keep the old system read-only for a few weeks. People will need to check something, and it is your safety net if a field was missed.
- Give reps a short walkthrough built around their own records, not a generic training video.
Salesforce to HubSpot migration: what to watch
This is one of the most common moves, and the data models differ in ways that matter.
- Leads and contacts. Salesforce keeps leads and contacts as separate objects. HubSpot uses one contact object with a lifecycle stage. Decide how converted and unconverted leads map, and how to avoid creating the same person twice.
- Accounts and opportunities. These become companies and deals. Opportunity contact roles need to be carried as associations, or deals lose the people involved.
- Record types and multiple pipelines. If you use record types to separate sales motions, you will likely need separate HubSpot deal pipelines.
- Activity history. Tasks, events and logged emails need their own pass, linked through your ID map.
- The native connector. HubSpot offers a Salesforce integration, which is built for keeping two systems in sync. It can help, but check what it carries over (history, files, custom objects) before treating it as your migration tool.
Notes for Pipedrive, Zoho and Attio
Pipedrive is organized around deals, people and organizations, with pipelines at the center. Moving out of it is usually straightforward for core records. The care goes into stages, custom fields and activity history. Zoho CRM uses modules (leads, contacts, accounts, deals) and many teams add custom modules over time, so the inventory step matters more. Attio has a flexible object and list model, so moving into it is a chance to rethink structure rather than copy the old one field for field. In every case, check the import limits and API access on your plan before planning timelines.
Common pitfalls
- Importing before owners exist as users.
- Turning on automations before the data is in.
- Skipping notes, emails and files because they are harder to move, then discovering sales relied on them.
- No freeze date, so test runs never match production.
- No ID map, so post-cutover fixes become guesswork.
- Switching off the old CRM the same day.
How Remqa runs CRM migrations
We run CRM migrations end to end with the same four steps every time: map, test run, verify, cut over. Every field and pipeline stage is signed off before anything moves, and the old system stays read-only until you sign off on the new one. Our engineers use AI for the repetitive parts (field matching, cleanup rules, transform scripts) and check every record that matters by hand. If you are also moving recruiting data, see the ATS migration checklist. For spreadsheets and old databases, see data migration. Read more about how we run CRM migrations, or about the forward deployed engineers who do the work.