Large rewrite or incremental refactoring?
Updated: 2026-09
A large rewrite promises a clean break and occupies the team without producing anything for the business. Incremental refactoring delivers value continuously but needs discipline. In most cases the incremental route wins — because large rewrites are rarely finished.
When technical debt becomes noticeable, the wish for a big clean-up project appears quickly: do it properly once, and afterwards everything is clean. The wish is understandable and usually goes wrong in practice.
The reason is organisational rather than technical. A rewrite project without visible business progress is under permanent pressure to justify itself. As soon as something urgent intervenes — and it does — it gets interrupted. A half-completed rewrite leaves two structures side by side and is worse than the starting state.
Head to head
| Criterion | Large rewrite | Incremental refactoring |
|---|---|---|
| Risk | High, a large change at once | Low, small steps |
| Visible progress | Only at the end | Continuous |
| Sustainability | Low, interrupted by anything urgent | High, because embedded in normal work |
| Business delivery | Stalls during the rewrite | Continues in parallel |
| Total effort | Lower on paper | Spread out, overall often similar |
| Risk of abandonment | High, with a poor intermediate state | Low, every step is complete |
When Large rewrite wins
- —The existing approach is fundamentally wrong, not merely untidy.
- —A clearly bounded area can be replaced in isolation.
- —There is a firm commitment that the project will be carried to the end.
When Incremental refactoring wins
- —The system fundamentally works and is merely hard to maintain.
- —Business requirements continue in parallel and cannot pause.
- —Experience says urgent work intervenes regularly.
Our take
Our view: in most cases the incremental route is right — the rule of leaving every area you touch a little better carries surprisingly far over months and needs no approval for a special project. It only works, however, with a binding definition of done; otherwise it is the first thing dropped under time pressure.
A large rewrite is justified when the approach itself is wrong and incremental improvement only polishes a wrong structure. It then belongs planned as its own project, clearly bounded and with an explicit commitment that it will not be interrupted at the first urgency.
Parent service: Custom Software Engineering
Matching offers
Legacy modernisation
Legacy modernisation makes grown software maintainable and future-proof again — step by step rather than in a risky big bang. The result is a system that can evolve without halting operations or rebuilding everything at once.
Tech due diligence
A tech due diligence examines what sits under the hood before an investment or acquisition: architecture, code quality, scalability, security and technical debt. The result is an honest risk assessment that can prevent an expensive wrong decision — before it is taken.
FAQ
How do we convince management of refactoring?
Not as a separate project but as part of normal work — by folding the effort into estimates. A separate request for clean-up work is almost always refused.
What if we have no time for refactoring?
Then the effort for every future change keeps rising. The time is therefore not saved but merely deferred — with interest.
How do we know a rewrite is needed?
When it is not the implementation that is untidy but the underlying approach that no longer fits today’s need. A cleanly implemented wrong approach does not become right through refactoring.