The instinct to replace a legacy system is understandable. The system is slow, expensive to change, poorly documented and disliked by the people who use it. A rewrite promises a clean start. The problem is that the legacy system is rarely just software; it is a set of business rules, data definitions, integrations and workarounds that the organisation has built around for years.
The rewrite trap
A large replacement programme concentrates risk. It asks the organisation to define the complete target state, build it, migrate the data, retrain the users and cut over — often while the old system is still changing. Every month of delay increases the pressure to compress testing and migration.
The failure is not usually technical. It is that the new system has to reproduce decades of implicit behaviour that nobody fully documented. The group discovers the gaps during migration, when the cost of change is highest.
Find the invariants before the target
Before deciding what to replace, identify what must remain true while the change happens. Which data is the system of record? Which interfaces cannot change? Which reports are legally required? Which operational workarounds are actually compensating for a business rule that nobody has written down?
These invariants become the guardrails for sequencing. They tell you what can move first, what must be wrapped, and what must wait until the organisation is ready.
Sequence by capability, not by layer
A modernisation plan organised by technical layer — database first, then services, then UI — tends to produce a long period with no visible benefit. A plan organised by business capability produces usable outcomes earlier and reduces the size of the final cut-over.
The strangler pattern is useful here: place a stable interface in front of the legacy capability, route a narrow slice of behaviour to the new implementation, and expand the slice as confidence grows. The legacy system remains available until the new path has proven itself.
Treat data and contracts as the hard part
The UI is rarely the constraint. Data ownership, identity, historical records, integration contracts and reporting are where modernisation becomes difficult. A target architecture that does not resolve those questions is a diagram, not a plan.
We prefer to define the data model and integration contracts early, even if the implementation is incremental. That gives the programme a stable semantic core while the surrounding capabilities change.
What we recommend
- Document the invariants: systems of record, mandatory interfaces, statutory reports and undocumented business rules.
- Choose a first slice that produces an operational benefit, not just a technical proof.
- Put a stable interface in front of the legacy capability before moving behaviour.
- Define data ownership and integration contracts before the first migration.
- Fund the sequence, not a single big-bang release; include the operating-model changes in the plan.
Where we disagree
We do not accept the common claim that every legacy system should be rewritten. Some systems are stable, well understood and cheap to operate; wrapping and integrating them may be the better decision. We also do not accept that lift-and-shift is always wrong. If the immediate constraint is data-centre exit, a controlled relocation can create the time needed for a proper modernisation sequence.
A practical test
Take the system you are planning to replace and write down the five things that must remain true on the day after cut-over: the data that must reconcile, the interfaces that must still work, the reports that must still be produced, the people who must still be able to do their job, and the evidence an auditor would ask for. If those five things are not explicit, the modernisation plan is not ready. If they are explicit, you have the beginning of a sequence.