In practice · 06 of 09
It was quoted at three years, so we deferred it again.
A modernisation makes thousands of decisions about what survives, and today almost none of them are made deliberately.
Nobody chose nine
Somewhere in a long-lived system there is a payment capped at nine invoices, because a print band was a fixed width and nine was what fitted. That is not a policy. Nobody chose it, nobody has defended it, and it has been enforced for two decades. There are thousands of these, and a conventional modernisation carries every one of them forward, because the safest instruction anyone can give is to reproduce the current behaviour.
Ask the business what the new system should do and the answer is usually "the same as the old one". That is a rational answer to an impossible question, and it converts the programme into an expensive way of perpetuating decisions nobody made.
It is rarely the COBOL
The industry conversation is about forty-year-old mainframe code, and that work is real, but it is not where most of the exposure sits. More often the problem is a system built in the last decade that is drowning in frameworks and libraries nobody can patch, with a dependency tree that cannot be upgraded without a rewrite of the parts that touch it. Nobody calls that modernisation, because it does not look old. It carries the same risk and it is growing faster.
Why the three-year quote keeps arriving
A long quote is usually not padding. It is uncertainty made expensive. The party quoting cannot see inside the estate any more clearly than you can, so they size the discovery phase generously and price the risk of what discovery might find. Then the number is too large to approve, the programme is deferred, and the estate becomes a year older and slightly harder.
The way out is not a cheaper quote. It is removing the uncertainty the quote is pricing. If you can say what is actually in there, what is dead, and what genuinely has to survive, the programme changes shape before anyone bids for it.
The order that matters. Retire first, then migrate. Every piece of dead or duplicated logic that survives into the target is paid for three times: once to understand it, once to rebuild it, and then forever to maintain it. The cheapest code to modernise is the code you decide not to carry.
Where AI changes this and where it does not
Code generation has stopped being the constraint. What has not changed is knowing what to point it at. Coding agents work well on code written last month and poorly on the estate that runs the business, because they sample, and sampling cannot tell a business rule from an accident of a record layout. The constraint has moved from writing to understanding, and understanding an estate you have never read is exactly the part that is not yet automated by the tools most organisations have bought.
Integration with what stays is the other place the benefit disappears. A model can produce a component quickly. Making that component live inside an estate with thirty years of accumulated interfaces is where the months go, and it is the part that rarely appears in a pilot.
Common questions
Our programme has already started and stalled. Is it too late?
No, and a stalled programme is often the easier case, because the organisation has already stopped believing the original plan. What it usually needs is not restarting but re-scoping against an evidenced picture of what is actually there, which is a much smaller piece of work than the one that stalled.
Do you deliver the modernisation?
No, and that is deliberate. We are independent of everyone who delivers, and we do not compete with them. Assuring a transition you are also delivering is a position that does not survive a regulator asking about it.
What if a vendor is forcing the move?
Then you have a date and not a choice, which changes the work but not the method. The value moves toward knowing precisely what has to travel, what can be left behind, and what the vendor's own migration path quietly assumes you will re-buy.
When this comes up. Comes up at end of life, when a vendor forces a move, or on a stalled programme that has already spent money.
How it is delivered
Compass to establish what is actually there, Blueprint to sequence it, Canvas where the estate has to be made legible first. Each module is a fixed deliverable behind a go or no-go gate, and the baseline earns the design. The full set of modules is here.
Related situations
- Delivery and change economicsThe cost of not understanding your own systems, made visible against your own records.
- AI enablement on a legacy estateEstablish which parts of the estate are safe to point an agent at, and why the rest are not.
- Sovereign and in-tenant deploymentA qualifying gate rather than an engagement. Nothing crosses the boundary.
Tell us what you are trying to land.
A short conversation about your situation and whether an independent accountable role is the right instrument. If it is not, we will say so. No deck follows automatically.