How UK SMEs are weighing the cost of modernising legacy software in 2026
A finance director at a 60-person London engineering firm spent most of last quarter chasing a number. The firm’s invoicing system, written in a framework the original developer no longer touches, had cost £18,000 in unplanned support fixes since January. Half of those fixes were the same problem appearing in different parts of the codebase. The board wanted to know whether the right call now was another six months of patching, or putting a budget line in front of them for replacement. The conversation that started in the FD’s office finished, three weeks later, with a board paper that traded off three years of compounded support cost against a six-month bespoke build. The board approved the rebuild on the second pass. Nobody around the table thought the timing was wrong.
This is the picture across more UK SMEs than the headline figures suggest. The systems running finance, customer records and operations were built or bought when the business was a different shape. Some have been outgrown. Some are running on infrastructure their suppliers have wound down. A few are working fine but cost more to maintain each year than the original build did to ship.
What the numbers say in 2026
The Department for Science, Innovation and Technology’s own data flags 28% of central government IT systems as legacy, with around a quarter of those rated red risk. The SME picture is harder to pin down at that resolution, but two figures from the 2025 Cyber Security Breaches Survey sit alongside it. 43% of UK businesses reported a breach in the previous twelve months, and the average cost to a medium business of the most disruptive breach was £10,830. For a finance director already balancing a tight cost base against software contracts that drift up at renewal, those numbers reframe what “we will look at it next year” actually costs.
There is a separate cost that does not show up in any breach survey, and it is the one most SME boards underestimate. Skilled developer time spent on workarounds. Lost productivity in the operations team that has to work around a system rather than with it. The slow accumulation of fixes that nobody has the bandwidth to consolidate. A 2025 Make UK survey put the share of mid-sized manufacturers running at least one mission-critical system on unsupported software at 39%. Most of those firms know which system it is. The question is whether to act this year or absorb another year of support cost.
Three financial questions before any rebuild
Before any modernisation budget gets a number against it, there are three questions worth answering for each system in scope. Is this workflow still earning its keep, or has the business changed shape around it? If it is still doing useful work, does the user-facing piece work and only the platform underneath need lifting? Or has the technology stack itself aged out far enough that any meaningful change costs nearly as much as a clean rebuild?
The first question retires more systems than people expect. The second points towards rehost or replatform work, which is the cheapest modernisation route when it applies. The third is the one that takes a finance committee paper, because the answer is rebuild and the cost shape is larger than the alternatives.
For SMEs weighing what to do with each system, a modernise-versus-maintain decision framework works better than a single answer applied across the estate. The right move for the finance system might be retire-and-replace. For the CRM it might be a six-month rehost onto a supported cloud platform. For a customer-facing portal it might be a refactor that keeps the data model and replaces only the user interface. Each of those has a different cost shape and a different payback window, and none of them is the same conversation as a full transformation programme.
Bespoke or off-the-shelf
When the answer is replacement, the SME-sized question is whether to buy something off the shelf or build something to fit. The choice is rarely all one or the other. The firms that get good value out of bespoke development have done a specific thing: they have identified the workflow that is particular to their business and provides a competitive edge, and put bespoke software around that workflow. Off-the-shelf gets used for the supporting functions where industry-standard processes already do the job.
The financial case for bespoke rests on two things. First, the workflow in question is one the business has built a competitive position around, and configuring an off-the-shelf product to match it produces a worse result than building it directly. Second, the build is scoped tightly enough that the total cost sits in a sensible relationship to three years of off-the-shelf licence and customisation fees. When both of those tests pass, the bespoke build pays for itself inside the support window of the alternative, and the conversation with the finance committee gets straightforward.
Local delivery and the cost of slippage
When a software project has a fixed external date behind it, whether that is a compliance deadline, a board commitment or a contract renewal, working with a delivery team in the same time zone and the same contract jurisdiction reduces friction in a way that shows up in the budget. Decisions get made in the same working day. Code reviews happen against the same calendar. Disputes about scope, when they arise, settle under English law without the cost overhead of cross-border arrangements.
This is the case for a London-based development team when the work has a hard deadline and the cost of slippage is concrete. The headline rate of an offshore alternative is straightforward to compare. The two things SME finance directors should weigh alongside it are the value of speed-of-decision when something goes wrong, and the cost of being unable to walk into a room with the team if a release is in trouble. Both show up in the budget eventually. The headline day rate does not capture either.
Where to start this quarter
Start with a list. Every system in the business that authenticates users or stores customer data, with three columns against each: support contract status, last meaningful update, and annual run cost including the time the operations team spends working around it. The systems with rising run costs and lapsed support contracts are the ones to bring to the next finance meeting. The rest can wait until the next planning round.
That list is enough to take to a conversation about scope and sequencing without committing the business to a transformation programme it does not need. This kind of audit surfaces the systems that need real attention. The work that follows can be sized to the business and the budget the board has signed off.