01
Do not start with the rewrite
A rewrite can be the right answer, but it is rarely the safest first move. The first job is to understand the system, the users, the business rules, the integrations, and the parts that create the most operational risk.
Without that understanding, a rewrite can recreate old complexity in a newer stack.
02
Stabilise the delivery path
Modernisation becomes easier when deployment, monitoring, logging, and rollback paths are improved. These capabilities make each future change less stressful and more observable.
Sometimes the best first modernisation work is not a feature. It is the ability to release safely.
03
Choose slices that compound
The best early improvements make the next improvement easier. That might mean isolating an integration, documenting a rule boundary, improving test coverage around a risky workflow, or simplifying a deployment step.
Each slice should reduce risk in the live system while creating better conditions for future work.
04
Protect the business during change
Legacy systems often carry hidden business knowledge. Modernisation should include user validation, rollout planning, fallback paths, and careful communication with the people who rely on the system.
The aim is not to look modern. The aim is to make important software easier to trust, operate, and improve.