"Should we rebuild it or keep extending what we have?" We get this question at least once a month. Usually from a CTO or IT director who knows the current system has problems but is not sure whether fixing them costs less than starting over. The answer depends on the system. But there is a structured way to evaluate it so the decision is based on evidence, not frustration.
What You Need to Know
- The rebuild vs extend decision has a knowable answer, but it requires honest assessment of both paths, not just the frustrations with the current system
- Rebuilds are almost always more expensive and take longer than estimated. But sometimes they're still the right choice
- The key factor isn't how bad the current system is. It's whether the current system can evolve to meet future requirements at a reasonable cost
- A phased migration often beats both a full rebuild and continued extension
The Temptation to Rebuild
Every system accumulates frustration. Features that were added hastily. Workarounds that became permanent. Dependencies that are three major versions behind. Eventually, someone in the organisation says what everyone is thinking: "We should just start over."
It's appealing. A clean codebase. Modern technology. No legacy baggage. A chance to do everything right this time.
70%
of large-scale system rewrites exceed their original time and budget estimates
Source: Gartner Application Modernisation Research, 2016
The data on rewrites is sobering. Most take longer and cost more than planned. Not because the teams are bad, but because the old system contains years of accumulated business logic, edge cases, and integrations that aren't visible until you try to replicate them. The iceberg problem: the 20% you can see in the interface hides the 80% of logic underneath.
Martin Fowler's advice on this is straightforward: if the current system works and the team can still modify it, extending is almost always cheaper. The question is whether those conditions hold.
When to Extend
Extension is the right choice when:
The architecture can grow. The current system has a reasonable structure. New features can be added without rewriting existing ones. The codebase is understandable to new developers, even if it's not elegant. The database schema can accommodate new requirements.
The technology is supported. The language and framework still receive updates. Security patches are available. The hosting environment is maintained. Developers with the relevant skills can be hired.
The integrations work. The system's connections to other platforms are stable and documented. Adding new integrations doesn't require rearchitecting the existing ones.
The users are productive. Despite frustrations, people can do their jobs. The system isn't actively preventing work. The complaints are about inconvenience, not about inability.
If all four are true, extend. Invest in refactoring the worst parts, modernising the front end incrementally, and paying down engineering debt strategically. It's less exciting than a rebuild but it's lower risk and lower cost.
When to Rebuild
Rebuilding is the right choice when:
The architecture can't adapt. The system was designed for a different purpose and the current use case has outgrown it. Adding features requires fighting the existing structure at every step. Changes in one area break others unpredictably.
The technology is dying. The framework is no longer maintained. Security patches have stopped. The developer pool is shrinking. Hosting the system requires increasingly specialised (and expensive) infrastructure.
The integration layer is brittle. Adding new integrations is a multi-week exercise that risks breaking existing connections. The system wasn't designed to participate in an ecosystem.
The users are suffering. Not inconvenienced, actually unable to do their work effectively. Workarounds have become the primary workflow. Shadow IT has replaced official processes.
The rebuild decision is not about whether the current system is bad. It is a numbers conversation, not a feelings conversation.
John Li
Chief Technology Officer
The Honest Assessment
Before making the decision, we run through a structured assessment with the client. It takes time, but it prevents the most expensive mistake: rebuilding something that should have been extended, or extending something that needed to be replaced.
Technical debt inventory
What's actually wrong with the current system? Not "it feels old" but specific, documented issues. Outdated dependencies with known vulnerabilities. Database queries that don't scale. Code paths that nobody understands. Security practices that don't meet current standards.
Each item gets a rough cost to fix within the current system and a severity rating. Some engineering debt is cosmetic. Some is structural. The structural debt is what matters for the rebuild decision.
Future requirements mapping
What does the system need to do in 12, 24, and 36 months? Can the current architecture support those requirements? Where will it break?
This is the most important part of the assessment. A system that works today but can't accommodate known future needs is a candidate for replacement, not because it's bad now, but because extending it will cost more than the rebuild over three years.
Total cost of ownership comparison
Three-year cost of extending: maintenance, refactoring, new features, hosting, developer hours. Three-year cost of rebuilding: development, migration, data conversion, training, parallel running, hosting, developer hours.
The rebuild almost always looks more expensive in year one. It sometimes looks cheaper over three years. When it does, and the organisation can absorb the upfront cost, the rebuild makes sense.
The Third Option: Phased Migration
In most cases, neither a full rebuild nor full extension is the best answer. Phased migration is.
Identify the worst subsystem. The part of the application that causes the most pain, carries the most engineering debt, or can't accommodate future requirements.
Rebuild that subsystem. Using modern technology, with clean APIs, proper testing, and current standards.
Connect it to the existing system. The new subsystem communicates with the old system through APIs or a shared database. Users experience a gradual improvement rather than a single disruptive switch.
Repeat. Each quarter, migrate the next worst subsystem. Over 18-24 months, the entire system has been modernised without a single big-bang migration.
This approach has real advantages. The risk is distributed across multiple smaller deliveries. Each phase delivers visible improvement. The business never needs to run two complete systems in parallel. And if priorities change, the migration can pause without wasting the work already done.
2-3x
risk reduction when migrating in phases vs full rewrite, based on incremental delivery research
Source: ThoughtWorks Technology Radar, 2016
The Decision Framework
Here's how we walk through the decision at IDESIGN:
- Assess the current system honestly. Technical debt inventory, architecture review, user satisfaction.
- Map future requirements. What needs to change in the next 1-3 years?
- Cost both paths. Three-year TCO for extending vs rebuilding.
- Consider phased migration. Can you get the benefits of a rebuild without the risk?
- Factor in organisational capacity. Can the business absorb the disruption of a rebuild? Who maintains the old system during transition?
- Make the call. With data, not frustration.
The rebuild vs extend question has an answer. It's just not the same answer for every system. Do the work to find yours.