How to migrate a CRM without losing the history that made it useful
Exporting contacts is the easy part. What breaks is the relationships between them, the custom fields with no equivalent, and the activity history most exports leave behind entirely.
Verdict
Contacts export cleanly. Relationships, custom fields, and activity history usually do not. Clean the data before you move it, migrate in stages, and keep the old system readable for a quarter.
Why it is harder than an export#
A CRM is not a list. It is a set of linked records, and links are what exports handle worst.
Four objects, three sets of links
What actually has to move
Companies, contacts, deals, activities. The value is in how they connect.
Exporting contacts gives you a spreadsheet of names. It does not give you which company each belongs to, which deals they are on, or what was said and when.
That structure is what made the old CRM useful, and it is the part that breaks. The shape of the problem is covered in what is a CRM database.
Do this before you move anything#
Clean the old system first. This is the whole project, and it is much easier before the move than after.
- Delete contacts nobody has touched in three years
- Merge the duplicates you already know about
- Close deals that have been open since 2023 and are not real
- Note which custom fields anybody actually uses
Move in stages, in this order#
1. Companies. Everything else attaches to them, so they go first.
2. Contacts, linked to companies.
3. Deals, linked to both.
4. Activities, linked to all three.
Verify each stage before starting the next. If contacts land without company links, you want to know before you import ten thousand activities on top of them.
What will probably not survive#
Activity history. Many exports include contacts and deals but omit logged calls, emails, and notes. That is usually the most valuable data you hold, and the least likely to move.
Check whether your old CRM exports it at all before you plan around having it.
Custom fields. The new system may have no equivalent, or a different field type. Somebody has to decide what maps, what gets recreated, and what gets dropped.
Attachments. Files attached to records often need moving separately, if they can be moved at all.
Keep the old one readable#
Do not cancel the old CRM the day the new one goes live.
Keep it read-only for at least a quarter. Somebody will ask what was agreed with a client in March, and the answer will be in the system you were about to delete.
Downgrade it to the cheapest plan rather than cancelling, if that is possible. It is the cheapest insurance in the whole project.
Expect duplicates#
They will appear. Records arrive through the import, through email sync switching on, and through people typing names in during the changeover.
Plan a deduplication pass two weeks after go-live rather than trying to prevent them entirely. Prevention does not work; a scheduled clean-up does.
Check before you start whether your new CRM lets you undo a merge. Most do not, and a batch of bad merges is worse than the duplicates were.
A realistic timeline#
| Stage | Small business, clean data |
|---|---|
| Cleaning the old system | 1 to 2 weeks, part time |
| Staged import and verification | 2 to 3 days |
| Team switchover | 1 day |
| Deduplication pass | 2 weeks after go-live |
| Old system read-only | A quarter |
If the data is messy, cleaning becomes the entire project and the import itself is an afternoon. That ratio surprises people, and planning for it the other way round is why migrations overrun.
The short version
What works
- Migration is the one moment you can delete years of dead records without argument
- Staged migration lets you verify each object type before the next one lands
- Keeping the old system read-only for a quarter removes almost all of the risk
What does not
- Activity history is the most valuable data and the least likely to survive
- Custom fields rarely have equivalents, so somebody has to decide what to drop
- Every import route creates duplicates, and merging them afterwards is slow
Frequently asked questions
- How do I migrate from one CRM to another?
- Clean the data in the old system first, then move in stages: companies, then contacts, then deals, then activities. Verify each stage before starting the next. Keep the old CRM readable for at least a quarter so you can check anything that looks wrong.
- What usually gets lost in a CRM migration?
- Activity history, which is often the most valuable data you have. Many exports include contacts and deals but not the logged calls, emails, and notes that explain them. Custom fields with no equivalent in the new system are the second casualty.
- How long does a CRM migration take?
- For a small business with clean data, a few days of real work spread over two to three weeks. Most of that is cleaning and verification rather than moving. If the data is messy, cleaning is the whole project and the move itself is an afternoon.
- Should I migrate everything or start fresh?
- Migrate contacts, companies, and open deals. Be ruthless about the rest. Records nobody has touched in three years are not history, they are weight, and they will make the new system slower and more expensive from day one.
Written by
Tashawar Awais
Researcher and editor
Tashawar handles verification and editing. Every figure in a review is checked a second time before it goes out, and anything that cannot be traced to a vendor page or a documented source is either qualified or cut. Where pricing is genuinely unclear, as it is with Canva team plans or Close CRM tiers, the article says so and tells the reader to confirm directly instead of quoting a number with false confidence.
- Second check on every published figure
- Removes claims the sources do not support
- Flags pricing that changes without notice