Modernizing an ERP without freezing the business
Slicing a replacement so every phase ships something usable and reversible. The order we choose slices in, how shadow mode works, and the parts we still find hard.
August 24, 2026 · Updated September 14, 2026 · 4 min read · Solution Architect
Every modernization proposal we have seen from a large vendor starts the same way: replace everything, run the old and new in parallel for eighteen months, cut over on a weekend. The risk sits entirely at the end. Nobody approves it, or someone does and the program is remembered for the weekend.
We do it in slices. This is what that means in practice, with the parts that work well and the parts that still keep us up.
Map before you cut
The first week or two produce no new software. We read the code, trace every integration, and sit with the people who operate the system. Not the managers. The person who runs the Friday reconciliation, the one who knows which screen to avoid at month end.
The output is a map: modules, the data each owns, the integrations in and out, who depends on what. Almost always, the map shows that a handful of modules carry most of the operational risk and most of the value, and a long tail could be left alone for years. That finding decides everything after it.
We also instrument. Where does time go? Which manual step exists because the system cannot do something? These become the candidates for the first slice.
Choosing the first slice
Not the most architecturally important module. The one whose replacement gives the most visible relief to the most people, with the fewest dependencies.
On one ERP modernization the technically obvious first slice was the master data module, because everything depended on it. We chose approval routing instead. It touched everyone, it was the source of most complaints, and it depended on master data only for reads, which we could serve from the old system. Within two months, approvals that had run through email ran through a system with a status anyone could see. That bought the program the credibility to do master data next.
A first slice that nobody outside the team notices is a slice that puts the program at risk in the next budget round.
Shadow mode
Each slice follows the same shape. Build the new component. Run it beside the old one, receiving the same inputs, producing outputs that are compared but not acted on. When the outputs match for long enough, switch the consumers to the new component. Keep the old one running for a defined period as a fallback. Then retire it.
The comparison step is where surprises live. New and old disagree, and the disagreement reveals either a bug in the new component or an undocumented behavior in the old one. Roughly half the time it is the second. The old system rounds a value in a way nobody wrote down, or applies a rule that exists nowhere except in twenty-year-old code. Each of these is a decision: replicate the behavior, or fix it and tell the business the number will change. We log every one.
Reversibility
Every slice has a rehearsed rollback. Not a document, a rehearsal. Before a cutover we switch consumers to the new component in a test environment, then switch back, and time it. If the rollback takes longer than the business can tolerate, the slice is not ready.
This costs effort and has been used, so far, twice in anger. Both times the business did not notice, which is the point.
Integration is the actual work
Nobody budgets enough for it. The modules are the visible part; the integrations are where the time goes. Every export-and-spreadsheet integration has to become an interface, and the spreadsheet usually contains logic that nobody realized was logic. A column that someone adjusts by hand every month is a business rule.
We build an integration layer early, in the first or second slice, that both old and new components talk through. It lets us move a module without touching every consumer, and it is where the shadow-mode comparison lives. It is also, honestly, the component we most often rework, because the first version is designed against the map and the map is never complete.
The parts we still find hard
Reporting. Every report that read from the old schema breaks when its module moves. We now inventory reports in the mapping phase and treat them as consumers with the same rigor as systems. Early on we did not, and finance found out on a month end.
Data migration for the long tail. Modules that are being left alone still hold data the new modules need. Deciding what to migrate, what to reference in place and what to archive is slow and does not ship anything visible.
People. The person who ran the Friday reconciliation for a decade has a job that changes. We have learned to involve them in the shadow-mode comparison, because they know what the numbers should be, and because it turns the change into something they are doing rather than something being done to them.
What we would do differently
Inventory the reports on day one. Always.
Build the integration layer before the first functional slice rather than alongside it, even though it delays the first visible win by a week or two. We have done it both ways; the version where the layer came first was less painful in every later slice.
And we would be firmer about the retirement step. Old components left running “just in case” become permanent, and a modernization that leaves the old system alive has not finished. Set the retirement date at cutover and hold it.