Rebuild the system or keep developing it?
Continuing to develop is the right starting point: gradual modernization delivers value continuously and preserves business logic built up over years. A full rewrite is only justified when the platform is dead, the skills can't be found, or the architecture blocks the business. Developers systematically underestimate rewrites, so demand hard evidence before choosing that path.
When a system starts to creak, the same question always comes up: should we rewrite the whole thing from scratch, or keep building on what we have? Few technical decisions are this emotionally charged. Both camps have good arguments – and both have predictable blind spots. Here’s the reasoning that helps you decide on facts rather than frustration.
Why a full rewrite is so tempting
Developers working in an old codebase see its worst sides every day: messy structure, outdated dependencies, simple changes that take weeks. The idea of starting over with clean architecture and modern technology is genuinely appealing.
But watch the comparison being made. Whoever proposes a rewrite is pitting a real system, with all its scars, against an imagined system that hasn’t yet met reality. The new one always looks better on the whiteboard than the old one does in production.
Why rewrites are systematically underestimated
Two mechanisms make rewrites end up bigger than planned almost every time.
Hidden business logic. A system that’s been running for ten years has accumulated thousands of small decisions: special rules for a particular customer type, handling of odd date cases, exceptions added after an incident. Most of it is undocumented and only visible in the code. The new version has to recreate all of it for the business to function, but the estimate usually only counts the features visible on the surface.
Second-system syndrome. Once the team finally gets to build something new, they want to fix every old mistake and add everything they’ve been missing – at the same time. Version two therefore ends up more ambitious than anyone actually ordered: bigger scope, a longer project, higher risk.
On top of that comes duplicated work. The business can rarely freeze development for a year or two, so every new feature has to be built into both the old and the new system – otherwise the new one is already outdated at launch.
Gradual modernization is the right starting point
For most systems, the baseline recommendation is therefore to keep developing and modernize step by step: improve the code from within, replace the most problematic part first, and let the rest live on behind stable interfaces.
- Value arrives continuously. Each replaced part improves day-to-day work immediately, instead of all the value sitting at the end of a multi-year project.
- Risk is contained. If a step goes wrong, it affects one part of the system – not the whole business at once.
- Course can be corrected. Priorities can be adjusted between phases, as the business learns what actually delivers results.
- Business logic is preserved. The hidden logic moves piece by piece and is verified against the old system’s behavior, instead of being reinvented in one sweep.
When a full rewrite is actually justified
There are situations where gradual modernization isn’t enough. They’re fewer than people think, but they’re real:
| Criterion | What it means |
|---|---|
| Dead platform | The language, framework, or platform no longer has support – security holes go unpatched and modern tools don't work with the system |
| Impossible to staff | Developers skilled in the technology can no longer be hired or contracted at a reasonable cost |
| Architecture blocking the business | The foundational design prevents what the business must do – serve more customers, integrate with partners, or launch new offerings |
If the system meets one or more of these criteria, a rewrite is worth investigating seriously. Even then, keep it as limited as possible: recreate what’s actually used, not everything that was ever built.
The bias warning cuts both ways
Rewrite enthusiasm is the most common trap, but the opposite exists too. Whoever has invested years in a system resists the idea that it’s played out its role – and so it keeps getting patched long after the math has stopped adding up. If maintenance eats most of the development budget, if every release requires manual acrobatics, and if nobody dares touch certain parts of the code, then “keep going as usual” isn’t the safe choice. It’s just the quiet one.
How to make the decision in practice
Take a concrete example: a wholesale company with an order system built in 2012. The system works, but the platform is nearing end of life and two key developers are nearing retirement. Instead of choosing between “keep everything” and “rewrite everything,” the company maps the system in parts. The integrations move first to a modern middle layer, then the customer portal is replaced, and the core – the pricing logic that works – gets to live on behind a stable API until it too can be replaced.
The result is a plan where each phase has its own budget, its own value, and a point where you can pause without being left with a half-finished build. That’s how you get out of a creaking system without betting everything on one card.
Want a second opinion on your path forward? At Weapp we do this kind of technical mapping as part of our services – get in touch and we’ll look at the circumstances together.
Frequently asked questions
What's the difference between a rewrite and a refactor?
A rewrite means rebuilding the system from scratch in a new codebase, often on new technology. A refactor improves the existing code from within – structure, testability, performance – without rebuilding the functionality. A refactor delivers value continuously, while a rewrite only delivers value once everything is done.
Why do rewrites so often end up more expensive than planned?
Mainly because old code carries hidden business logic: special rules, exceptions, and bug fixes nobody documented. The new version has to recreate all of that to work, but the estimate usually only counts the features visible on the surface. Expect the hidden logic to be far larger than the visible requirements list.
What is second-system syndrome?
The tendency for version two of a system to become overambitious. Once the team finally gets to build something new, they want to fix every old mistake and add everything they've been missing, all at once. The result is often a bigger, more complex project than the system it was meant to replace.
Can we keep developing the system while it's being rewritten?
Yes, but it's one of the biggest risks of a full rewrite: every new feature has to be built twice, once in each system. Many freeze development during the rewrite, which in practice pauses the business's evolution. Gradual modernization avoids the problem, since there's only ever one system in production.
How long does a full rewrite take?
For a business-critical system, it's rarely a matter of months but of years, especially if the old system has been developed for a decade. A common rule of thumb is to double the initial estimate – hidden business logic, data migration, and parallel operation eat time that doesn't show up in the plan.