Legacy Modernisation vs Full Rewrite
Incremental modernisation replaces the system piece by piece while it stays in use. A rewrite builds a new system and switches over. The first spreads risk. The second concentrates it. Both have cases where they are the right call.
What Each Approach Involves
Incremental modernisation changes the system in steps. A common method places a routing layer in front of the old system. New components take over one function at a time, and the old code is retired as each function moves. The system stays in production throughout.
A full rewrite starts a new codebase. The team rebuilds the required functions, migrates the data and switches users over, either all at once or in groups. The old system must be kept running, and often kept changing, until the switch.
Neither approach is always right. Incremental work can be slow and leaves old and new code side by side for a long time. A rewrite gives a clean design but delays value and risks missing behaviour that nobody wrote down.
Decision Matrix
Find the rows that match your system. Mixed results usually mean a mixed approach.
| Situation | Incremental modernisation | Full rewrite |
|---|---|---|
| System is business-critical and must stay available | Best fit: changes are small and staged | Risky: cutover is a single large event |
| Business rules exist only in the code | Best fit: rules are moved one at a time | Risky: rules are easy to miss |
| Platform has no supported upgrade path | Fits if parts can be replaced around it | Best fit |
| Requirements have changed a great deal | Fits for partial change | Best fit: old design no longer applies |
| System is small and well understood | Fits | Fits: risk is contained |
| Code cannot be tested or safely changed | Hard: add tests at the edges first | Fits, after behaviour is documented |
| Funding is approved in stages | Best fit: each stage delivers something | Weak fit: value arrives late |
Side-By-Side Comparison
| Incremental modernisation | Full rewrite | |
|---|---|---|
| Cost shape | Steady spend over a longer period | High up front, plus the cost of running two systems |
| Main risk | Work stops part way and leaves a hybrid system | Missed requirements and a late or failed cutover |
| Speed | First results early, full completion later | No results until a usable version exists |
| Team impact | Team must work in old and new code | Team is split between maintaining and rebuilding |
| Reversibility | High: each step can be rolled back | Low after cutover |
Hidden Risks To Plan For
Behaviour nobody documented
Old systems handle edge cases that users rely on without knowing. Both approaches need a way to discover them before they are lost.
The permanent hybrid
Incremental work that loses funding leaves two systems joined together. Plan each step so the system is in a stable state if work pauses.
Feature parity
A rewrite must match what the old system does before users will switch. The old system keeps gaining features during the build.
Data migration
Old data often breaks the rules the new system expects. Profile and clean it early. Rehearse the migration more than once.
A Phased Way To Decide And Act
- 1Phase 1
Assess
Review code health, test coverage, platform support and how well the rules are documented.
- 2Phase 2
Capture behaviour
Record what the system does today with tests around its inputs and outputs.
- 3Phase 3
Choose per component
Decide to modernise, rewrite or leave alone, one component at a time.
- 4Phase 4
Deliver one slice
Move one function to production. Confirm that the rollback works.
- 5Phase 5
Continue and retire
Repeat in order of value and risk. Remove old code as each part moves.
Two Anonymised Scenarios
Both scenarios are invented illustrations. They are not client stories.
- Scenario A
A core system that cannot go offline
Imagine a company that runs its daily operations on one large, old application. The rules inside it were added over many years. Incremental modernisation fits. Functions move one at a time, and the business keeps running while they do.
- System is critical
- Rules are in the code
- Each step can be reversed
- Scenario B
A small tool on an abandoned platform
Imagine a company with a small internal tool built on a platform that is no longer maintained. The tool does a few well-understood things. A rewrite fits. The scope is small, the behaviour is known and the old platform offers nothing to build on.
- Scope is small
- Behaviour is understood
- Platform has no future
Recommended Next Step: Resilience Audit
We review the system with your team, list the risks and discuss which parts to modernise, rewrite or leave alone.
Related Insights
View All Articles- HiringHow to brief a remote developer so week one is productiveA short checklist covering access, context and a first task that is small enough to finish.
- Project ManagementStaff augmentation or a dedicated team: a decision you can make in ten minutesFour questions about ownership, runway and management time that settle the choice.
- ModernisationSigns your legacy platform has become a business riskWhat to look for in release frequency, incident history and hiring difficulty.
Frequently Asked Questions
No. A rewrite is reasonable when the platform has no supported future, when the system is small, or when requirements have changed so much that the old design no longer applies. It carries more risk, so it needs a stronger reason.
Full completion often takes longer. The difference is that results arrive along the way, and the work can pause without leaving the business without a working system.
Yes. Many projects rewrite a few components and modernise the rest in place. Decide one component at a time.
Capture the current behaviour in tests and documentation. Whichever approach you choose, this reduces the chance of losing rules that the business depends on.
You do. You own all code and IP. An NDA is signed before anyone has code access, and the work happens in your repository and tools.