When an old system needs a plan
A system becomes legacy when changing it is harder than the business can afford, whatever its age. The software may still work every day. The trouble shows in what surrounds it: the one person who understands it, the supplier who no longer supports its platform, the integration that cannot be built, the report that takes a week by hand.
Reasons that justify a project
- Its platform or language no longer receives security updates
- Only one or two people can safely change it
- It blocks a product, a market or a regulation
- Small changes take far longer than they once did
- It cannot connect to systems the business now depends on
Reasons that do not, alone
- It looks dated
- A new technology is fashionable
- A new manager prefers another product
- It was written before the current team arrived
- A supplier is offering a discount on a replacement
Be clear about which reasons apply to you, because they decide what success means. A project to remove a security risk is finished at a different point from a project to speed up product changes.
Assess the system before choosing a route
Old systems hold years of decisions that nobody wrote down: a rounding rule added after a dispute, a special case for one customer, a nightly job that quietly repairs data. These are the business, and a plan that ignores them fails at go-live.
- 01
What does the system do, function by function?
Why it mattersList what it does, not what its manual says. Watch people use it, and read its scheduled jobs and reports.
- 02
Which functions are still used?
Why it mattersMany are not. Everything you can retire is something you do not have to rebuild.
- 03
Where is the data, and how clean is it?
Why it mattersStructure, volume, quality and history decide much of the cost of moving.
- 04
What is connected to it?
Why it mattersFiles dropped on a server, direct database access by other systems and spreadsheets fed by exports all count as integrations.
- 05
Who knows how it works?
Why it mattersTheir knowledge needs capturing early, whether they are staff, a supplier or a retired contractor.
- 06
What state is the code in?
Why it mattersWhether it can be built, tested and changed safely determines which routes are open.
A technical code audit answers the last question in writing and gives the plan a factual base.
The routes, from lightest to heaviest
| Route | What it means | Fits when |
|---|---|---|
| Keep and contain | Leave it alone, isolate it and reduce the risk around it | It works, changes rarely and will be retired within a known horizon |
| Wrap | Put a modern interface in front so other systems can use it | The core is sound but nothing can connect to it |
| Move | Shift it to current infrastructure with little change | Hardware or hosting is the problem, not the software |
| Rework | Restructure and update the code while keeping its behaviour | The logic is valuable and the code can be made testable |
| Replace in stages | Build new parts beside the old and move functions across one by one | The system must change substantially and the business cannot stop |
| Replace with a product | Adopt packaged software and adapt processes to it | Your needs in that area are standard |
Most real plans combine routes: one module is retired, one is wrapped, the core is replaced in stages. Our comparison of modernizing and replacing legacy software helps with the choice for each part.
Why staged replacement usually wins
The alternative to stages is to build the entire replacement and switch on one day. It is attractive on paper and dangerous in practice. Nothing is delivered until the end, the old system keeps changing while the new one is written, and every hidden rule is discovered at the same moment, in production.
- 01
Choose a first slice
Pick a function that is useful, reasonably separate and not the most critical. Its purpose is to prove the method as well as to deliver value.
- 02
Put a layer in front
Route requests through a point that can send each one to the old system or the new. Users and other systems see one system throughout.
- 03
Build the slice and run it beside the old
For a period, both produce results and the results are compared. Differences reveal the undocumented rules.
- 04
Switch that slice, keeping a way back
Move users across, watch closely and keep the ability to return until confidence is earned.
- 05
Retire the old part, then repeat
Remove what has been replaced so that it cannot be used by mistake, and take the next slice.
Each stage should leave the business in a state it could live with for a long time. Plans change, budgets pause, and a half-finished modernization must still be a working system.
Plan the data as carefully as the software
During a staged replacement, data lives in two places. Decide for each kind of record which system is the authority at each stage, how changes pass between old and new, and how you will prove that nothing was lost. Totals, counts and samples compared before and after each move are simple and effective.
Decide also how much history to move. Carrying every record from decades of operation costs effort and brings old errors with it. Many organizations move open and recent records, and keep the rest in a read-only archive that remains searchable. Our data migration page describes how this work is structured.
A worked example
A distributor's order system
This example is invented to show a staged plan. A distributor runs orders, pricing and stock on a system written long ago by a contractor who has retired.
- AssessmentWatching the order desk reveals that 40 of the system's 110 screens are still used. The pricing module contains customer-specific rules that exist nowhere else.
- RoutesReporting is retired in favour of a standard reporting tool. Stock is wrapped with an interface so the web store can read it. Order entry and pricing will be replaced in stages.
- First sliceOrder entry for one product family is rebuilt. For a month, each order is priced by both systems, and 3 differences in every 100 expose rules nobody remembered.
- SwitchThe order desk moves to the new screens for that family. The old screens stay available for two weeks and are then removed.
- ContinuationThe remaining families follow, one at a time. Pricing is last, because by then its rules have been documented through the comparisons.
The distributor had working improvements within the first stage and never faced a single high-risk switch. The plan could have stopped after any stage and left a usable system.
Modernization planning checklist
Legacy modernization planning checklist
0 of 11 checkedWhat to do next
Start the function list this week. Sit with the people who use the system and write down what they do in it. That list will shrink the project, expose the hidden rules and make every later estimate more accurate.
Our legacy software modernization page explains how we plan and carry out this work. Describe the system to us and we will suggest what to assess first.
Common questions
Is it better to modernize or to rewrite from scratch?
A complete rewrite is the riskiest route, because it reproduces years of behaviour in one attempt and delivers nothing until the end. It is justified when the technology is unsupported and the code cannot be made testable. Even then, building the replacement in stages beside the old system is usually safer than a single switch.
How long does a modernization project take?
It depends on the size of the system, how much is still used, the state of the code and data, and how many stages the business can absorb, so a general figure would mislead. A staged plan gives a better answer than a total: it tells you when the first slice will be live and what each later stage adds.
Can the business keep operating during modernization?
Yes, and the plan should be built around that. Staged replacement keeps the old system running while functions move across one at a time, with a way back at each step. Some stages need a short planned pause for a data move, which can usually be scheduled outside working hours.
What if nobody understands the old system any more?
Then discovery is the first stage and deserves a proper budget. The system itself is the documentation: its code, its database, its scheduled jobs and the habits of the people who use it. Running old and new side by side and comparing results is the most reliable way to surface rules that nobody can explain.
Should we move everything to the cloud as part of modernization?
Only if hosting is one of your problems. Moving infrastructure and changing software are separate decisions that are often bundled without reason. A system can be modernized where it runs, or moved with little change. Combining both in one step doubles what can go wrong, so sequence them unless there is a clear case for doing otherwise.