Modernizing Oracle ERP without the big-bang risk

Most ERP programmes do not fail at go-live. They fail months earlier, at the moment someone decides the whole estate has to move at once because splitting it looked too complicated. The big-bang cutover is rarely chosen on its merits. It is what remains after sequencing was treated as an afterthought.

A modernization that survives contact with a real business tends to look unglamorous: a long series of small, reversible moves, each of which leaves the organization able to invoice, pay people and close the books on Monday morning.

Start with an estate assessment, not a roadmap

Roadmaps built before anyone has read the customizations are fiction. The first weeks should be spent establishing what actually exists, which is almost never what the documentation claims.

• Every customization, with the business reason it was written and whether that reason still holds.
• Integration surface: what calls the ERP, what the ERP calls, and which of those paths are undocumented.
• Data quality in the objects that block a cutover, chiefly chart of accounts, vendor and customer masters, and open transactions.
• The reporting that finance will not close the month without.

A surprising share of customizations turn out to encode a process that was abandoned years ago. Retiring those is the cheapest scope reduction available, and it only becomes visible when someone goes looking.

The question is never whether to modernize. It is which part can move first without taking the close with it.

Sequence by blast radius, not by module

Programmes are often sequenced by module because that is how the software is licensed. A better axis is blast radius: how much of the business stops if this piece is wrong on day one.

Reporting and analytics usually move first. They are read-only, they prove the data pipeline end to end, and a bad week costs dashboards rather than payroll. Procurement and expense tend to follow. Core financials and anything touching payroll go last, with the longest parallel run, because those are the systems where being wrong is not recoverable by apologising.

Parallel running is the price of reversibility

Teams resist parallel running because it means doing the work twice for a period. That is precisely what buys the ability to stop. A cutover you cannot reverse is not a cutover, it is a bet.

The discipline worth keeping is to define, in writing and before the window opens, what would make you roll back. Thresholds decided in advance get honoured. Thresholds decided at 3am during a go-live never do.

Treat the integrations as the real project

The ERP migration is usually the smaller half. The larger half is every system that assumed the old behaviour: the warehouse tool that parsed a specific file layout, the bank integration keyed to a particular reference format, the spreadsheet a controller has run every quarter for a decade.

Those break quietly. They do not throw errors; they produce slightly wrong numbers that no one notices until a reconciliation fails. Finding them requires tracing the data, not reading the architecture diagram.

What good looks like

• A first production workload live early enough that the organization believes the programme is real.
• Every phase independently reversible, with the rollback trigger written down beforehand.
• Finance closing the books on the new stack at least once before the old one is switched off.
• No phase whose failure stops the business from operating.

None of this is novel. It is simply harder to sell than a single decisive migration, and it is the approach that tends to still be standing a year later.