Guide
CRM and ERP data migration: what actually goes wrong
Migration is a cleaning project with an import at the end. Here is what to move, what to leave behind, and the four assumptions that turn a two-week job into a two-month one.
In short
Most migration overruns are not technical. They come from discovering, halfway through, that the source data was never as clean as everyone assumed: duplicated customers, products with inconsistent references, and historical records nobody can explain. Decide early what actually has to move. Master data and open items almost always do. Full transaction history almost never earns its place, because it slows the migration and is rarely queried afterwards. Keep the old system readable instead.
Past the import button
What a migration actually involves
An import moves rows. A migration decides which rows deserve to exist in the new system, what they should look like once they get there, and who owns the answer when two records disagree. The import itself is usually the last afternoon of the project.
In practice the work splits into four parts: deciding scope, profiling the source data to find out how bad it really is, cleaning and reconciling it, then loading and verifying. Teams that budget only for the fourth part are the ones that overrun.
Three variables
What decides how long this takes
Not the row count. These three.
How many systems disagree
One source is a data project. Three sources that each hold a different version of the same customer is a reconciliation project, and reconciliation is where the weeks go.
Whether anyone owns the rules
Someone has to decide which duplicate wins and what a missing field should default to. If that person does not exist, the migration stalls waiting for decisions nobody is empowered to make.
How much history you insist on
Master data and open balances are bounded. Full transaction history is not, and it is the single easiest place to halve the scope without losing anything you will actually use.
The sequence
How a migration runs
Five phases. The first two are where the project is won or lost.
- 1
Decide what moves
Agree, in writing, which entities and which date ranges come over. Everything not on that list stays in the old system, which remains readable.
- 2
Profile the source
Count duplicates, nulls and inconsistent references before promising a date. This is the step that turns assumptions into a schedule you can defend.
- 3
Clean at source where you can
Fixing records in the old system is usually cheaper than writing transformation rules for them, and it leaves the team with data they recognise.
- 4
Load into a rehearsal environment
Never load straight into production. A rehearsal run tells you the real duration and surfaces the failures while they are still cheap.
- 5
Verify against the business, not the row count
Matching totals is not verification. Ask the people who use the data to find their own records, because they spot wrongness that no checksum will.
Four traps
The four assumptions that cost weeks
None of them are about the tooling.
Assuming the source is clean
It never is. The question is only how dirty, and profiling answers that in days rather than discovering it in month two.
Migrating everything because it is there
History carried over out of caution costs migration time, storage and every future upgrade. Carry what gets used and keep the rest readable elsewhere.
Treating go-live as the finish
The first weeks after cutover produce the corrections that matter. Budget for them or they land on whoever is least able to refuse.
Nobody owning the rules
Every migration hits records where the right answer is a judgement call. Without a named owner those decisions queue up and the project waits.
Side by side
Lift and shift vs a scoped migration
Same data. Very different second year.
| Dimension | Lift and shift | Scoped migration |
|---|---|---|
| What moves | Everything, because deciding felt risky. | Master data, open items, and history that earns its place. |
| Duplicates | Carried across and multiplied. | Resolved before the load, with a rule that is written down. |
| Timeline | Confident until profiling happens. | Set after profiling, so it survives contact with the data. |
| Trust after go-live | The team keeps checking the old system. | The new system is the answer, because they verified it themselves. |
What moves
- Lift and shift
- Everything, because deciding felt risky.
- Scoped migration
- Master data, open items, and history that earns its place.
Duplicates
- Lift and shift
- Carried across and multiplied.
- Scoped migration
- Resolved before the load, with a rule that is written down.
Timeline
- Lift and shift
- Confident until profiling happens.
- Scoped migration
- Set after profiling, so it survives contact with the data.
Trust after go-live
- Lift and shift
- The team keeps checking the old system.
- Scoped migration
- The new system is the answer, because they verified it themselves.
Being honest about it
When not to migrate at all
If the old system still does its job and the new one only overlaps it partially, running both with a connector is often the better answer. Migration is justified when a single source of truth removes real daily friction, not when it merely tidies the architecture diagram.
The other honest case is a business whose data is bad enough that migrating it would carry the problem forward. Sometimes the right move is to start clean with master data only, and treat the old system as an archive nobody writes to.
Questions we hear about migrations
Straight answers before you commit to a date.
Should we clean the data before or after?
Before, and in the old system where practical. Cleaning at source is cheaper than writing transformation rules and leaves the team with records they recognise.
Should we migrate our full transaction history?
Usually not. It slows the migration, inflates the new system, and is rarely queried once people trust the current data. Master data and open items come over; the old system stays readable for the rest.
How long does a migration take?
For a single clean source, a matter of weeks. Multiple disagreeing sources, or data nobody has profiled, extend it, and the honest answer is that the schedule cannot be set before profiling.
How is a migration priced?
It depends on how many sources disagree, the state of the data once profiled, and how much history is in scope. We share a precise number after the 30-min review.
How much downtime should we expect?
The cutover itself is usually hours, not days, because the rehearsal run has already established the real duration. What costs time is the correction period after go-live.
What if it goes wrong?
The old system stays available and readable until the new one is verified by the people who use it daily. Cutover is a decision made after evidence, not a date fixed in advance.
Not sure what your data actually looks like?
Tell us which systems hold customer and product records today. We will tell you what a realistic migration scope looks like, and where the reconciliation work is hiding.