Legacy system modernisation: finding out what you have, the options from retain to replace, and moving off it one function at a time
A method for modernising a legacy system: assessing what it really does and what is really wrong with it, the options from retain and rehost through refactor and rebuild to replace and retire, why incremental replacement beats a big bang and how the strangler fig pattern works, migrating the data, and the checks before the old system is switched off.
Key takeaways
- Modernising a legacy system starts with finding out what it actually does, who depends on it and what is actually wrong with it. 'It is old' is not a problem statement, and the undocumented report someone runs every Monday is a requirement.
- The options run from retaining it, through rehosting, replatforming, refactoring and rebuilding, to replacing it with a product or retiring it. Each fits a different problem, and the right one is often different for different parts of the same system.
- Big bang replacements fail more often than they succeed. Moving one function at a time behind a routing layer, the strangler fig pattern, keeps the business running on a working system the whole way through.
- The data is usually the hardest part. Fields reused for other purposes, rules that live only in the code and history that has to survive all need finding before the migration, not during it.
- A legacy system is not retired until every function is accounted for, the data is reconciled, the outputs match in a parallel run, the integrations are repointed and its costs have actually stopped.
A maintenance department runs its shutdown planning on an application written fifteen years ago by an engineer who has since retired. It runs on a server under a desk, on a database version out of support, and it does three things nothing else on site does. Everyone agrees it has to be replaced. Two projects to replace it have started and stopped, both because they tried to replace everything at once and found, part way through, functions and integrations nobody had listed.
This guide sets out a method for modernising a legacy system: finding out what it really does and what is really wrong with it, the options from retaining it to replacing it, why incremental replacement usually beats a big bang and how the strangler fig pattern works, how the data is migrated, and what has to be true before the old system is switched off. It sits beside the guides on choosing a technology stack, taking a prototype to production and software for 24/7 operations.
Find out what you have
The first job is to find out what the legacy system actually does, and the documentation is rarely the answer. Watch people use it. List every function, every report, every export and every system that reads from it or writes to it. Long-lived systems collect uses nobody wrote down: the spreadsheet fed from a nightly export, the report the finance team runs at month end, the field that was repurposed years ago to hold something its name does not describe. Each of these is a requirement for whatever comes next.
Then name what is wrong with it. An unsupported platform, a security exposure, one person who understands it, poor performance, rising cost, or a capability the business needs and the system cannot give. The problem decides the option. A system whose only problem is the server it runs on needs new hosting, not a rebuild.
| Find out | What it covers | What to watch |
|---|---|---|
| What it does | Every function people use, including the ones nobody wrote down | Watch people use it. The undocumented report run every Monday is a requirement |
| Who depends on it | Users, other systems reading its data, exports, spreadsheets fed from it | The integrations are usually the hard part |
| What is wrong with it | Unsupported platform, security, a single person who understands it, performance, cost, a missing capability | Name the problem. 'Old' is not one |
| Its data | Volume, quality, the meaning of each field as used, and the history that has to survive | Fields reused for other purposes are common in long-lived systems |
| The rules in the code | Calculations, validations and workflows the business relies on | Often the only record of a rule is the code |
| What it costs to keep | Licences, hosting, support, and the risk of the platform failing | The baseline any option is compared against |
The options
The options are commonly described as a list of words starting with R, and the list is useful because it puts the cheap, low risk options beside the expensive ones. Retaining a system with a plan to look again is a legitimate choice. Rehosting moves it to supported infrastructure without changing it. Replatforming makes small changes, such as a newer database or runtime. Refactoring restructures the code while keeping its behaviour. Rebuilding writes it again on a current stack. Replacing moves the job to a product, which suits needs that many organisations share, such as a CMMS. Retiring switches it off.
Different parts of one system often suit different options. The core records might move to a product, the one calculation the business depends on might be rebuilt as a small service, and the rarely used reports might be retired. The ISO/IEC 25010 quality model is a useful checklist for comparing options on more than function: reliability, security, maintainability and how well each fits the systems around it.
| Option | What it means | Fits when |
|---|---|---|
| Retain | Leave it, with a plan to look again | It works, the risk is acceptable and the money is better spent elsewhere |
| Rehost | Move it as it is to new infrastructure | The hardware or hosting is the problem, the application is not |
| Replatform | Move it with small changes, such as a newer database or runtime | The platform is out of support but the code is sound |
| Refactor | Restructure the code without changing what it does | The behaviour is right but the code is hard to change |
| Rebuild | Write it again on a current stack, keeping the scope | The behaviour is right, the code cannot be saved, and nothing off the shelf fits |
| Replace | Move to a product, configured to fit | The need is common and a product does it well |
| Retire | Switch it off and move the few uses that remain | Little still depends on it |
Moving off it one function at a time
A big bang replacement cuts over every function, integration and report on one day, and anything missed is found by the users in production. The strangler fig pattern spreads that risk. A routing layer is put in front of the legacy system, which can be as simple as the menu users open or as formal as an API gateway. Functions are rebuilt one at a time, and as each is ready the routing layer sends its requests to the new system. Users see one system throughout, the business runs on working software the whole way, and each step is small enough to test in use and reverse if it fails.
The order matters. Functions that are self-contained and well understood go first, to prove the new platform and the routing. Functions that share data heavily with others go once the data they depend on has a clear home. While both systems are running, each piece of data has one system of record, and the other reads it rather than keeping its own copy. That rule, kept strictly, is what stops two systems drifting apart.
1Today
Users
Routing layer
Legacy
Work requests
Scheduling
Reporting
Costing
Integrations
New
Every function in the legacy system, and a routing layer put in front of it
2Part way
Users
Routing layer
Legacy
Scheduling
Costing
Integrations
New
Work requests
Reporting
Functions move one at a time. Users see one system, the routing layer decides which answers
3Retired
Users
Routing layer
Legacy
Switched off
New
Work requests
Scheduling
Reporting
Costing
Integrations
The last function moves, the data is archived and the legacy system is switched off
While both systems run, every piece of data has one system of record. Two copies that both accept edits will disagree within a week.
The data
The data migration is usually the hardest and least visible part. Profile the data first: how much, how clean, and what each field actually holds as used, which can differ from what its name says. Find the rules that live only in the code: a calculation, a validation, a status that changes another record. Then map every field to the new system with its transformation, and decide what history moves and what is archived in a readable form.
Run the migration repeatedly in test before running it for real, and reconcile every time: record counts, totals that should match, and a sample of records checked field by field. Each run finds something. The goal is a migration that has been run enough times that the real one is a repeat, not a first attempt. Master data quality problems found here are cheaper to fix in the source before migration than in the new system after it.
Before switching it off
A legacy system that is not quite switched off keeps costing money and keeps being used for the one thing the new system does not do. Retirement has a checklist, and it is worth agreeing at the start what the checklist is. A parallel run, with both systems taking the same inputs for a set period and the outputs compared, is the strongest single test that the new system does what the old one did. Differences are either fixed or explained and accepted by the people who own the output.
| Check | What has to be true |
|---|---|
| Every function accounted for | Each function is moved, replaced or deliberately dropped, with the user who agreed |
| Data migrated and reconciled | Record counts, totals and a sample of records checked against the source |
| Parallel run passed | Both systems run on the same inputs for a set period and the outputs match, or the differences are explained |
| Integrations repointed | Every system that read from or wrote to the legacy system now uses the new one |
| Reports reproduced | The reports people depend on give the same numbers from the new system |
| History kept | Records that must be kept are archived in a readable form, with how to get to them |
| Rollback understood | What happens if the new system fails in the first weeks, and until when that is possible |
| Licences and hosting ended | The old system's costs actually stop |
Where modernisation goes wrong
- Starting from 'it is old' rather than a named problem, so the option chosen does not fix anything specific.
- A requirements list written from the documentation, missing the functions people actually use.
- A big bang cutover with no way back once the data has moved.
- Integrations discovered late, after the new system's design has been fixed.
- Two systems of record for the same data while both are running.
- A data migration run for the first time on the cutover weekend.
- Rebuilding a system feature for feature, including the workarounds for problems the new platform does not have.
- The legacy system left running 'just in case', with its licences, hosting and risks still in place.
Common questions
What is legacy system modernisation?
Changing an old software system so it can keep doing its job, or moving its job to something else. It covers a range of options: moving the system to new hosting as it is, upgrading its platform, restructuring its code, rebuilding it on a current stack, replacing it with a product, or retiring it. Modernisation is usually driven by a specific problem, such as an unsupported platform, a security risk, a single person who understands it, or a capability the business needs and the system cannot provide.
What are the options for modernising a legacy application?
Commonly described as retain, rehost, replatform, refactor, rebuild, replace and retire. Retain leaves it with a plan to review. Rehost moves it unchanged to new infrastructure. Replatform moves it with small changes, such as a newer database. Refactor restructures the code without changing its behaviour. Rebuild writes it again on a current stack. Replace moves to a product. Retire switches it off. The choice depends on what the problem is, and different parts of one system often suit different options.
What is the strangler fig pattern?
A way of replacing a system incrementally. A routing layer is put in front of the legacy system, and functions are rebuilt one at a time behind it. As each new function is ready, the routing layer sends its requests to the new system instead of the old. Users see one system throughout. When every function has moved, the legacy system is switched off. The name, from Martin Fowler, comes from a fig that grows around a host tree until the tree is no longer needed.
Why do big bang replacements fail?
Because everything has to work on the same day. Every function, every integration, every report and the whole data migration are cut over at once, and anything missed is found by the users in production. The scope is fixed early, while the old system keeps changing. And there is often no way back once the old system's data has moved. Incremental replacement spreads the risk: each step is small, tested in use and reversible.
How do you migrate data from a legacy system?
Profile it first: volumes, quality, and what each field actually holds, which in a long-lived system is often not what its name says. Map each field to the new system and write down the transformation rules. Run the migration repeatedly in test, reconciling record counts, totals and a sample of records against the source each time. Decide what history moves and what is archived. Then migrate for real, reconcile again, and keep the source readable until the new system has proved itself.
When should you not modernise a legacy system?
When it works, its risks are understood and acceptable, and the money is better spent elsewhere. A system on a supported platform that does its job, with more than one person who understands it and no capability the business is missing, may be best retained with a date to look again. Modernisation for its own sake spends money to arrive back where you started, with new risks.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- Strangler Fig (Martin Fowler)
- Strangler Fig pattern, Azure Architecture Center (Microsoft)
- ISO/IEC 25010:2023 Systems and software quality requirements and evaluation (SQuaRE): product quality model (ISO)
- The Twelve-Factor App (Adam Wiggins)
- Essential Eight (Australian Signals Directorate)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.