Legacy software development cost in the UK (2026)

Why keeping it running quietly costs more

The comparison that matters isn't "modernise vs. do nothing for free" — it's modernise vs. keep paying to stand still. Old systems don't sit there for nothing. They soak up the budget you'd rather spend on the things customers actually notice.

Deloitte's CIO research has technology teams spending roughly 55% of their budget just sustaining what already exists, and only about 19% on genuinely new technology. Gartner puts the share going to technical debt at around 40%. Stripe's Developer Coefficient study found developers lose about 42% of their week to maintenance and working around old code rather than building anything. And at the extreme end, the UK government alone spends an estimated £2.3 billion a year keeping outdated public-sector technology alive.

None of those numbers show up as a line item called "legacy". They show up as slow releases, a team that can't recruit because no one wants to work on the old stack, and a security posture that gets harder to defend every year. When you're weighing a modernisation quote, that ongoing drain is the baseline you're comparing against — not zero.

What actually drives the price

Two systems that look similar from the outside can differ by a factor of five once you're inside them. A few things move the number more than anything else, and it's worth knowing them before you read a quote.

Data migration is the one people underestimate most. Moving code is tractable; moving twenty years of accumulated data — with its duplicates, its undocumented edge cases and the one field three departments each use to mean something different — is where projects quietly bleed time. If a quote treats migration as a rounding error, that's a warning sign, not a saving.

The rewrite premium is the other big one. A ground-up rewrite can cost three to five times a careful, incremental modernisation, and more than 70% of large rewrite projects overrun their budget or timeline. Sometimes a rewrite is genuinely the right call. But it should be a decision you've argued yourself into, not the default because the old code looks ugly.

Rebuild, refactor or just replatform?

Most teams reach for "rebuild" too quickly. The instinct is understandable — the old code is painful and a clean slate sounds liberating — but a rebuild throws away years of hard-won business logic, including the ugly bits that encode real rules. The cheaper, lower-risk path is usually to modernise in stages: rehost to get off unsupported infrastructure, then replatform or refactor the parts that actually hurt.

A rough way to choose: if the system still does the right things but runs on infrastructure you can't support or secure, replatforming buys you years for a fraction of a rebuild. If the code is so tangled that every change risks breaking three others, refactoring the worst modules pays for itself. A full rebuild earns its keep when the business needs have genuinely moved on from what the system was designed to do — not merely when the code offends you.

This is also where senior judgement matters more than raw build capacity. The expensive mistakes in legacy work are strategic — rebuilding the wrong thing, or migrating data no one validated — and they're made in the first few weeks, long before most of the money is spent. Our own view, from building and operating our own AI products in regulated and consumer-facing sectors, is that the assessment phase is the cheapest insurance you'll ever buy on a project like this.

Where AI changes the maths

AI tooling has started to bend the cost of the grindier parts of legacy work. Reading and documenting an undocumented codebase, generating a first pass of tests around code that has none, translating one language or framework to another, mapping data between old and new schemas — these used to be slow, manual and expensive, and they're exactly what modern coding models are good at.

The honest caveat: AI speeds up the mechanical work, not the judgement. It won't tell you which business rules still matter, and it will happily reproduce a bug faithfully if you let it. Used well, on the right tasks and with senior engineers checking the output, it can take a meaningful slice off a modernisation bill — particularly on the test coverage that makes changing old code safe in the first place. Used as a shortcut around review, it just moves the cost downstream. Our AI legacy modernisation and AI-driven development pages go into how we apply it.

Day rates, and buying the work well

If you're costing a team rather than a fixed-price project, contractor day rates are the building block. In 2026 the median UK software developer contract rate sits around £500 a day (ITJobsWatch); Java work runs a little higher at about £525, and roles that specifically call for legacy-application experience command around £575, rising to roughly £800 in London. Senior, scarce skills — mainframe COBOL, older .NET, niche embedded stacks — sit above those medians because the people who know them are retiring faster than they're replaced.

A few things make a legacy engagement go well:

• Pay for a proper assessment before you commit to a build — a £12k–£40k roadmap that prevents one wrong turn pays for itself many times over.
• Insist on a working test safety net early, so behaviour can be preserved as code changes.
• Modernise in slices that each ship something, rather than a big-bang cutover you can't reverse.
• Get data migration scoped and dry-run early, not left to the final fortnight.

And the red flags: a fixed price quoted before anyone has read your code, a plan that jumps straight to a rewrite, and migration treated as an afterthought. Any of those, and the £40k you thought you were spending has a habit of becoming £400k.