How to Migrate CRM Data Without Losing Anything

Most failed CRM projects don't fail at the build. They fail at migration — the point where years of records have to move from the old system into the new one, and something goes missing.

Usually it isn't dramatic. Nothing is deleted. But notes get orphaned, a custom field silently drops, dates shift by a day because of a time zone, and three months later someone can't find the history on an account and quietly stops trusting the new system. Once trust goes, people go back to spreadsheets and the project is dead regardless of how good the software is.

Here's how to avoid that.

Start by deciding what actually needs to move

The instinct is to bring everything. That's usually wrong. Migration cost scales with volume and with mess, and a lot of what's in an old CRM is neither used nor trustworthy.

Sort your data into three piles:

• Live — active customers, open jobs, current pipeline. Must come across, complete and correct.
• Reference — closed jobs, past customers, historical notes. Needs to be findable, doesn't need to be pretty.
• Archive — dead leads from six years ago, duplicates, test records someone created in 2019. Export to cold storage and leave it there.

That last pile is often 30 to 40 per cent of the database. Not migrating it is the single cheapest decision in the project.

Audit before you move, not after

Run this on your existing data before anyone writes migration code:

• Duplicates. How many contacts appear more than once? Which is the real one? Merging is far cheaper before migration than after.
• Required fields that are empty. If half your records have no phone number, you need to decide now whether that's acceptable.
• Free-text fields holding structured data. Someone has been typing job status into the notes field for four years. That's information, and it needs a plan.
• Inconsistent formats. Phone numbers as 0412345678, +61412345678 and 0412 345 678. Dates as both DD/MM and MM/DD. Both will bite you.
• Attachments. Where are they stored, how big is the total, and does the export include them? Frequently it doesn't.
• Relationships. Which notes belong to which contact, which contacts to which company. These links break more easily than the records themselves.

Map every field before you move any of them

Write down, field by field, where each one goes in the new system. Every mapping decision falls into one of four categories: it moves as-is, it moves with a transformation, it gets merged with another field, or it gets dropped.

That last category is the one to be deliberate about. Dropping a field is often correct — but it should be a decision someone made and signed off, not a discovery someone makes in March.

Get the person who uses the data every day to review the mapping. Not the owner, not the developer. The person in it daily knows that the field labelled "Status 2" is the one that actually matters.

Migrate three times

This is the part people skip, and it's the part that works.

Run one — a test slice. Take 100 records covering your messiest cases and move them. You will find problems. Fix the mapping, not the records.

Run two — a full dry run. Move everything into a staging environment nobody is using. Now you know how long it takes and what breaks at volume. This is where you do reconciliation properly.

Run three — the real one. By now it's a rehearsed procedure with a known duration rather than an event.

Reconcile with numbers, not with a look

"It looks right" is not verification. Before you sign off:

• Record counts match, by type, old system versus new
• Spot-check 20 records field by field — including your five worst-formatted ones
• Financial totals match to the cent
• Date ranges match: oldest and newest record in each type
• Attachment count and total file size match
• Relationship counts match — notes per contact, contacts per company
• Every user account exists with the right permissions

Discrepancies are normal on the first pass. What matters is that each one gets explained rather than waved through. "We're 47 contacts short because those were duplicates we merged" is fine. "We're 47 short and we don't know why" is not.

Don't switch the old system off

Keep it running, read-only, for at least a month after go-live. It costs one more month of subscription and it buys you the ability to answer any "where did this go?" question in minutes instead of panicking.

Switch it off when a month has passed with no one needing it. Take a full export first, and store it somewhere you'll still be able to read in five years.

Plan the cutover on a quiet day

Not Monday morning. Not end of month. Not the day before someone's on leave.

Write out the sequence before the day: when the old system goes read-only, when the final export runs, when the import runs, who reconciles, who signs off, and what the rollback is if it goes wrong. Everyone should know who makes the call to proceed or abort.

The week after

Have someone available for questions all week — most will be "where do I find X now?" rather than faults. Keep a running list of what people ask, because three of those questions will point at something worth changing in the system.

Check daily for the first week that data is being created correctly. It's much easier to fix a bad pattern in week one than after 400 records have been entered the wrong way.

Done properly, migration is boring. That's the goal. If you'd like it handled by someone who's done it before, book a discovery call — migration, reconciliation and a month of parallel running are part of every build we do.