How to migrate data from one CRM to another
Three jobs pretending to be one: export everything, decide what actually moves, import in two passes. The hardest part is deciding what to leave behind.
Syncek Team · CRM reference library
/ 5 min read / Art. #53
A CRM migration is three jobs wearing one name. Getting the data out. Deciding what actually moves. Getting it in. Most of the pain comes from treating them as one step and doing the middle one last.
The CRM migration checklist
The three jobs break down into seven steps, in the order you do them. Each has a check to pass before the next one starts.
| # | Step | What to do | Done when |
|---|---|---|---|
| 1 | Export everything | Export contacts, companies, deals, notes, and email history as separate files while the subscription is active. Edit copies only. | Custom fields and note bodies match the screen for a handful of records you know well. |
| 2 | Decide what does not move | Write the rule before you look at the data, then apply it to the copies. | The rule is written down, and everything it leaves out sits in an archive file. |
| 3 | Merge duplicates | Find duplicate contacts and companies in the copies and merge them. | Each person and each company appears once. |
| 4 | Map the fields | Put the old fields beside the new ones. Give each unmatched field a new home, or drop it. | No old field is undecided, and every value of a fixed-value field, such as lifecycle stage, has a match. |
| 5 | Pilot import | Import 10 to 20 records in order: companies, contacts, deals. Open each one in the new system. | Every field landed where the map says, and each contact and deal is linked to the right company. |
| 6 | Full import | Load the rest in the same order, then notes and activities. | Each layer holds as many records as its file has rows. |
| 7 | Keep the old CRM readable | Keep read access for about a month. | The month is up, and every request for something you did not migrate was answered from the old system. |
Export everything before you cancel anything
Do this first, on the day you decide, not the week you leave.
Export contacts, companies, deals, notes and email history separately, and keep the raw files untouched. You will edit copies. Once the subscription lapses you may lose access to exports entirely, and a vendor under notice is not motivated to help.
Check the export actually contains what you saw on screen. Custom fields and note bodies are two that often go missing.
Decide what does not move
This is the step people skip, and it is where the value is.
A migration is the only moment you get a free clean-up. Contacts that have never replied, deals closed three years ago, companies that no longer exist: moving them costs import time now and clutters every view afterwards. Open deals that stopped moving are the same question, and whether the pipeline is realistic is easier to answer before an import than after.
Write the rule before you look at the data, so you are not deciding record by record. Something like: contacts with any activity in two years, all closed deals, notes attached to either. Then find the duplicates before you import rather than after, because merging is easier in a spreadsheet than in a database.
Give what you leave behind a home. An archive file in cold storage is still governed by your retention rules, and "we did not migrate it" is not the same as "we deleted it".
Map the fields once, on paper
List the old fields in one column and the new ones beside them. Mark every old field that has no new home, and decide right there whether to create one or drop it.
This takes an hour and saves a re-import. The alternative is discovering mid-load that lifecycle stage has four values in the old system and three in the new one.
Import in two passes
Companies first, then contacts, then deals. Each layer references the one before, so loading them out of order produces orphans.
Run a test import of 10 to 20 records first, look at them in the new system, and only then load the rest. Preparing the CSV properly is what makes the difference between one pass and five.
The week after
Keep the old system readable for a month if you can. Not as a fallback, but because the first month is when somebody asks for the one thing you did not migrate.
Frequently asked questions
How do you migrate data from one CRM to another?
Export everything first, while your subscription is still active. Then decide what actually moves, using a written rule rather than record-by-record judgement. Map old fields to new ones on paper before loading anything. Finally import in layers, companies then contacts then deals, testing 10 to 20 records before you load the rest.
What should you not migrate to a new CRM?
Anything you would not create today. Contacts with no activity in two years, deals closed long enough ago that nobody reports on them, and companies that no longer exist. A migration is the only moment you get a free clean-up, and moving dead records costs import time now and clutters every view afterwards.
In what order should you import CRM data?
Companies first, then contacts, then deals, then notes and activities. Each layer references the one before it, so loading contacts before their companies creates orphan records that have to be relinked by hand. Test the order with 10 to 20 records before committing to a full load, since fixing the sequence afterwards is far more work.
How long should you keep the old CRM after migrating?
About a month of read access if the contract allows it, and not as a fallback. The first weeks are when somebody asks for the one thing that did not come across, usually a note or a custom field nobody listed. Keeping it readable turns that from an incident into a lookup.
What usually goes missing in a CRM export?
Custom fields and the bodies of notes. Both look present on screen and both are frequently absent or truncated in the export file. Check them specifically against a handful of records you know well, before you rely on the file, because by the time you notice during import the old system may already be gone.
Should you clean data before or after importing?
Before, in the spreadsheet, every time. Merging duplicates and fixing inconsistent values is far easier in a file you can sort and filter than in a database with relationships already built. Cleaning afterwards also means the bad records sit in your reports for however long the clean-up takes, which is usually longer than planned.