An ERP is not an application, it is the record of what the business believes to be true. Stock levels, ledgers, orders, payroll, tax positions. Every other system reads from it, finance closes the month with it, and the warehouse cannot dispatch without it. That is why modernising one is a different discipline from modernising ordinary software: there is no window in which it may simply stop.
The constraint shapes everything. You are not delivering a new system, you are performing a transplant on a patient who has to keep working through it.
Why big-bang cutovers fail
The plan is always the same: build the replacement, migrate the data over a long weekend, switch everyone on Monday. It is attractive because it is simple to explain and appears to avoid the cost of running two systems.
It fails for structural reasons rather than bad luck.
All the risk lands in one weekend. Every unvalidated assumption about data, integrations, permissions, reports and user behaviour surfaces simultaneously, at the point of least available time and highest stress. Problems that would each take a day to diagnose arrive in parallel.
Testing cannot cover it. An ERP’s behaviour is the sum of thousands of configuration decisions interacting with real transaction history. A test environment holds a sample; production holds the awkward cases — the credit note from 2016 that was never fully applied, the customer with three tax registrations, the product that exists in two units of measure.
Rollback is theoretical. By Monday afternoon the new system has taken orders and posted transactions. Going back means reversing real business activity, not restoring a backup. In practice teams push forward through problems they would have rolled back from, because rolling back has become the more dangerous option.
Every department changes at once. Finance, sales, warehouse and procurement all learn new processes in the same week, while support has no experienced users to lean on.
Phasing by module, not by department
The practical alternative is to move capabilities one at a time, with the old and new systems both live and a clear rule about which one owns what.
The unit of a phase should be a coherent capability with a defensible data boundary — procurement, warehouse operations, a business unit’s sales — not “everything the finance team touches”. The test for a good boundary is whether you can state, in one sentence, which system is the master for each entity during that phase. If you cannot, the phase is drawn wrongly and you will spend the project reconciling two systems that both think they are authoritative.
Two sequencing heuristics are worth more than a detailed plan. Start where the blast radius is smallest and the pain is real — a module with few downstream consumers, whose users want the change. And keep the general ledger late: it is the system of record inside the system of record, and almost every other module posts into it.
Where the estate is broad, a phase may also be a single business unit or country moving wholesale while the rest stay put. That trades data-boundary complexity for process divergence, which is often the easier problem to manage.
Parallel running, and what it actually costs
Running old and new side by side for a period is the single most effective de-risking measure available, and it is not free.
Genuine parallel running means the same transactions are processed in both systems and the outputs compared. That is double entry work for the people doing it, so it is sustainable for weeks, not quarters, and only for a defined scope. Teams that promise six months of full parallel operation are describing something their staff will quietly stop doing in week three.
A narrower version is usually the right trade: the new system is authoritative, the old one continues to receive a feed of the same transactions, and an automated comparison reports differences daily. You keep the detection value without the manual double-keying. What matters is that somebody owns the difference report and that a non-zero difference is treated as a defect with an owner, not as an expected artefact of transition.
Decide in advance what level of divergence ends the parallel period. “It looks fine” is not an exit criterion. “Zero unexplained differences across three consecutive month-ends for these twelve figures” is.
Data migration is the hard part
Every ERP programme underestimates this, and it is almost always the item that moves the date.
Cleansing happens before migration, not during
Master data in a long-running ERP accumulates duplicates, obsolete records, inconsistent codes and fields repurposed for something other than their name. Migrating that as-is imports the mess; cleansing it inside the migration scripts makes the migration unrepeatable and unauditable.
Treat cleansing as a separate workstream, run in the old system, owned by the business rather than the project team. It has value even if the programme is cancelled, which is a useful property.
Decide how much history moves
The default request is “all of it”, which is rarely justified and always expensive. Open transactions and current balances must move. Historical detail often does not need to live in the new system at all — an archive that finance can query satisfies most retention and audit obligations at a fraction of the cost. Get the retention requirement in writing from whoever is accountable for it, rather than inferring it.
Reconciliation is the deliverable
Migration is not finished when the load completes without errors. It is finished when someone with authority signs that the balances agree.
Build the reconciliation before the migration: an automated comparison of control totals — trial balance by account, stock valuation by location, open orders by customer, aged debt by bucket — run after every rehearsal. Where a difference is expected because of a deliberate rule change, document the expected delta and prove that figure too.
Rehearse the full migration repeatedly against a copy of production, not a sample. Each rehearsal should be timed, scripted and produce the same reconciliation pack. The first rehearsal exists to find out how wrong the plan is; by the last one, the run should be boring.
Keeping integrations alive
An established ERP is surrounded by things that read from it, and the inventory is always longer than the documentation suggests: the e-commerce platform, the warehouse system, the bank feeds, the payroll interface, the reporting warehouse, the tax filing tool, and the spreadsheet on someone’s desktop that pulls a nightly extract and drives a decision nobody in IT knows about.
Two practical measures carry most of the load. First, inventory the consumers empirically — from database logs, API access records and firewall traffic — rather than from a list, because the list is incomplete. Second, place a stable interface layer in front of the ERP and point consumers at it, so that when ownership of an entity moves from old to new, the routing changes in one place instead of in twenty consuming systems on the same night. That facade is the same mechanism described in our piece on the strangler pattern, and it is what makes a phased ERP migration mechanically possible.
The part that is not software
A modernisation that changes only the software delivers a new interface onto the same inefficiencies. But process change and system change compete for the same attention, and doing both at maximum intensity in the same phase is how programmes stall.
The workable sequence is to standardise deliberately where the current process is genuinely broken, and otherwise preserve behaviour through the transition and improve it once the new system is stable. Every deviation from standard functionality should have a named business owner who can explain why the difference is worth its permanent maintenance cost.
Training pitched at the button level ages badly and does not survive contact with an exception. Train people on how the new model works — what a document represents, what posts where, why a step exists — and they can reason about cases the training never covered. Identify people in each function who learn the new system early and become the first line of support for their colleagues; users ask the person next to them long before they raise a ticket.
Rollback planning
Every phase needs a written answer to three questions, agreed before go-live: what specifically would make us reverse, who decides, and how do transactions entered in the new system get back into the old one.
That third question is the one that gets skipped, and it is the one that determines whether rollback is real. If the answer is “we would re-key them”, establish the volume at which that stops being feasible, and treat that volume as the point of no return.
Set the decision point explicitly — a time and a person, not a mood. A phase that has passed its decision point without triggering rollback should stop discussing rollback and move to fixing forward, which is a different and better-focused activity.
What “done” means
Go-live is not done. Done is a set of conditions somebody signs:
- A month-end has closed in the new system within the normal timetable.
- Reconciliation differences are zero or individually explained and accepted.
- Every identified integration is running against the new system, and the old endpoints are switched off.
- Support volume has returned to something near its pre-migration baseline.
- The old system has been made read-only, with an agreed date and process for decommissioning it.
That last condition is where value is realised. An old ERP left running “just in case” continues to consume licences, infrastructure, patching effort and attention, and it gives users a route back to the old process. Decommissioning should be a scheduled deliverable with a date, not an intention.
How we approach it
Our ERP and legacy application modernization work is scoped around the constraint that the business keeps trading: phases with defensible data boundaries, reconciliation designed before migration, and integrations routed through a layer that lets ownership move without a coordinated overnight change. Where the underlying question is whether to move the ERP at all, our guide to rewriting, refactoring or replatforming is the better starting point.
Talk to us about your ERP estate and we will map the phases before anyone writes code.