CRM data migration is the move of contacts, companies, deals and their history from one CRM (or spreadsheets) into another. It succeeds when you audit and clean the data first, map every field on paper, run test loads and validate counts before the old system is switched off.
- Decide what not to migrate before deciding how to migrate
- Keep the old record ID on every new record
- Load in order: companies, contacts, deals, then activities
Switching CRM is rarely held back by the new software. It is held back by the data. Years of contacts typed in five different formats, deals that were never closed, custom fields nobody remembers creating, notes attached to people who left the company: all of it has to go somewhere, and the new CRM will only be as useful as what you put into it.
For most small teams, the built-in import wizard of the new CRM covers the simple part. The trouble starts with relationships (which contact belongs to which company, which email belongs to which deal), with history, and with fields that need reshaping on the way. That is where a migration either turns into a spreadsheet marathon or into a short project with custom migration scripts and sync services that do the reshaping the same way every time, so a test run and the final run produce identical results.
This guide walks through the whole process: what CRM data migration involves, which strategy to choose, a nine-step plan, how to map fields, which tools fit which situation, the mistakes that cause data loss and a checklist you can copy. If you are still choosing the destination system, start with our build vs buy CRM guide and come back once the decision is made.
What is CRM data migration?
CRM data migration is the process of extracting customer data from a source system, transforming it to fit the structure of a target CRM and loading it there, then confirming that nothing was lost or broken. Engineers call this extract, transform, load (ETL); in a CRM project it usually covers:
- Core records: companies (accounts), contacts, leads and deals (opportunities).
- Relationships: which contacts belong to which company, which deals involve which people, parent and child accounts.
- History: notes, emails, calls, meetings and tasks with their dates and owners.
- Files: attachments such as proposals, contracts and signed quotes.
- Configuration: users, owners, pipelines, stages, picklist values and custom fields.
Workflows, automations and reports are usually rebuilt rather than migrated, because every CRM implements them differently. Treat that as a separate workstream. If you want a refresher on how records and relationships fit together inside a CRM, our explainer on what a CRM database is covers the basics.
When should you migrate your CRM data?
Most teams migrate for one of five reasons:
- Outgrowing spreadsheets or a starter tool. The team has added reps, pipelines or a second sales motion and the old setup cannot keep up.
- Cost. Contact tiers and seat prices have risen past what the CRM delivers.
- Missing capabilities. Custom objects, a usable API, mobile access or reporting that the current tool does not offer.
- Mergers and consolidation. Two teams on two CRMs need one shared view of customers.
- Vendor changes. A product is discontinued, acquired or repriced.
Whatever the reason, the timing rule is the same: avoid the last two weeks of a quarter, avoid your busiest season and leave a buffer before any major campaign that depends on clean lists.
Which migration strategy should you choose?
There are three common approaches: big bang, phased and fresh start plus archive. The right one depends on data volume, how many people use the CRM daily and how much downtime you can accept.
| Strategy | How it works | Best for | Main risk |
|---|---|---|---|
| Big bang | Freeze the old CRM, move everything over a weekend, go live on Monday | Small teams, under ~100,000 records, one source system | Any problem found after go-live hits everyone at once |
| Phased (trickle) | Move one team, region or object at a time while both systems run | Larger teams, several pipelines, complex history | Two systems of record for weeks; needs a sync or clear ownership rules |
| Fresh start plus archive | Move only active records and open deals; keep the rest in a searchable archive | Messy legacy data, teams that rarely look at old history | Reps may need something that was left behind |
For most small and mid-size teams, a big bang migration of active data plus an archive of the rest is the fastest, cheapest and least confusing option.
How do you migrate CRM data step by step?
The nine steps below work for a move from spreadsheets, from one SaaS CRM to another or from an in-house system. Small teams can finish them in four to eight weeks.
Plan and prepare (steps 1–6)
- Set scope and success criteria. Write down which objects move, how far back history goes, the cutover date and how you will judge success (for example, "record counts match within 0.5%, all open deals present, every contact linked to a company").
- Audit the source data. Export everything and profile it: record counts per object, fill rate of each field, duplicate rate, oldest and newest records, fields nobody has touched in a year.
- Decide what not to migrate. Archive bounced emails, contacts with no activity for several years, test records and abandoned custom fields. Every record you leave behind is one less to clean, map and check.
- Clean the data. Merge duplicates, standardise phone numbers, country names and job titles, fix company names and fill required fields. Our guide on improving data quality with free web tools lists simple ways to do this without paid software.
- Map fields and values. Build a mapping document (see the next section) that links every source field to a target field, with transformation rules for picklists, dates and owners.
- Prepare the target CRM. Create users, pipelines, stages, custom fields and a hidden "legacy ID" field on every object before importing anything.
Test, cut over and validate (steps 7–9)
- Run a test migration. Load a representative sample, 5 to 10% of records including awkward ones, into a sandbox or trial account. Check counts, relationships and how records look to a rep.
- Cut over. Freeze edits in the old system, run the full load in the right order, then run a final delta for anything changed during the freeze.
- Validate and decommission. Reconcile counts, spot-check records, have reps work real accounts for a week and keep the old CRM read-only for at least one billing cycle before cancelling it.
How do you map fields between two CRMs?
Field mapping is where most migrations are won or lost. A spreadsheet with one row per source field works well. For each row, record the source object and field, the target object and field, the data type, the transformation rule and an owner who signs it off.
| Source field | Target field | Transformation | Common trap |
|---|---|---|---|
| Contact: Name | First name, Last name | Split on the last space; review exceptions | Double surnames and prefixes split wrongly |
| Company: Country | Country (picklist) | Map variants ("USA", "U.S.", "United States") to one value | Import rejects values not in the picklist |
| Deal: Stage | Pipeline stage | Stage-to-stage lookup table | Old stages with no equivalent left blank |
| Deal: Owner | Owner (user) | Match by email; inactive reps to a holding user | Deals owned by people who have left |
| Created date | Legacy created date (custom) | Store the original date; target sets its own | All records appear "created" on cutover day |
| Record ID | Legacy ID (custom, hidden) | Copy as text | Without it, re-linking and re-runs are guesswork |
The last two rows matter most. The legacy ID lets you re-link activities, run delta loads and trace any problem back to its source. The legacy date keeps age-based reports working, because most CRMs stamp imported records with the import date.
Which tools can you use for CRM data migration?
Five types of tools cover almost every CRM migration: native import wizards, vendor migration utilities, third-party migration services, integration and ETL platforms, and custom scripts. The choice depends on volume, how many related objects you have and how often you will rerun the load.
- Native import wizards. Every major CRM accepts CSV imports with field matching, and some handle associations between objects in one file. HubSpot's import documentation is a good example of what to expect. Best for small, flat datasets.
- Vendor migration utilities. Tools such as Salesforce Data Loader handle bulk inserts, updates and upserts with an external ID, which makes repeatable loads possible.
- Third-party migration services. Point-and-click services connect two popular CRMs directly and move records, relationships and some history. Useful when both systems are mainstream and the mapping is standard.
- Integration and ETL platforms. iPaaS and ETL tools suit phased migrations where both systems must stay in sync for a while.
- Custom scripts. Small programs that read from the source API or database, transform records and write to the target API. Best when the source is an in-house system, the transformations are unusual or you need the same run to be repeatable exactly.
Whatever you pick, check API rate limits and daily import caps on the target CRM in advance; they decide how long the cutover window needs to be. Our CRM integration guide explains sync direction and field ownership if you plan to run both systems in parallel.
What are the most common CRM migration mistakes?
- Migrating everything. Ten years of dead leads slow every search and inflate contact-tier pricing. Archive instead.
- Cleaning after the move. Duplicates and bad formats trigger automations and pollute reports from the first day.
- Ignoring relationships. Contacts arrive without their companies, deals without their contacts, notes without anything. Test associations explicitly.
- No legacy IDs. Without them, a second load creates duplicates and errors are impossible to trace.
- Losing original owners. Deals of reps who left arrive unassigned and nobody follows them up; route them to a holding user and reassign within the first week.
- Skipping the test run. Problems surface in front of the whole team on go-live day.
- Switching off the old CRM too soon. Keep it read-only until reps confirm nothing important is missing.
Poor data has a real cost: Gartner has estimated that bad data quality costs organisations an average of $12.9 million a year (Gartner on data quality). A migration is the cheapest moment you will ever get to fix it.
What should a CRM data migration checklist include?
Copy this list into your project tracker and tick it off in order.
- Scope, cutover date and success criteria written and agreed
- Full export of the source system stored safely as a backup
- Data audit done: counts, fill rates, duplicates per object
- Archive rules defined; archived data stored and searchable
- Duplicates merged and formats standardised in the source or staging copy
- Field and value mapping signed off by sales and marketing owners
- Users, pipelines, stages and custom fields created in the target
- Legacy ID and legacy date fields added to every object
- Test load of 5 to 10% of records reviewed by at least two reps
- Freeze announced; cutover run in dependency order; delta load done
- Counts reconciled and sample records checked field by field
- Automations, reports and integrations rebuilt and tested
- Old CRM read-only for one billing cycle, then cancelled
What happens after the migration?
Go-live is the start of adoption, not the end of the project. In the first month, collect reps' reports of missing or wrong data in one place and fix them in batches. Rebuild only the automations people actually used, and add the reports managers check weekly before anything else. Set a recurring data-quality review, even a monthly hour, so duplicates and empty fields do not creep back.
The migration usually fits inside a broader rollout of the new system, with training, ownership and a timeline for each team. Our CRM implementation plan sets out a 90-day schedule you can adapt, with the migration as one of its milestones.
CRM data migration: frequently asked questions
How long does a CRM data migration take?
For a small team with one source system and under 50,000 records, plan four to eight weeks from audit to cutover. The load itself often takes hours; most of the time goes into auditing, cleaning, mapping fields and running test imports.
Should I clean data before or after migrating to a new CRM?
Before. Deduplicate, standardise formats and archive dead records in the old system or in a staging copy. Importing dirty data into a new CRM spreads the mess into automations and reports from day one, and it is harder to fix later.
Can I migrate emails, notes and attachments, not just contacts?
Usually yes, but it is the hardest part. Notes and activities need their parent record IDs to be re-linked, and attachments are often limited by file size or storage. Decide early how much history you really need and archive the rest.
How do I avoid duplicate records during a CRM migration?
Pick one matching key per object, such as email for contacts and domain for companies, deduplicate in the source before export, keep the old record ID in a custom field and use upsert rather than insert where the import tool allows it.
Do I need a migration tool or can I use CSV imports?
CSV imports work for small, simple datasets with few relationships. A migration tool or a custom script makes sense when you have many objects, linked activities, attachments, or more than a few tens of thousands of records.
How do I check that a CRM migration was successful?
Compare record counts per object between the old and new systems, spot-check a sample of records field by field, confirm that associations such as contact-to-company and deal-to-contact survived, and ask reps to work a few real accounts before switching off the old CRM.
