A legacy system can be modernised seven ways, and each treats a different problem. Name the pain first, then pick an approach for that system alone. A large estate normally ends up with several approaches, and a low-cost one is often enough.
The seven at a glance
| Approach | What it touches | Relative cost | Result |
|---|---|---|---|
| Rehost | The hosting only | Lowest | A move off hardware or a data centre contract that is ending |
| Encapsulate | Nothing inside; an interface is added in front | Low | A stable way for other systems to use it, and time to decide |
| Replatform | The runtime or database, with little code change | Low | A supported stack and some operating gains |
| Refactor | The code, not the structure | Medium | A system that is cheaper to change |
| Rearchitect | The structure, often splitting a monolith | High | Independent deployment and scaling of parts |
| Replace | The system itself, with a packaged product | Varies | Someone else carries the maintenance |
| Rebuild | Everything | Highest | Software that matches your specification, provided you have one |
The seven approaches here suit business systems of all kinds. AWS's guidance on cloud moves uses a different set of seven, called the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. AWS also says refactoring is the most complex and costly of its strategies and recommends modernising after a large migration, not during it. See AWS Prescriptive Guidance.
Rehost: move it as it is
Use it when the data centre lease is ending or the hardware has lost vendor support while the application still does its job. Move it, bank the saving and stop there.
People dismiss rehosting as "lift and shift" because the alternatives bring larger fees. When the real problem is the server, it is the correct answer. It will not make the system any easier to change, so if slow change is your pain, look further down the table.
Encapsulate: put an interface in front
Leave the old system running. Wrap it in a documented interface, and have every other system call the wrapper.
Nothing inside changes, yet three things get better. Other systems stop reading its internal tables. Each new integration stops being a one-off job. And you can now replace the part behind the interface in stages without anything downstream noticing. This is why encapsulation is the usual first move before the larger options.
Replatform: change what it runs on
Keep the code and swap what it runs on, for example a database version that has lost support, or an application server that moves into a container. The effort is modest, the operating benefit is real and the structure is untouched.
Refactor: clean the code in place
Choose it when the structure is sound and the code is merely awkward to edit. It can stall, since it produces no feature anyone can see and competes with the roadmap at each planning meeting. Give it its own budget and an owner, or expect it to stall.
Rearchitect: change the structure
Choose it when a monolith cannot be scaled or released in parts, and that limit costs you something you can measure. Be cautious. Splitting a system adds network calls, partial failures and more to operate. It earns its cost only where tight coupling is the real problem. Estates built on IBM midrange and mainframe platforms have their own constraints, covered in modernising AS/400 and mainframe systems in India.
Rebuild: write it again
A rebuild costs the most and carries the most risk, because everything is written again and nothing is in use until it is finished. Consider it in three cases. The whole system could be redone in a few months. Its platform is dead. Or the business is deliberately changing the process, so copying old behaviour is no longer the aim.
If none of those apply, you are probably planning a gradual migration and calling it a rebuild.
Replace: buy a product
A packaged product already covers the need. Count the steps that would need code changes and not settings. If the list is short, buy. The cheapest modernisation is one that somebody else maintains. ERPNext, Odoo or a custom ERP shows the counting method for ERP.
How to read the cost column
The cost column is relative and meant for ordering, not budgeting. Three things move a project up or down it.
- Size of the system. Lines of code, number of screens and number of reports all push cost up.
- Quality of the documents. A system with a current dependency map and tests costs less to change than one with neither.
- Number of connections. Every system that reads from or writes to the legacy one is another thing to test.
A first assessment that lists these three for each system gives a ranking you can defend. It is cheaper than a detailed estimate, and it often shows that two or three systems need only the low rows of the table.
Choosing, one system at a time
Ask four questions of each system, not of the whole programme.
- What is the pain? Hardware, cost, speed of change, scale or risk. Each points to a different row. Age alone is not a pain.
- Can it stop? If the business cannot pause, anything needing a single cutover is out. See big bang or phased rollout.
- Is the behaviour written down? If the rules live only in code, a rebuild is riskier than it appears, since you have no specification to build against. Recovering undocumented business rules covers the method.
- Is there a fixed date? An end-of-support date or a legal deadline narrows your choices. Plan backwards from it.
| Pain | Usual first choice |
|---|---|
| Hardware or hosting contract ending | Rehost |
| Other systems break when this one changes | Encapsulate |
| Unsupported database or runtime | Replatform |
| Each change takes too long | Refactor, or encapsulate then rearchitect |
| One part must scale alone | Rearchitect that part |
| A product already does the job | Replace |
Different systems in one estate give different answers. Treating the estate as a single decision is how a company spends rebuild money on a system that needed rehosting. Choosing the first legacy system to modernise helps with the order.
The strangler pattern is a sequence, not an eighth option
Martin Fowler named the strangler pattern after strangler fig vines. He describes building new components beside the legacy system and moving behaviour across piece by piece, which lets the business see returns early and keeps risk low (Fowler). Temporary code lets old and new coexist.
In practice it is a way to apply several of the seven in order. Encapsulate first, so that other systems stop reaching into the old one. Next, rearchitect or rebuild a single capability at a time, hidden behind the wrapper. Retire what is left. The programme can stop at any point and still hold working improvements.
What a mixed plan looks like
Take a hypothetical manufacturer with five systems. It rehosts a reporting database nobody changes. It encapsulates the stock system that three others read. It replatforms a dispatch tool on an unsupported runtime. It rearchitects, module by module, the plant-floor system that blocks every new product line. It replaces a payroll tool whose vendor now sells a better product. That is five approaches in one programme, and none is a rebuild. The example is illustrative and not a client case.
Questions teams ask
Which approach is cheapest?
Rehost, and it also gives the least. Encapsulate comes next and often gives the best value, because other systems stop relying on the internals, at a fraction of what changing them costs.
Does one approach suit a whole estate?
Rarely. Choose per system against the four questions above.
Where do I start?
With the broader legacy modernisation guide and the pain list for your top five systems.
Where Brihat fits
Brihat Infotech's legacy modernisation service chooses one of these seven for each system. It then migrates in stages, with behaviour tests and checksummed parallel runs. Start a conversation.