Out of the Shadow: How UK Firms Can Retire Legacy Systems Without Stalling the Business

The name of this publication offers a convenient metaphor. An eclipse is temporary, and what emerges from it is the same system with the light restored. Most legacy technology estates follow a similar pattern: the capability is still there, but something has been standing between the business and its own systems for far too long.

The question worth asking in 2026 is not whether legacy platforms should be replaced. It is how to do so without inviting the disruption that keeps so many boards opting for another year of extended support.

Why legacy persists, and why the reasons are usually rational

It is tempting to characterise legacy retention as inertia. In practice, the decision to keep an aging platform is often well reasoned at the time it is made. The system works. It contains a decade of business logic that nobody documented. Two or three long-serving colleagues understand its quirks. A migration would consume the same team that is currently keeping the lights on. And the last major IT project, whatever the vendor promised, overran.

There is also the question of embedded customisation. A finance system modified over fifteen years to match a company's exact process is not easily replaced by a standard product, because the standard product will require the company to change instead. That is an organisational problem dressed as a technical one, and it is the single most common reason modernisation programmes stall.

What standing still actually costs

The counter-argument is rarely presented in financial terms, which is why it loses. A credible total cost of ownership model for a legacy platform should include:

• Extended vendor support premiums, which typically rise sharply once mainstream support ends
• Patching and security workarounds, often absorbed silently by the infrastructure team
• Licensing for middleware, database versions and integration tools that exist only to keep the system connected
• Manual re-keying and reconciliation between systems that should talk to each other
• Recruitment premium and key-person risk for scarce skills, including COBOL and older ERP specialisms
• Business cost of the workarounds staff have built around the system, which rarely appear in any IT budget

When those lines are added together, the comparison changes. The question shifts from what a migration costs to what the current arrangement is already costing each year.

Start with a map, not a plan

The most common failure in modernisation is beginning with a target architecture. Begin instead with an inventory. For each system, record what it does, who depends on it, what data it holds, which interfaces it uses and which processes would stop within a day of it going offline.

Dependency mapping is unglamorous and disproportionately valuable. In most mid-sized UK organisations it reveals a small number of systems carrying a disproportionate share of business risk, and a longer tail of applications that could be retired with very little effort.

Score for risk and value, not for age

A simple two-axis assessment is sufficient for most purposes. On one axis, place the business risk of failure: regulatory exposure, revenue interruption, safety, customer impact. On the other, place the business value of modernising: efficiency gain, integration benefit, access to data.

Systems that are high risk and high value justify early attention. Systems that are low risk and low value should be switched off, which is often the fastest available win and requires no procurement at all. Systems that are high value but low risk make good pilots. Systems that are high risk and low value are the awkward middle, and usually need an interim mitigation before replacement.

The strangler approach: incremental beats big bang

Large, single-phase replacements concentrate risk into a window where everything must work at once. The alternative, widely used and rarely regretted, is to place a new capability alongside the old system and move functionality across in slices, retiring the old component once its replacement has proven itself.

Practical first moves that deliver visible benefit within a quarter include:

• Placing single sign-on and multi-factor authentication in front of a legacy application, which improves security posture without touching the application itself
• Building a read-only reporting layer on a modern data warehouse so that staff stop extracting spreadsheets from a system that was never designed for it
• Wrapping the legacy system in an API so that newer tools can consume its data without custom point-to-point integration
• Retiring unused licences and dormant modules, which frequently funds the next stage

None of these is a transformation. Each one reduces risk, demonstrates progress and builds the internal credibility needed for the harder phases.

Funding the change in terms finance will accept

A business case that leans on future agility tends to be treated as an aspiration. A business case that quantifies current spend, names the support end date and models the cost of a forced migration at short notice tends to be acted upon. Include the cost of doing nothing explicitly, and set the payback period in months rather than in strategic benefit statements.

Where the platform is industry-specific, it is also worth testing the market properly. Several UK sectors have seen new entrants over the past two years, and a competitive process is itself a source of negotiating leverage with an incumbent vendor.

People, not just platforms

Change management is where well-designed migrations most often lose momentum. Two practices help. First, identify the colleagues who hold undocumented knowledge of the system and involve them early as paid contributors to the mapping work rather than as obstacles to be managed. Second, train in the workflow rather than in the software. Staff do not need to learn a new interface; they need to complete the same task in fewer steps, and they will judge the project on that basis.

Decommission with care

Retiring a system is a data decision as much as an infrastructure one. Under UK GDPR, personal data held in a legacy application remains subject to retention limits and subject access obligations until it is properly dealt with. Before switch-off, confirm what must be migrated, what must be archived in a readable format, and what should be deleted. Check contracts for exit assistance clauses and for any notice periods that have been quietly auto-renewing.

Composite case notes

The patterns below are illustrative composites, drawn from accounts commonly reported by UK resellers and integrators over the past 18 months.

A West Midlands manufacturer running a 2005-era ERP alongside modern finance software replaced only the reporting and integration layer first. Reporting time fell from three days to under an hour, and the credibility gained funded a full replacement eighteen months later.

A Yorkshire professional services firm found that four of its eleven core applications were used by fewer than five people each. Three were retired within a quarter, removing licence costs and a persistent patching burden at effectively no project cost.

A Scottish logistics operator kept its legacy transport system in place but placed authentication and API access in front of it, buying two years of breathing space while a replacement was procured at a sensible pace rather than under duress.

A ninety-day starting sequence

Weeks one to three: inventory and dependency mapping. Weeks four to six: risk and value scoring, plus a first pass at total cost of ownership. Weeks seven to nine: identify two quick wins and one candidate for a strangler pilot. Weeks ten to twelve: build the business case with the cost of inaction priced in, and take a decision about what will be switched off this year.

None of that requires a transformation programme, a steering committee or a new job title. It requires a list, a spreadsheet and the discipline to retire one thing before buying another.