Skip to content

Enterprise software engineering · US registered · Global delivery

Modernisation

Retiring a monolith without stopping the business

Modernisation fails when it is sold as a rewrite. Inventory behaviour, slice so every step is reversible, and schedule the decommissioning date.

A large share of enterprise modernisation programmes are sold as rewrites and delivered as outages. The reason is rarely technical incompetence. It is that a rewrite asks the business to freeze its operating model for eighteen months while the replacement is built — and operating models do not freeze.

Inventory behaviour, not code

Legacy systems encode decades of decisions, including the ones nobody documented and the ones that exist only because of a customer commitment signed in 2009. Before proposing a target architecture, write down the behaviours the system must preserve: integration contracts, batch windows, regulatory reports, the two reports the CFO actually reads.

That inventory is the real specification. A target architecture that cannot reproduce those behaviours is a design exercise, not a migration plan.

Slice so every step is reversible

  • Wrap before you replace. Put a stable interface in front of legacy behaviour so consumers stop depending on internals.
  • Shadow traffic. Run the new path alongside the old one and compare outputs before switching a single user.
  • Dual-write with reconciliation. Migrate schemas while both stores agree, and treat disagreement as a defect, not noise.
  • Feature-flag the cutover. Every switch should have a documented rollback that takes minutes, not a release train.

Measure the cost of change, not the lines of code

The number that matters to the board is how long a routine change takes and how often it breaks something. Instrument that before you start: lead time for a small change, change failure rate, mean time to restore. A modernisation programme that halves lead time in two quarters while leaving half the monolith in place has succeeded, even if the architecture diagram is unglamorous.

Schedule the decommissioning

Nothing drains a modernisation budget faster than a legacy system that keeps running because nobody was assigned to switch it off. Put decommissioning dates in the plan with named owners, and treat any extension as a risk item with a cost attached. The programme ends when the old system is gone — not when the new one is live.

Share LinkedIn X Email