Legacy system modernization means changing an old system so it keeps serving the business at acceptable cost and risk. There are five main options: rehost (move it unchanged), replatform (move it with limited changes), refactor (restructure the code), rebuild (write it again) or replace (adopt another product). Most organizations choose per component, not once for the whole system.
The right choice depends less on how old the technology is than on three questions: does the system still fit how the business works, can the code be changed safely, and can anyone still support the platform it runs on? This guide sets out each option, the assessment questions that separate them, a decision tree, and how to move from old to new without betting the business on one weekend.
What are the options for modernizing a legacy system?
The five options sit on a scale from least change to most change. Cloud providers use similar vocabularies: AWS Prescriptive Guidance, for example, lists seven migration strategies, namely retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. The table uses the five terms buyers meet most often.
| Option | What it means | Effort | Risk | What improves | What stays the same |
|---|---|---|---|---|---|
| Rehost | Move the system to new infrastructure without changing it, often called lift and shift | Low | Low to medium | Hosting, hardware support, sometimes availability and backup | Code, business logic, screens, data model and all existing technical debt |
| Replatform | Move with targeted changes: a supported database or runtime version, managed services, containers | Low to medium | Medium | Platform supportability, operations, sometimes performance | Business logic, most of the code and the user experience |
| Refactor | Restructure the code without changing what it does for users, usually module by module | Medium to high | Medium | Maintainability, testability, speed of change, integration points | Business behaviour, by design |
| Rebuild | Write a new system to current requirements, reusing data and knowledge rather than code | High | High as a big bang, lower when incremental | Fit to the process, user experience, architecture, integrations | Only the data and the rules you choose to keep |
| Replace | Adopt a packaged or SaaS product and migrate data into it | Medium: configuration, migration and process change | Medium | Vendor-maintained platform and standard features | Your process must adapt wherever it differs from the product |
Two more options belong on every shortlist. Retain means leaving the system alone for now, with a review date and a watch on end-of-support dates. Retire means switching it off and archiving the data for as long as your legal and tax advisers say it must be kept.
AWS describes refactoring as the most complex and costly of its strategies and, for large portfolio migrations, recommends moving applications first and modernizing them afterwards. That is sound advice when hundreds of applications are moving to the cloud. For a single core business system the reverse is sometimes true: rehosting a system you already plan to rewrite only buys time, and time is worth buying only if you know what you will do with it.
How do you assess a legacy system before choosing?
Answer six questions about the system, with evidence rather than opinion, and write down the answers. The pattern of answers points to the option far more reliably than the age of the code does.
Assessment checklist
- Business fit. Does the system still do what the business needs? Count the workarounds: spreadsheets kept alongside it, data re-keyed into other systems, approvals done by email because the system cannot model them.
- Code health. Is the source code available and in version control? Are there automated tests, or could tests be added? When did someone last change it without breaking something else?
- Skills availability. Can you hire or contract people who know the language, framework and database? Is knowledge concentrated in one person who could leave?
- Vendor support status. Are the operating system, database, runtime and third-party components still supported by their vendors with security updates? Check each vendor's published lifecycle page and record the end-of-support dates in a register.
- Data quality. Are there duplicates, missing mandatory fields, codes whose meaning nobody remembers, or business rules hidden in stored procedures and triggers?
- Integrations. What does the system exchange data with, and how: shared files, direct database reads, scheduled jobs, APIs? Who owns the system at the other end?
Reading the answers
| What the assessment shows | Leans toward |
|---|---|
| Good business fit, healthy code, unsupported platform or expiring hosting | Rehost or replatform |
| Good business fit, code hard to change, changes needed often | Refactor, one module at a time |
| Poor business fit because the process has changed, code hard to change | Rebuild incrementally, or replace |
| The process is standard for your sector and well served by products you have evaluated | Replace |
| Few users, rare changes, supported platform | Retain, with a review date |
| Little use, functions duplicated elsewhere | Retire and archive |
What does a modernization decision tree look like?
Work through these questions in order, for each major component rather than for the system as a whole.
- Is this capability still needed? If not, retire it and archive the data.
- Is the process standard, and does a product you have evaluated fit it with modest configuration? If yes, replace it and budget properly for data migration and process change. Our comparison of custom versus ready-made software covers that choice in more depth.
- Is the urgent problem only the platform (unsupported hardware, operating system or database, or an ending hosting contract) while the system still fits the business? If yes, rehost or replatform now and revisit the code later.
- Is the code changeable? Source available, someone understands it, tests exist or can be added. If yes, refactor the parts that change most often.
- If the code is not changeable and the business needs significant change, rebuild incrementally using the strangler fig approach described below. Keep a big-bang rebuild for small systems with simple data and few integrations.
The result is usually a mix. A common shape: replatform the database now to get back onto vendor support, replace a standard accounting function with a package, and rebuild the part that makes your organization different.
What is the strangler fig approach?
The strangler fig approach replaces a legacy system gradually: a new system grows around the old one and takes over one capability at a time until the old one can be switched off. Martin Fowler named it the Strangler Fig Application, after the fig that grows around a host tree.
In Fowler's description, it begins with small additions, often new features, built on top of yet separate from the legacy code base, and then moves pieces of behaviour from the old system into the new one. Because each piece is small, each release carries less risk than a single switch-over.
How it works in practice
- Put a routing layer in front. An API gateway, reverse proxy or integration layer decides whether each request goes to the old system or the new one.
- Choose a first slice with clear edges. Good candidates have visible value and limited data dependencies: a customer self-service screen, a reporting module, a new feature the old system cannot support.
- Decide which system owns each record during the transition. If both systems can write the same customer or order, define the synchronization rule in writing before any code is written.
- Move, verify, switch the route, then delete the old path. A slice is finished only when the old code for it is no longer in use.
- Repeat until the remainder is small enough to replace, rebuild in one step or retire.
The approach has costs. You run two systems for a period, and some integration between old and new is built only to be thrown away later. It also takes discipline to retire each old piece; without it, you end up with two systems permanently. Our guide to system integration approaches covers the patterns used to connect old and new during the transition.
Illustrative scenario
This is an illustrative example, not a client case. A distributor runs an order management system built some fifteen years ago in a desktop framework, with pricing logic in stored procedures. The assessment finds that order entry still fits, customer self-service and reporting do not, the original developer has left, and the database version is out of vendor support.
The plan: first replatform the database to a supported version, changing nothing else. Next, build a customer portal as a new service that reads orders through an API layer over the old database. Then move pricing rules into a new service that the old system calls. Then move order entry, leaving the old system read-only for history, and finally retire it. Each step ships on its own, and the business could stop after any step and still be better off.
How should data migration and reconciliation be handled?
Treat data as its own workstream, with named owners, written mapping rules, trial loads and reconciliation, starting during the assessment rather than at the end of the build.
Legacy data has particular traps. Status codes carry meanings documented only in someone's memory. Dates are stored as text in more than one format. Business rules live in triggers and stored procedures, so the data alone does not tell you how it was used. Older systems may also use legacy character encodings that corrupt names when extracted carelessly.
Reconciliation checklist
- Record counts per entity in source and target, with every difference explained
- Financial totals and open balances agreed to the old system
- Field-by-field comparison on a sample of records
- Users running real scenarios on migrated data, such as receiving a payment against a migrated invoice
- Written sign-off by the business owner of each data area
Our ERP data migration plan sets out trial loads, tie-outs and sign-offs step by step; the method applies to any core system, not only ERP.
How do you plan cut-over and rollback?
Write the cut-over as a timed runbook, rehearse it at least once, agree go and no-go criteria in advance, and define the point after which you fix forward rather than roll back.
- The runbook lists every step with an owner and a time: freeze changes, final extract, load, reconcile, smoke test, switch routes or DNS, tell users.
- Go and no-go criteria are agreed before the day: reconciliation tie-outs signed, critical scenarios passed, support rota in place.
- Rollback before the point of no return means switching routes back to the old system, which must still be intact and unmodified.
- Rollback after users start transacting in the new system means records created there must be re-keyed or synchronized back. Plan how, or decide explicitly that you will fix forward.
- Choose a quiet window. Avoid month end, payroll runs and seasonal peaks.
- Plan hypercare: extra support for the first weeks, with a daily issue review.
Should you run old and new systems in parallel?
Sometimes. Parallel running gives evidence that the new system produces the same results, but it adds work, so choose the lightest form that gives you the evidence you need and set exit criteria in advance.
| Approach | How it works | Good for | Cost |
|---|---|---|---|
| Full parallel run | Users enter transactions in both systems and outputs are compared | Calculations where errors are costly, such as payroll or billing | Double entry and staff fatigue; keep it short and defined |
| Shadow mode | The new system receives the same inputs automatically; its outputs are compared but not used | Pricing, rules and calculations fed by integrations | Input duplication to build; no extra user effort |
| Pilot group | One branch or team moves first | Process-heavy systems with many users | Two ways of working live at once |
| Read-only legacy | The old system stays available for lookups and history only | After cut-over | Hosting and licences for a defined period |
Why do legacy modernization projects fail?
The causes repeat across sectors and technologies:
- A big-bang rewrite of a large system. The old system keeps changing while the new one is built, so the target moves.
- Copying the old system feature for feature, including workarounds nobody needs any more.
- Business rules discovered late, hidden in code, scheduled jobs, reports and staff habits.
- Data treated as an afterthought instead of a workstream with owners.
- Nobody in the business empowered to decide which old behaviour to keep.
- Integrations found after the design is fixed.
- The old system never retired, leaving two systems to maintain.
- Choosing the option by fashion rather than by the assessment.
When is modernization not the right approach?
Sometimes the honest answer is to leave the system alone or to change something else.
- The system is stable, supported and rarely changes. Retain and maintain it, and watch the end-of-support dates.
- The real problem is that it cannot talk to other systems. An API or integration layer around it may be enough, without touching the core.
- The process is standard and a product fits. Replacing is usually cheaper to own than rebuilding.
- Nobody can make decisions about the business rules. Modernizing without those decisions recreates the old problems on a new platform.
How Timeline Digital approaches legacy modernization
We start with an assessment rather than a recommendation: a system map, a code and infrastructure health review, a data quality audit, a risk register and a proposed approach with the reasoning written down. Our legacy software modernization page describes that work. Where the main need is connecting an old system to new ones, see our systems and API integration services; where a rebuild is the right answer, our custom software development team builds module by module. Before any full project, we build 2 to 3 of your key modules as a free pilot, so you can judge working software before committing.