Legacy is not old software. It is software nobody can safely change
Technology gets chosen on build cost. It gets lived with on run cost, and escaped at exit cost, and those two are the numbers that were never in the paper. This practice owns the estate as a whole: what it costs, what it risks, and what can actually be moved.
The bill arrives quarterly, and nobody signed for it
A platform gets chosen on a licence cost and a demonstration. What it actually costs is the integration nobody scoped, the two people who understand it, the release that takes a fortnight because there are no tests, and the vendor's position at renewal once leaving has stopped being plausible.
None of that appears in the business case, and all of it compounds. The estate does not decay evenly either. It decays around the systems everything else depends on, which are precisely the ones nobody wants to touch.
Which is why "we should modernise" is not a plan. The plan is knowing what to rebuild, what to retire, and what is genuinely fine left alone.
Four kinds of work, all of them about what happens next
Each of these is judged on what it costs to live with, not only on what it costs to deliver.
Architecture and platform roadmap
What the estate should look like in three years and the sequence that gets there, with the case for what gets rebuilt, what gets retired, and what is fine as it is.
Data architecture and integration
How data is stored, moved and reconciled across systems. Two reports disagreeing about the same number is an architecture symptom, not a reporting one.
Build-vs-buy and vendor selection
Independent judgement on the major calls and the selection that follows, with run cost and exit terms priced alongside the licence rather than after it.
Technical due diligence
An estate review written for a transaction rather than for the engineering team: what the other side's diligence will surface, found and priced before they find it.
Every recommendation carries three numbers
What it costs to build, what it costs to operate for three years, and what it would cost to get out of. The third is the one that changes decisions and the one almost nobody asks for, because at the point of choosing it feels like planning to fail.
It constrains us as much as it constrains a vendor. A recommendation that only looks good on the build number does not survive its own paperwork here, which is rather the point of writing all three down.
An estate you can see, before a roadmap you can fund
Most engagements here open with an estate view: what runs, what it costs to run, what depends on what, who is able to change it, and where the single points of knowledge sit.
That last one is usually the finding. Systems are rarely the risk on their own. The risk is a critical system with one person who understands it, and that shows up on a dependency map long before it shows up in an incident report.
What comes out is a dependency map with costs on it, enough to sequence a modernisation properly, and often enough to conclude that this year the right answer is containment rather than a rebuild.
Three remits sit inside this practice
Technology strategy, the data blueprint underneath it, and the infrastructure that has to stay up while both change. Which one you need depends on where the pressure is.
CTO / CDO leadership
Architecture, platform roadmap and the build-vs-buy calls, where technology strategy is set.
See the leadershipChief Data Architect
The technical blueprint for how data is modelled, moved and trusted, downstream of the strategy.
See the leadershipFractional CIO
Infrastructure, security posture and the vendor contracts that keep the business running day to day.
See the leadershipStart with the system nobody wants to touch
Most estates have one. Naming it is usually enough to work out whether this is a rebuild, a containment job, or a succession problem.