Every legacy migration has the same tension. The old system is holding the business back, and the business cannot stop while it is replaced. The failures almost always come from resolving that tension the wrong way: picking a date, switching everything at once, and discovering on Monday morning what nobody had tested.
Why big bang cutovers fail
A single switchover concentrates every risk into one weekend. You find out simultaneously that the data did not map cleanly, that a report the finance team relies on does not exist, that a workflow nobody documented was load bearing, and that the warehouse staff do not know the new screens.
There is no way to test all of that in advance, because the failures are not technical. They are organisational, and they only appear when real people do real work under real pressure.
Big bang is occasionally the right answer, for small systems with few users and simple data. For anything a business depends on daily, it is a bet with no hedge.
The approach that works: strangle it
Instead of replacing the system, replace one function at a time, and let the old system keep running until nothing is left pointing at it.
- Pick the least risky, most annoying piece first. Often reporting, or a single workflow that irritates people daily. Something visible enough that people notice the improvement and low risk enough that a mistake is recoverable.
- Build the replacement so it reads from the old system’s data, or from a synchronised copy. Nobody has to move yet.
- Move a small group of users to it. One branch, one team, one product line.
- Run both for a period. When they agree, expand. When they disagree, you have found a real requirement nobody wrote down.
- Repeat with the next function, until the old system holds nothing anyone needs.
This takes longer in calendar time and is dramatically less likely to produce a crisis. It also lets you stop, because at every stage the business is running.
Parallel running, which most companies skip
For the core financial or inventory function, run both systems on the same real transactions for two to four weeks and compare the outputs daily.
Yes, it is double work for that period, and that is exactly why it gets cut. It is also the only way to find the discrepancies that matter before they are your only record. Every migration that skipped this and later found that six months of stock valuation was wrong would have paid for the parallel run a hundred times over.
Data is what decides the timeline
The engineering to move data is usually straightforward. The problem is what the data contains.
- Duplicates. The same supplier entered five ways. The same customer with three records.
- Inconsistent units. Some items in cartons, some in pieces, no rule about which.
- Free text where structure was needed. A status column with forty distinct values including spelling variants.
- History with no source. Balances carried forward that nobody can explain.
Cleaning this before migration costs a fraction of cleaning it during, and a small fraction of discovering it afterwards. Budget a data audit in the first week, always. Our note on what an ERP really costs makes the same point for the same reason: migration is where projects overrun.
Decide what history to bring
The default assumption is that everything must come across. It usually does not. A common and much cheaper pattern: migrate current open records and balances into the new system, and keep the old system available read only for historical lookups for a year.
That single decision often halves the migration effort.
The cutover checklist
For each function you move:
- A rollback plan you have actually tested, not just written.
- A defined freeze window where no transactions are entered in either system.
- Reconciliation of totals before and after, checked by someone from finance.
- Users trained on the new screens before the day, not during it.
- A named person available for support who is not the person doing the migration.
- The old system left running, read only, not switched off.
That last one is the cheapest insurance in the entire project and it is regularly ignored to save a hosting fee.
The part that is not technical
Most migration resistance is from people who were competent in the old system and are now beginners. That is a real loss for them, and treating it as an attitude problem rather than a legitimate one is how projects acquire quiet saboteurs who keep parallel spreadsheets.
What helps: involve the people who use the system daily in choosing what gets built, train before cutover rather than during, and nominate one person per team who learns it first and helps the rest. The internal owner matters more than any feature.
How long it takes
- A small system, few users, clean data: 4 to 8 weeks.
- A departmental system with integrations: 3 to 6 months.
- A core business system, multi location, years of history: 6 to 18 months using the strangle approach.
The variable is almost never the engineering. It is data quality and how many people have to change how they work.
Frequently asked questions
Should we migrate all data or start fresh?
Migrate open records and current balances. Keep history accessible in the old system read only unless there is a legal or operational reason to move it.
How do we avoid downtime?
Replace one function at a time rather than switching everything at once, and keep the old system running until nothing depends on it.
What is the most common cause of migration failure?
Dirty source data, followed by inadequate training. Neither is a software problem, and both are predictable.
Can we run both systems permanently?
Not for the same function. Two systems of record for the same data produce two versions of the truth, and reconciling them becomes a permanent job.
Ezitech has migrated businesses off legacy ERP, POS and custom systems across 10 or more industries. Tell us what you are trying to replace.