Why do modernization projects so often fail to change the numbers?
Because they move the system rather than reduce it. A lift-and-shift to containers, or a rewrite that faithfully reproduces every existing behaviour, arrives with the same service count, the same operational surface and the same headcount requirement. The stack is newer and the bill is the same or higher.
The savings live in the decisions people avoid: which services should not exist, which features nobody uses, which queue exists because of a problem solved three years ago, and which managed service is being paid for twice. Those are uncomfortable conversations, which is exactly why an outside engineer is often the one who can have them.
Where does AI actually help with legacy code?
In comprehension far more than in generation. Reading a codebase nobody remembers writing, mapping call paths and data flow, producing an accurate inventory of what exists and what is dead, and drafting characterisation tests around behaviour before you touch it. That work used to take months of an expensive engineer's time and is now dramatically faster.
Where it helps less than people hope is the rewrite itself. A model will happily reproduce a bad abstraction in a new language. The architectural decisions, what to drop, what to merge, what to leave alone, are still the part that determines whether the project pays for itself.
How do you modernise without stopping the business?
Incrementally, behind the existing interface. New implementations run alongside the old ones with traffic moved in slices, so every step is reversible and nothing depends on a single cutover weekend. Characterisation tests capture current behaviour first, including the behaviour that is technically wrong but that customers now rely on.
Each phase has to stand on its own: a measurable reduction in cost, operational load or delivery time, delivered before the next phase starts. A modernization programme whose value arrives only at the end is a programme that gets cancelled halfway.
What does the assessment actually produce?
An inventory of what runs, what it costs and what it is for. A map of what can be removed outright, merged, or left alone because it works. The infrastructure spend broken down by service with the waste identified. An honest view of which parts are load-bearing and which are just old.
Then a sequenced plan where each phase has a measurable outcome, so you can stop after any of them and still be ahead.
How an engagement runs
| Stage | What happens | Timeline |
|---|---|---|
| Assessment | Codebase and infrastructure inventory, cost breakdown, removal candidates, and a sequenced plan with measurable outcomes per phase | Two to three weeks |
| Phase delivery | Incremental re-architecture behind the existing interface, each phase standing on its own | Scoped per phase |
| Cost engineering | The infrastructure and operational reduction that usually funds the rest of the programme | Runs alongside |
Scoped and priced per phase, so you can stop after any phase and keep the gains. Assessment findings are delivered in writing before any implementation is agreed.