Signs your app needs a rebuild, not another patch

Most software that lives long enough reaches an awkward stage. It still works and customers still rely on it, but every change takes longer than it should, small fixes cause new bugs, and the original developers are long gone. At some point someone asks the expensive question: should we keep patching this, or rebuild it?

There is no universal answer, but there are clear signals. This guide walks through them, explains why full rewrites so often go wrong, and describes the incremental approach that usually works best.

Warning signs that the system is holding you back

The technology is no longer supported

Frameworks, languages and runtimes have end-of-life dates after which they stop receiving security fixes. Some well-known examples: AngularJS reached end of life on 31 December 2021, Python 2 on 1 January 2020 and PHP 7.4 in November 2022. Running unsupported software means known vulnerabilities stay unpatched, and it gets harder to find developers willing to work on it.

You cannot update dependencies

Libraries are years out of date because updating one breaks another. Security advisories pile up with no realistic way to apply the fixes.

Every change breaks something else

A small change to the checkout breaks the admin panel. There are no automated tests, so the only way to find out is in production, from customers.

Deployments are rare and frightening

Releases are manual, risky, done late at night and involve one person who knows the steps. Teams start batching changes to avoid deploying, which makes each release even riskier.

Nobody understands the system

Knowledge sits with one or two people, or with nobody. New developers take months to become productive, and estimates are guesses.

Delivery keeps slowing down

Features that once took days now take weeks. More and more time goes into working around the system instead of improving the product.

The product has outgrown the design

The business now works in a way the data model was never meant to support: multiple countries, new pricing models, a marketplace where there used to be a single seller. Every new requirement is a hack on top of a hack.

Running costs are out of proportion

The system needs large servers or expensive licences for the amount of work it does, and performance problems cannot be fixed without changing the architecture.

When patching is still the right answer

• The core business logic and data model are sound, and problems are concentrated in specific areas.
• The technology stack is still supported and widely used.
• Problems come mainly from missing process: no tests, no reviews, no deployment pipeline. These can be fixed without rewriting code.
• The product is stable and only needs modest changes for the foreseeable future.

Why full rewrites are risky

The idea of starting fresh is appealing, but complete rewrites have a long history of running late and over budget. Fred Brooks warned about the “second-system effect” in The Mythical Man-Month: second versions tend to be over-engineered as teams try to include everything they wished they had built the first time. Other common traps:

• Hidden knowledge: the old system contains years of bug fixes and edge-case handling that nobody documented.
• Moving target: the business keeps needing changes to the old system while the new one is being built, so the rewrite has to catch up with a moving product.
• No value until the end: customers see nothing new for months, and the project is easy to cancel halfway.
• Data migration: moving years of real data into a new model is often harder than building the new system.

The strangler fig approach

Martin Fowler named this pattern after strangler fig vines, which grow around a tree until they can stand on their own. Instead of rewriting everything at once, you build new parts of the system alongside the old one and gradually route traffic to them, one area at a time:

1. Put a routing layer, such as a reverse proxy or API gateway, in front of the existing system.
2. Choose one well-bounded area to replace first, ideally one that causes pain and changes often.
3. Build the new version, connect it to the shared data or sync data between systems.
4. Route that area’s traffic to the new component, keeping the ability to switch back.
5. Remove the old code for that area, then repeat with the next.

Each step delivers value, risk stays small, and the business keeps running throughout. You can also stop at any point if priorities change, with everything delivered so far still in use.

A simple scorecard

Score each dimension from 1 to 3. A low total suggests investing in process and targeted fixes. A high total suggests planning an incremental replacement. A middling score usually means fixing process first, then reassessing in a few months.

Planning the decision

1. List the business outcomes you need over the next one to two years.
2. Audit the system: technology versions, test coverage, deployment process, documentation and known problem areas.
3. Score it honestly with the people who use and maintain it.
4. Fix process gaps such as tests, pipelines and monitoring, which help in every scenario.
5. If replacement is justified, plan it incrementally, starting with the area that delivers the most value.

We regularly take over ageing applications, stabilise them and modernise them step by step. If you are unsure whether to patch or rebuild, a short audit will give you a clear recommendation and a realistic plan.