Legacy System Modernisation
What we've learned so far
Old software does not announce its cost. It appears as a roadmap that keeps slipping, a release nobody will touch on a Friday, an integration that cannot be built because the system has no way to expose the data, and a hiring problem because good engineers decline the work. Modernisation converts that cost back into capacity. What you get is not really a new system, it is a business that can make changes again and integrate with anything.
The usual approach fails, and this is the best-documented finding in the field. Full rewrites are reported to fail or underperform between 70 and 88 percent of the time, and the causes are rarely technical: lost sponsorship, unclear ownership, growing scope and people leaving with knowledge nobody wrote down. A failed programme consumes 18 to 36 months, after which you still have the original system, now further behind. Difficulty is decided by knowledge. The behaviour that matters most is usually undocumented: a defect operations has worked around for years, a reconciliation done in a spreadsheet, a rule that applies only to older records.
We modernise behind the running system, one capability at a time, with both paths live until the numbers agree and traffic routed back in seconds if a slice misbehaves. Any serious firm now describes that approach. What changed is that AI removed its only drawback. Incremental was always safer and always slower, and slowness is what sold rewrites to boards. Reading an unfamiliar codebase and generating characterisation tests took a discovery team a quarter and now takes days, so the safe path is no longer the expensive one. What AI does not do is decide which behaviour is worth keeping, or hold sponsorship together for eighteen months. Those are the reasons these programmes fail, and they remain human.
What this can involve
Mapping URL redirects
Reviewing security and compliance
Code Refactoring and Technical Debt
Cloud Infrastructure Setup
Technical Discovery
How we work
Understand the current system
Reading the codebase and talking to the people who work around it. The behaviour that matters is usually undocumented: a defect operations has adapted to, a rule that applies only to older records, a reconciliation done in a spreadsheet.
Pin the behaviour down in tests
Characterisation tests that capture how the system behaves today, including the parts that are technically wrong. They are what let you change anything safely afterwards.
Agree the order of slices
Which capability moves first, and what each one has to prove before the next begins. Starting where the pain is loudest is rarely the same as starting where the risk is lowest.
Run both paths side by side
Old and new live together, compared on real traffic until the numbers agree. Anything that misbehaves routes back in seconds rather than requiring a rollback.
Retire the old slice and move on
Only once the replacement has been carrying real load. The programme delivers value continuously rather than at the end, which is also what keeps sponsorship alive.
Where this isn't the right fit
If the system is small enough to rebuild in a few months, rebuild it. Incremental modernisation earns its place on systems too large or too central to switch off, and the machinery it requires is overhead on anything smaller.
If nobody internally can answer questions about the system, the first step will stall. We can read the code. We cannot tell you which of its odd behaviours the business has come to depend on. And if there is no sponsor who will still be there in a year, do not start. These programmes fail on lost sponsorship and unclear ownership far more often than on anything technical, and no approach survives that.
