Why legacy applications are left alone
Many organisations have at least one: the application that runs something important, was written a long time ago, is understood by two people and is quietly blocking other initiatives. Nobody wants to be the person who breaks it.
The scale of the problem has been measured in the public sector. The UK government’s State of Digital Government Review, published in January 2025, estimated that 28 per cent of central government systems were legacy in 2024, up from 26 per cent the year before, and that legacy systems cost three to four times more to maintain than modern alternatives. Private sector estates are not measured in the same way, though the same pattern is familiar in many insurance and banking estates.
Why are you migrating? Be specific
Programmes often fail because the objective was never sharp enough to make trade-offs against. ‘Modernisation’ is too broad to do that. These objectives are specific enough:
- The platform is out of support, or will be: a security and compliance problem with a date attached.
- The skills are disappearing, and replacements are scarce and expensive.
- It blocks change. Every new requirement takes months, so the business has stopped asking.
- It cannot integrate. Every connection is a nightly file transfer and a reconciliation.
- Running cost is rising, or it fails audit: no modern authentication, no meaningful audit trail.
Write down which of these apply and which matter most. That list tells you whether you need a rehost this year or a rebuild over three, and it is what success is measured against.
What are the legacy application migration options?
The most widely used taxonomy is the set of ‘R’ strategies. Gartner published five in 2011; AWS extended the list to seven and it is now the common vocabulary. In rough order of effort:
Retire. Some applications are used by four people for a report that could be produced another way. This is the cheapest outcome, and it is available more often than people expect.
Retain. Keep it where it is, deliberately, with a review date.
Rehost. Move it unchanged onto supported infrastructure, on-premises or cloud. Lowest risk and fastest, and right when the driver is platform support or hardware cost.
Relocate. Move a whole virtualised environment to a different host or cloud without changing the servers in it. A variant of rehost that moves many applications at once.
Replatform. Modest changes so it runs on a modern stack, such as a supported database version or containers.
Repurchase. Move to a packaged or SaaS product. The risk is discovering late that the part of your process the package does not support is the part that differentiates you.
Refactor or re-architect. Restructure or rewrite the application, which is where custom application development comes in. Highest effort and highest potential value.
Most estates need several of these. Northdoor’s legacy migration and management process assesses each application against six criteria before recommending a route: technological conformance, architectural conformance, support requirements, functional fit, volatility and business significance.
Why do single-cutover rewrites go wrong?
A rewrite has to replicate everything the old system does before either can be switched off. Meanwhile the business keeps needing changes, which have to be made twice. The scope turns out larger than documented, because years of business rules are embedded in the code. And go-live is a single, hard-to-reverse event.
Martin Fowler, who coined the term for the alternative, describes the rewrite plan as one his colleagues have seen ‘go down in flames most of the time’: replacement takes too long, existing behaviour is hard to establish, and much of it turns out not to be wanted anyway.
A well-known UK example is TSB. In April 2018 it moved its customer data onto a new IT platform, which failed on arrival and disrupted branch, telephone, online and mobile banking. In December 2022 the Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) fined TSB £48.65m, finding that it had not adequately organised and controlled the migration or managed its outsourcing risk, and in April 2023 the PRA fined the former chief information officer £81,620 under the Senior Managers and Certification Regime. It was a platform and data migration rather than a code rewrite, but it shares the defining risk: a single cutover that is hard to reverse.
In a rewrite, the specific problem is the rules nobody remembers: a rating condition that treats policies incepted before 2009 differently, for example, which nobody in underwriting knows about until a fortnight after go-live.
What is the incremental pattern that works?
The approach with the better record is to grow the new system around the old one and move behaviour across gradually, which is where the strangler fig name comes from:
- Put an API or integration layer in front of the legacy system, so consumers talk to the interface rather than the application.
- Pick the least risky slice, such as a report or a lookup service, and implement it in the new stack behind the same interface.
- Run both on the same inputs and compare outputs automatically. This is how undocumented rules are found while the old system is still authoritative.
- Cut over that slice when outputs agree consistently. If it fails, route back to the old path.
- Repeat with larger slices, and retire the old system when nothing routes to it.
Every step is reversible, value arrives continuously, and the programme can be paused without writing off work done. The automated build, test and comparison it depends on is the same pipeline that DevOps practices put in place. The cost is running two systems in parallel for a period, which belongs in the business case.
What else reduces migration risk?
- Capture real inputs and outputs from the running system. They become the test suite and the basis of the automated comparison.
- Freeze non-essential change on the old system during transition.
- Migrate data separately and early, with reconciliation. Data quality problems the old system tolerated frequently break the new one.
- Resist scope addition. ‘While we are rebuilding it, could we also’ is how a 12-month programme becomes a 30-month one.
- In a regulated firm, check whether the application supports an important business service. If it does, the plan must keep that service within its impact tolerance under the FCA and PRA operational resilience rules. A move to cloud can also be a material outsourcing that PRA-regulated firms must notify to the PRA under SS2/21.
What this means for your organisation
The application nobody wants to touch will be dealt with eventually, on your timetable or the vendor’s. A precise reason to move, an honest assessment of the options and an approach where each step can be reversed make it a programme that can be managed.
Northdoor supports the platforms where many insurance and banking systems still live, led by RPG on IBM Power Systems and SQL Server, alongside .NET, PowerBuilder, Visual Basic and Access. We support the incremental approach with assessment and development, and afterwards with ongoing management of the applications and the SQL Server estates underneath them.