Legacy Modernization: Rehost, Replatform, Refactor or Rebuild?
Most organisations run at least one system that is too important to switch off and too old to change easily. Modernizing it is rarely a single decision. The right approach depends on what is actually holding the system back: hosting costs, code that nobody wants to touch, missing integrations, security gaps or a user experience that slows people down. This guide compares the four main modernization approaches and explains how to choose between them.
Signs a system needs modernization
- Small changes take weeks because the code is fragile or poorly understood.
- Only one or two people know how the system works.
- It cannot integrate with newer tools without manual workarounds.
- Infrastructure or licences are expensive, unsupported or near end of life.
- Security patches are no longer available for the platform or framework.
- Users rely on spreadsheets and email to work around its limits.
If several of these apply, the cost of standing still is usually higher than it looks.
The four main approaches
| Approach | What changes | Best when | Main trade-off |
|---|---|---|---|
| Rehost | Infrastructure only (for example moving to the cloud as-is) | Hosting is the main problem and the code is stable | Fast, but the application's own limits remain |
| Replatform | Infrastructure plus targeted changes (managed database, containers) | You want cloud benefits without a rewrite | Moderate effort; architecture mostly unchanged |
| Refactor | Code and architecture, in steps, while the system keeps running | The business logic is valuable but the code is hard to change | Larger effort, but lower risk than a rewrite |
| Rebuild | A new application replaces the old one | The system no longer fits the business at all | Highest cost and risk; needs careful data migration |
Many programmes combine approaches: rehost first to cut hosting costs quickly, then refactor the parts that change most often.
How to choose
Start with the business problem
Write down what the modernization must achieve in measurable terms, such as "release changes every two weeks instead of every quarter" or "remove the unsupported database before its end-of-support date". The goal decides the approach, not the other way round.
Assess the system honestly
A short assessment should cover code quality, test coverage, dependencies, data structures, integrations, security and who knows the system. This shows which parts are worth keeping and which are holding everything back.
Prefer incremental change
Replacing a critical system in one big release concentrates all the risk on one day. An incremental approach, often called the strangler pattern, moves functionality piece by piece to new components while the old system keeps running. Each step is smaller, easier to test and easier to roll back.
Plan the data early
Data migration is where many modernization projects slip. Profile the data, agree on what needs cleaning, rehearse the migration more than once and define how you will verify that nothing was lost.
Managing risk
- Keep the lights on: agree how the old system will be supported until the switch-over is complete.
- Automate testing first: tests around existing behaviour make every later change safer.
- Run in parallel where possible: compare old and new results before cutting over.
- Communicate with users: training and a clear timeline reduce resistance and support load.
- Measure outcomes: track the goals you set at the start, not just the delivery milestones.
Key takeaways
- Rehost, replatform, refactor and rebuild solve different problems; choose by business goal.
- An honest assessment of code, data and integrations prevents expensive surprises.
- Incremental modernization keeps the business running and spreads risk across smaller steps.
If you are planning to modernize a critical system, our team can assess it and recommend a practical, phased approach.