A rewrite vs incremental modernisation: which to choose and when
What is the difference between a rewrite and incremental modernisation?
A rewrite builds a replacement system in parallel and cuts over in one event. Incremental modernisation leaves the old system running and replaces it a route at a time behind a stable facade. Choose a rewrite when the platform cannot be extended at all; choose incremental when the business cannot stop.
A rewrite builds a replacement system in parallel and cuts over in one event. Incremental modernisation leaves the old system running and replaces it one route, one module or one table at a time behind a stable facade. The difference is not technology but exposure: a rewrite concentrates all the risk into one date, while incremental modernisation spreads it across many small reversible steps.
This comparison sets out what each approach actually involves, a side-by-side on eight dimensions that matter to a budget holder, the conditions under which each clearly wins, the hybrid that most enterprise programmes end up running, and the cost of reversing the decision if you pick wrong.
What a rewrite actually is
A rewrite is a greenfield build of a system that already exists. A new team writes a new application, usually on a new stack, reading the old system as a specification. The old system keeps running and keeps changing while the new one is built, which is the part that surprises people. On go-live day, data is migrated, traffic is switched and the old system is retired.
Rewrites are attractive because they promise a clean slate: no compromise architecture, no dead code, no dependency on a framework nobody supports. They are dangerous because the clean slate has no users on it. Every behaviour the old system acquired over fifteen years of edge cases, regulatory patches and finance-team workarounds has to be rediscovered, and the only complete record of those behaviours is the code you are throwing away.
What incremental modernisation actually is
Incremental modernisation keeps the legacy system in production and moves capability out of it in slices. A facade sits in front of the old system so callers do not know which implementation answers them. One capability at a time is reimplemented behind that facade, verified against the old one, and switched over. When the last slice moves, the old system has nothing left to do and is switched off. This is the strangler pattern, described in detail in the strangler pattern: modernizing without stopping the business.
The technique depends on three supporting pieces: an anti-corruption layer that translates between the old data model and the new one, characterisation tests that pin down what the legacy code does today rather than what the documentation says it does, and a period of parallel running where both implementations answer and the outputs are reconciled. We cover the test discipline in characterisation tests: the safety net for legacy code.
Martin Fowler's original write-up of the strangler fig application makes the point that matters commercially: the value of the approach is that each step is small enough to reverse, so a mistake costs a sprint rather than a programme.
Rewrite vs incremental modernisation: a side-by-side
| Dimension | Full rewrite | Incremental modernisation |
|---|---|---|
| Risk profile | Concentrated in one cutover date | Spread across many small switches |
| Time to first business value | At go-live, often a year or more | Weeks, at the first slice |
| Feature freeze on the old system | Usually required, and usually resented | Not required; the old system keeps shipping |
| Data migration | One large migration with one reconciliation window | Many small migrations, or shared data with dual writes |
| Rollback | Restore from backup and re-run the day | Flip a route back to the legacy implementation |
| Hidden behaviour discovery | Found after cutover, by users | Found during parallel running, by reconciliation |
| Total engineering effort | Lower in theory, higher in practice | Higher in theory, includes facade and dual running |
| Architecture freedom | Complete | Constrained by the facade contract early on |
| Organisational tolerance needed | One large budget, one large leap of faith | Sustained attention over several quarters |
When a rewrite clearly wins
A rewrite is the right call more often than the internet suggests, and the conditions are specific rather than emotional.
The first is a hard platform floor. If the system runs on a runtime, database version or vendor product that is out of support and cannot be upgraded in place, there is no incremental path; you are not modernising, you are evacuating. The second is scale: a system of a few thousand lines with one integration and twenty users is cheaper to rebuild than to wrap. The third is a genuine change of purpose. If the new system is meant to do something structurally different rather than the same thing better, you are not replacing software, you are building new software that happens to retire something.
When incremental modernisation clearly wins
Incremental wins whenever the system is load-bearing for revenue and the business cannot pause. Core banking, hospital administration, dispatch, order management and institutional ERP all fall here: the cost of a bad weekend is measured in regulatory exposure rather than in engineering hours.
It also wins when the system is large and poorly understood. If nobody currently employed can describe what the batch job on the last working day of the month does, a rewrite is guessing and an incremental approach is reading. Parallel running turns the legacy system into its own test oracle.
Finally, incremental wins under budget uncertainty. Each slice delivers a working improvement, so the programme can be paused after any slice with the value already banked. A rewrite paused at sixty per cent has delivered nothing.
The case where the answer is both
Most large programmes we run are hybrids, and the split is usually along the line between system of record and system of engagement. The record stays where it is for now, wrapped in an API layer, while the interfaces, reporting and workflow around it are rebuilt cleanly. Adding that layer is often the first paid step, covered in adding an API layer to a legacy monolith.
How to choose: a test you can run in a week
- Count the integrations. List every system that reads from or writes to the legacy application. More than about six inbound integrations makes a clean cutover very hard to schedule.
- Check the platform floor. Ask whether the runtime, database and hosting can be upgraded in place. If the answer is no, the incremental path may not exist.
- Find the owner of the weird behaviour. If no current employee can explain the month-end or year-end processing, treat the code as the specification and go incremental.
- Price a bad weekend. Multiply an hour of downtime by the revenue or regulatory cost it carries. If a failed cutover is survivable, a rewrite is on the table.
- Test for a feature freeze. Ask the business whether the old system can stop changing for the build period. If the honest answer is no, a rewrite will be chasing a moving target.
- Check appetite for duration. Incremental needs sustained attention across quarters and a named owner who survives reorganisations. Without that it stalls halfway, which is the worst of both approaches.
What each costs and how long it takes
Eazyware runs both shapes as fixed-price programmes. A legacy-to-AI modernization programme starts at $31,500 or ₹22,40,000 and runs to $105,000 or ₹72,00,000 and above depending on the number of slices and integrations. A ground-up custom enterprise software build, which is the shape a rewrite takes, starts at $24,500 or ₹16,00,000 and reaches $175,000 or ₹1.2 Cr for a large platform. Published starting figures for every programme are on the pricing page.
On duration, most scoped builds take eight to sixteen weeks. Incremental programmes are not longer in total; they are longer before they finish and much shorter before they first deliver. If the decision itself is unclear, a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, produces the integration map, the slice order and a defensible recommendation. The three-week ProofRun at $6,250 or ₹4,00,000 proves the hardest slice before anyone commits to the rest.
The reversal cost if you chose wrong
This is the question that should settle most arguments, because the two approaches fail asymmetrically.
Abandoning an incremental programme is cheap. The facade stays, the slices already moved keep working, and the legacy system continues to serve the rest. You stop, and what you built is still in production. Abandoning a rewrite at month nine means writing off every line of the new system and returning to an old one that is now nine months further behind on patches and features. There is no partial credit.
Where incremental modernisation is the wrong choice
Incremental is not a universal answer and we say so in scoping calls. It is wrong when the facade would be more complex than the thing it hides, which happens with small systems and with systems whose data model is genuinely incompatible with where you are going. It is wrong when the organisation cannot sustain a multi-quarter programme, because a half-stranglered system is harder to operate than either endpoint. It is wrong when the licence or hosting contract you are trying to escape expires before the slices can realistically finish.
It is also the wrong frame entirely if the honest problem is that the business process, not the software, is broken. Rebuilding a bad process in a modern stack produces a faster bad process. A longer discussion of that trade-off sits in application modernization vs rewrite: the honest comparison.
What this looks like in practice
A university ran a fifteen-year-old ERP that handled admissions, fees and examinations, with an academic calendar that made a big-bang cutover impossible: there is no weekend in the year where nothing important is happening. We wrapped it, moved capability out module by module, and ran old and new in parallel through a full admissions cycle before switching anything permanently. The programme is described in the university ERP modernisation case study. The decision was not made on architectural taste; it was made because the calendar removed the cutover window.
Related reading
Cloud migration for legacy apps: lift, shift or re-platform covers the hosting decision that usually accompanies this one, and zero-downtime cutovers: how to plan them sets out the mechanics if you do choose a switch date. Our other side-by-side decision guides, including build versus buy, are collected on the comparison hub, and the build vs buy AI framework applies the same reversal-cost test to AI capability.
Choose by asking what a wrong decision costs to undo, not by asking which architecture you would rather work in.
Frequently asked questions
Is a rewrite always more expensive than incremental modernisation?
▾
No. A rewrite of a small, well-understood system with few integrations is usually cheaper, because incremental work adds a facade, dual running and reconciliation. The cost inverts as the system grows: above roughly six integrations and one unexplained batch process, incremental becomes the cheaper path to a working outcome.
How long can a strangler-pattern programme run before it becomes a problem?
▾
Until the last slice moves, you are operating two systems, so the cost of the intermediate state is real. Most programmes should be scoped to finish within four to six quarters. If the slice order cannot be sequenced to finish in that window, reduce scope rather than extending the parallel period indefinitely.
Can we modernise incrementally and add AI at the same time?
▾
Yes, and it is often the reason to start. Once a facade exists, a retrieval or agent layer can read through it without touching legacy code. Eazyware's legacy-to-AI modernization programme starts at $31,500 or ₹22,40,000 and sequences AI capability after the first slices are stable.