Legacy modernization means changing a working system so that it can keep changing, and the right route depends on evidence you can collect from the system itself. The guides on the first page of search results list six routes and leave the choice to the reader. That is where projects start to drift. This post gives four evidence checks that point to one route. A table sets the routes side by side, and a plain answer covers systems that should simply be switched off. The definition comes first.
What is legacy modernization?
Legacy modernization is the work of changing an older business system so that it can keep adapting to new needs. The system usually still works. Often it has become hard to change, hard to test, or tied to a platform that is ageing. Options range from moving it unchanged to replacing it.
Technical debt is the usual cause. Years of patches, each made under time pressure, leave code that nobody wants to touch. A change that should take a day takes a week, and every release carries a worry that something unrelated will break.
Application modernization and legacy system modernization describe the same work from different angles. The first names the software, while the second names its age. Both ask what must change so the business can keep changing.
Keep that question in front of you, because the answer ranges widely. A move to new hosting, a repaired code base, and a switch-off are all legitimate outcomes of legacy software modernization, and they cost very different amounts.
Which route fits: rehost, replatform, refactor, rearchitect, rebuild, or replace?
Rehost moves the system unchanged. Replatform adds light optimization. Refactor improves the code, and rearchitect changes the structure. Rebuild starts again with new code, and replace swaps in a product. Match the route to what the system's own data shows, using the four checks in the next section.
Swipe or use the arrow keys to compare all 4 columns.
Route | Fits when | Evidence to check | Main risk |
|---|---|---|---|
Route: Rehost | Fits when: Code is sound, platform is ageing | Evidence to check: Stable behaviour, few defects | Main risk: Same limits, new location |
Route: Replatform | Fits when: Light changes cut running cost | Evidence to check: Database or runtime can change alone | Main risk: Hidden dependencies |
Route: Refactor | Fits when: Code is hard to change or test | Evidence to check: Low test coverage, unclear modules | Main risk: Slow progress |
Route: Rearchitect | Fits when: Structure blocks new features | Evidence to check: Monolith slows every release | Main risk: Highest effort |
Route: Rebuild | Fits when: Old code cannot carry the roadmap | Evidence to check: Source is lost or unmaintainable | Main risk: Long run without value |
Route: Replace | Fits when: A product covers the function | Evidence to check: Process is standard, data extractable | Main risk: Fit gaps found late |
Read the table from the evidence column. A team that picks a route first and looks for evidence afterwards will find whatever supports the choice. Start with the system.
The guide from AWS Prescriptive Guidance calls refactoring the most complex and costly of its migration strategies. Its subject is moves to the cloud, so the point applies here by analogy. The more of the structure you change at once, the more can go wrong at once.
Effort rises as you move down the table, and so does the value at stake. Little changes with rehost, and little is gained. Rearchitect and rebuild change a great deal, and they pay back only when the old structure is the thing blocking the business. Such work pays only when the change matches the blockage.
Combining routes is allowed. A system can be rehosted this year to leave an ageing server, then refactored in slices over the next two. Treat each step as its own decision with its own evidence, and legacy modernization stops looking like a single leap.
Our post on on-premises versus cloud covers the decision to move, which comes before the route when the cloud is part of the plan.
What evidence decides the route?
Four checks decide the route. Check usage first, because AWS guidance treats applications under 5% CPU and memory use, or with no inbound connections for 90 days, as candidates to retire. Then check test coverage, data extraction, and whether old and new can run in parallel.
Check 1: usage
Count how many people use the system and how often, before any legacy modernization quote arrives. The AWS guidance names average CPU and memory use below 5%, and no inbound connections for the last 90 days, among the signals that an application can be retired. Cloud migration is its subject, and the same logic applies to any ageing system.
A system with no users needs no legacy modernization. Switching it off costs less than any route in the table.
Check 2: test coverage.
The AWS guidance lists an application that is difficult to test, or has very low test coverage, among the use cases for refactoring. The reasoning carries over. Code that cannot be tested cannot be changed safely, and each future release inherits that risk. Tests come first.
Establish what share of the behaviour automated tests cover. If the answer is close to none, refactoring or rearchitecting will start with writing tests, and that slow work makes every later change cheaper.
Check 3: data extraction.
Can the records leave the system in a usable form? Export a sample and look at it. Dates and codes, plus free-text fields, often hide inconsistencies that years of use have built up. Without extraction, replacement is blocked until the data can be moved, while with it the choice stays open.
Check 4: parallel run.
A parallel run means the old and the new system process the same input for a trial period, and the results are compared. Find out whether that is possible. Some systems cannot run alongside another because they hold the only copy of a record or control a physical process.
A possible parallel run makes any route safer. Without one, prefer small steps over a single switch.
How do you approach legacy modernization without a cut-over rewrite?
Replace the system in slices. Martin Fowler's strangler fig pattern builds new components alongside the old system and moves functions across one at a time, until the old system can be switched off. Fowler notes that replacing a serious IT system takes a long time and users cannot wait for new features.
The pattern answers the fear behind many legacy modernization projects, which is the big-bang switch. Fowler describes four activities that the incremental approach needs. Understand the outcomes you want. Decide how to break the problem into smaller parts. Deliver those parts successfully, and change the organization so the work can continue. The old system keeps serving users throughout, and new features appear in the new code. Bits of behaviour move across as each slice is ready. The old system can retire once the last slice has moved.
Slicing the work also suits different contracts. One slice can run as a fixed-scope project and another with a dedicated team, as our posts on how to hire dedicated developers and on software development outsourcing companies explain.
A parallel run fits the pattern well. Each slice sends the same input to the old and the new component, and the results are compared. A slice goes live when the two agree for long enough to trust. The pattern also has a cost, which is transitional code that lets old and new coexist and is thrown away later. In Fowler's view, the reduced risk and earlier value of the gradual approach outweigh that cost.
When should you retire or retain a legacy system?
Retire a system when nobody uses it, and no business value remains. Retain it when data residency, a dependency, or a recent upgrade makes moving it unwise today. Both appear as strategies in the AWS guidance. Modernizing a system that no one uses spends effort with no return.
The AWS guidance gives checkable reasons. Reasons to retire include no business value in keeping the application, the cost of maintaining and hosting it, and the risk of an unsupported operating system. The retain list names data residency requirements and dependencies on other applications that must move first, and the same list includes recently upgraded applications and those tied to specialized hardware.
Take an illustrative case. A reporting tool is opened by 3 people once a quarter, and the logs show no inbound connections for 90 days. The audit takes an afternoon. The tool is archived, and the project loses one system.
A short audit of usage should sit before any modernization quote. Count users, check the logs for the last 90 days, and list what depends on the system. Leave some systems alone for now and switch others off, because a modernization budget is better spent on the systems that carry the business.
Where does Burhani Technologies fit when you plan legacy modernization?
Burhani Technologies has built business software since 2010. Before recommending replacement, our engineers review the current code and data model, since extending an existing system can solve the problem. We then agree on a route and a dated plan per project after discovery, and we make no promise on duration before the evidence is in. Our application development practice covers the build.
→ Describe the system, who still uses it and what it blocks, and book a free consultation.
FAQs on legacy modernization
What is legacy modernization?
The work changes a working system so it can keep changing. The system usually runs, but it is hard to test, hard to change, or tied to an ageing platform. Options run from a move to new hosting through to a full rebuild, and some systems are simply retired.
What is the difference between rehost and refactor?
The rehost route moves the system to a new platform unchanged. Refactor improves the code itself so that the system is easier to test and change. AWS Prescriptive Guidance calls refactor the most complex and costly of its migration strategies, because the application is modernized during the move. Pick it only when the evidence supports it.
What is the strangler fig approach?
Martin Fowler describes the strangler fig approach as a gradual alternative to wholesale replacement. New components are built beside the old system, and functions move across one at a time until the old system can be switched off.
What is technical debt?
Technical debt is the accumulated cost of shortcuts that make a system harder to change. A quick patch saves time today and adds cost to every later change. Low test coverage is a common sign. So are unclear modules, and both help decide which route fits.
When is a rebuild justified?
A rebuild is justified when the old code cannot carry the roadmap, for example, when the source is lost, or nobody can maintain it. The AWS guidance lists a legacy application that nobody knows how to maintain, or whose source code is unavailable, as a case for refactor or re-architecture. Check the other evidence first, and then decide.
What is a parallel run?
A parallel run has the old and the new system process the same input for a trial period. The results are compared, and the old system is switched off only when the two agree. The method suits systems that can accept duplicate input, and it does not suit systems that control a physical process.
Which piece of evidence will you collect first?
Collect the four pieces of evidence first, and the route for your legacy modernization usually names itself. Usage comes before everything else.
→ Send us the system's name, its users, and its constraints, and get in touch.
