CRM Migration: A 5-Step Plan (With Checklist and Timeline)

A CRM migration moves your customer records, their history, and the processes built around them from one system to another. The data transfer is usually the easy part. Migrations go wrong in the pieces people forget to plan for: automations that don’t come across, reports that stop matching, owners who get reassigned by accident, and a sales team that goes back to spreadsheets the week after go-live.

This guide walks through the five steps, a mapping checklist you can copy, realistic timelines, and a cutover plan with a way back if something breaks.

What a CRM migration includes

Most teams budget for “moving the data” and get surprised by the rest. A full migration has four layers:

If a vendor quote only covers the first row, it isn’t a migration quote.

How long does a CRM migration take?

It depends less on record count than on how many objects, integrations and rebuilt automations you have. As a working guide:

Two things stretch timelines more than anything else: nobody owns data decisions (so every mapping question waits a week), and the data turns out dirtier than anyone admitted.

Step 1: Audit what you have before choosing what to keep

Export everything from the current system and take an unsparing look at it. You’re answering three questions:

• What’s in use? Fields that are empty on 90% of records, pipelines nobody has touched in a year, and custom objects built for a project that ended are candidates to leave behind.
• What’s broken? Duplicates, contacts without accounts, deals with no owner, free-text fields that should be picklists, dates in three formats.
• What depends on what? List every automation, report, dashboard and integration that reads or writes CRM data. This list becomes your rebuild backlog.

A migration is one of the cheapest times to clean data. Anything you move dirty, you’ll pay to clean later inside a more expensive system. If this is where you are, our guide to cleaning up your CRM and keeping it clean goes deeper.

Step 2: Define what the new CRM must do on day one

Write down the outcomes, not features. For example:

• “Every inbound lead is assigned to a rep within 5 minutes.”
• “Sales leadership can forecast by segment without exporting to Excel.”
• “Support can see open deals before replying to a customer.”

Then split the list into must-have at go-live versus phase two. Trying to launch everything at once is a common reason a migration slips by months. If you’re still choosing the platform, read how to choose the right CRM before you go further, because the target system shapes every decision that follows.

Step 3: Map every object and field

This is the core of the project. Build a mapping sheet with one row per field:

Decisions to make explicitly:

• Record owners. Map users by email and decide what happens to records owned by people who’ve left.
• Picklists and stages. Old values need a home in the new model. Don’t import values that shouldn’t exist anymore.
• IDs. Store the legacy record ID on every migrated record. You’ll need it to reconcile counts, fix mistakes and re-link history.
• Load order. Parents before children: users, then accounts, then contacts, then deals, then activities.
• What you’re not moving. Write it down and get sign-off, so nobody discovers the gap in month two.

Step 4: Test-load, reconcile, then plan the cutover

Never run the first full load in production.

• Test load in a sandbox with a real sample: 5–10% of records, including your messiest ones.
• Reconcile. Record counts per object should match the source minus anything deliberately excluded. Spot-check 20–30 records end to end: fields, owner, related contacts, activity history.
• Rebuild and test automations against the migrated test data, not clean demo data.
• Run user acceptance testing with two or three people from each team, doing their actual daily tasks.

Plan the cutover:

• Freeze window: when the old system goes read-only.
• Delta load: records created or changed between the full load and the freeze.
• Integration switch-over order.
• Rollback plan: the conditions under which you revert, and how. If you haven’t written down how to go back, you don’t have a plan.

Many teams cut over at the end of a week, leaving the weekend as buffer, and keep the old system read-only for at least one full sales cycle afterwards.

Step 5: Support the first 30 days after go-live

Adoption is decided in the first few weeks. Plan for:

• Hypercare. Named people fix issues the same day for the first two weeks.
• Role-based training. Reps, managers, marketing and support each need a short session on their own workflows, not a platform tour.
• Adoption checks. Log-ins, records updated, pipeline changes. If a team’s activity drops, find out why in week one, not month three.
• A phase-two backlog. Everything you deferred in Step 2, prioritized with real usage data.

What usually breaks at cutover

From the migrations we’ve been brought into after the fact, these cause most of the pain:

• Email and activity history exported without the link to its contact, so it lands as orphaned records.
• Automations rebuilt with slightly different logic, so leads route to the wrong rep or get two nurture emails.
• Reports that no longer match because stage definitions changed and nobody told finance.
• Integrations still writing to the old CRM for days after go-live.
• Attachments and files left behind because they needed a separate export.
• Duplicate records created when a marketing form and an import both ran in the freeze window.

Most of these are preventable when they’re on the checklist.

CRM migration checklist

Before

• Full export and data audit completed
• Day-one requirements agreed and signed off
• Field/object mapping sheet complete, with owners
• “Not migrating” list signed off
• Legacy ID field created in the target system
• Integration inventory and switch-over order agreed

During

• Sandbox test load with a messy sample
• Record counts reconciled per object
• 20–30 records spot-checked end to end
• Automations rebuilt and tested on migrated data
• UAT completed by each team
• Freeze window, delta load and rollback plan confirmed

After

• Old system read-only, not deleted
• Hypercare owners named for two weeks
• Role-based training delivered
• Adoption metrics reviewed weekly for 30 days
• Phase-two backlog prioritized

Tools that help

• Salesforce Data Loader / Data Import Wizard: bulk loads into Salesforce with field mapping.
• HubSpot’s import tool and migration services: good for simpler object models moving into HubSpot.
• ETL/iPaaS tools such as Talend, Informatica or MuleSoft: useful when you need transformations, large volumes or repeatable loads.

The tool matters less than the mapping sheet. A good mapping sheet run through a basic importer beats a powerful ETL tool fed bad decisions.

When to bring in a CRM migration partner

You can run a small migration yourself. It’s worth bringing in help when you’re moving between platforms with different data models (Pipedrive or HubSpot to Salesforce, for example), when integrations or automations need rebuilding, when you have compliance constraints, or when nobody internally has done a migration before.

Mountainise runs CRM migrations and rebuilds across Salesforce, HubSpot, Pipedrive and Microsoft Dynamics as part of our CRM implementation and enhancement work. If you’re moving from Pipedrive specifically, our Pipedrive to HubSpot migration guide walks through that path.

Plan your migration with a second pair of eyes

Before you commit to a timeline, get your mapping and cutover plan reviewed by people who’ve seen migrations fail. Book a 30-minute CRM migration call and we’ll walk through your source system, target CRM and integrations, and tell you where the risk is.

Frequently Asked Question