Legacy systems rarely fail dramatically. They keep working, quietly, while becoming more expensive and more dangerous every year - unsupported dependencies, a shrinking pool of people who understand them, and an ever-growing list of things the business wants that the system cannot do.
Modernisation is the work of resolving that. The hard part is not the technology; it is choosing the right strategy per application and sequencing the work so the business keeps running.
First, define what "legacy" means in your case
Age alone is not the problem. A stable, well-understood, secure system that meets business needs is not a modernisation candidate regardless of how old it is. An application is genuinely legacy when it exhibits some combination of:
- Running on unsupported platforms, runtimes or operating systems with no security patches
- Depending on skills that are scarce or absent in your team
- Being impossible to change safely because there are no tests and no documentation
- Blocking business initiatives - it cannot expose an API, support mobile, or handle expected load
- Failing compliance or audit requirements
- Consuming a disproportionate share of the IT budget just to stay upright
Be specific about which of these apply, because the answer determines the strategy. A system that is merely old needs different treatment from one that is a live security liability.
Build the inventory before the plan
Most modernisation programmes go wrong because they start with a technology decision instead of an assessment. Before choosing anything, catalogue every application with:
- Its business criticality and which processes depend on it
- Its integrations - what calls it, and what it calls
- Its technology stack and support status
- Its annual run cost, including licences, infrastructure and maintenance effort
- Its known security and compliance gaps
- Who actually understands it
That last point is frequently the real constraint. If one person holds all the knowledge of a critical system, your first priority is capturing that knowledge, not migrating anything.
Pay particular attention to integrations. Undocumented dependencies are where modernisation projects break - a nightly batch job nobody remembers, a report a regulator requires, a spreadsheet that pulls directly from the production database.
The six strategies
1. Retain
Do nothing for now, deliberately. This is a legitimate choice for stable systems with low business impact, and it is far better than modernising something just because it is on the list. Revisit on a defined schedule.
2. Retire
Decommission it. Genuinely useful in most portfolios - organisations routinely maintain applications whose function has been superseded or whose user base has dwindled to a handful of people who could be served another way. This is the cheapest possible modernisation and it is almost always underused.
3. Rehost (lift and shift)
Move the application to modern infrastructure - typically cloud - with minimal code change. Fast and relatively cheap, and it solves hardware end-of-life and data centre exit problems. It does not solve architectural problems: a monolith with no tests is exactly as hard to change after rehosting, and cloud bills for un-optimised workloads can exceed the original hosting cost.
4. Replatform
Move it, and make targeted changes along the way - swap a self-managed database for a managed service, containerise the application, replace the file system with object storage. A pragmatic middle ground that captures real operational benefit without a rewrite.
5. Refactor or re-architect
Restructure the code and design while preserving behaviour: break apart the monolith, introduce proper interfaces, add a test suite, separate concerns that have grown together. This is where the durable benefit lives, and it is also the most expensive and the most technically demanding. It requires disciplined, incremental work and a genuine test safety net.
6. Replace or repurchase
Retire the custom system and adopt a commercial product. The right call when the functionality is not differentiating - payroll, accounting, generic CRM. The trap is configuring or customising the product so heavily to match legacy processes that you have built a new legacy system with worse economics.
Why big-bang rewrites usually fail
The instinct to start clean is strong and almost always wrong at portfolio scale. Full rewrites fail for structural reasons, not because the engineers were bad:
- They take longer than the business will tolerate. Multi-year projects outlive the sponsors, the budget cycle and sometimes the strategy that justified them.
- Feature delivery freezes. While the rewrite runs, the old system still needs changes, so you maintain two systems and pay twice.
- Undocumented behaviour is invisible until it breaks. Decades of accumulated business rules, edge cases and regulatory quirks are encoded in that code. Nobody can list them, but users notice immediately when they disappear.
- There is no value until the very end. A project that delivers nothing for two years has no way to demonstrate progress or course-correct.
The strangler pattern: incremental replacement
The lower-risk alternative is to grow the new system around the old one and retire the old one piece by piece. In practice:
- Put a facade in front of the legacy system - an API gateway or proxy through which all traffic flows.
- Pick one bounded capability and build it properly in the new architecture. Choose something valuable but not the most dangerous part of the system.
- Route that capability's traffic to the new implementation through the facade, with the ability to route back instantly if something goes wrong.
- Run both in parallel initially, comparing outputs on real traffic to catch behavioural differences before they matter.
- Repeat, capability by capability, until the legacy system has nothing left to do - then retire it.
The advantages compound: value is delivered continuously, every step is individually reversible, the team learns and adjusts, and the business never faces a single high-stakes cutover. It is slower in theory and considerably faster in practice, because it does not fail.
Data is usually the hardest part
Legacy data is rarely clean. Expect inconsistent formats, duplicate records, values that violate their own schema, and fields repurposed years ago for something other than their name. Plan for a distinct data workstream covering profiling, cleansing rules, mapping, a reconciliation process that proves nothing was lost, and a rollback plan.
Where old and new must run simultaneously, decide explicitly which system owns which data and how synchronisation works. Bidirectional sync without a clear source of truth produces conflicts that are extremely difficult to unpick.
Making the business case
Technical debt arguments do not secure funding. Cost and risk arguments do. Quantify the annual cost of the status quo:
- Licences, infrastructure and support contracts for obsolete technology
- Engineering hours spent on maintenance rather than new capability
- Cost of unplanned downtime, based on actual incident history
- Security and compliance exposure from unsupported components - including realistic breach and penalty scenarios
- Revenue or efficiency opportunities that are blocked today because the system cannot support them
Present that annual figure against the modernisation investment and a phased delivery plan. A programme that delivers measurable improvement every quarter is far easier to fund than one that promises transformation in year three.
Practical sequencing
Start where risk is high and blast radius is small. The first project should be valuable enough to matter and contained enough that failure is survivable - it establishes your patterns, tooling and delivery credibility.
Do not start with the most critical, most entangled system, however tempting. Build capability on something smaller first, then apply it where the stakes are highest.
If you are weighing up options for a specific system, our team works through exactly this kind of assessment - see our modernisation service or get in touch.