·2 min read
Fix or rewrite? 5 questions before replacing a system
A rewrite sounds appealing but is usually more expensive and riskier than planned. 5 questions to help you decide on evidence rather than gut feeling.
When a system becomes slow, hard to change and fragile, the suggestion to "rewrite it from scratch" arrives quickly. Sometimes that's the right call. Often, though, it's made before anyone truly understands where the problem lies.
Here are 5 questions worth answering first.
1. Is the problem the code, or the infrastructure and operations?
Many "slow" systems are slow because of missing database indexes, under-provisioned servers or no caching. Plenty of systems that "keep going down" fail because deployments are manual and there's no way to roll back.
A rewrite doesn't fix these by itself. The new version still needs a database, servers and a deployment process.
2. How many undocumented business rules does the current system hold?
A system that has run for a few years usually encodes a lot of small decisions: how amounts are rounded, a special case for one large customer, an extra approval step added after an incident. Most of it isn't written down anywhere.
A rewrite means rediscovering and recreating all of it. Miss one rule and you have a new production bug.
3. How long can the business wait?
During a rewrite the old system must keep running and keep getting fixes. Engineering effort is split in two. New features are postponed. Rewrites taking twice as long as planned is not unusual, and the cost of that delay adds up.
4. Can it be replaced piece by piece?
Instead of replacing everything at once, you can often:
- Stabilize infrastructure and deployment first.
- Carve out the most problematic module and rewrite just that part.
- Put an intermediate layer (an API) in front, so the old and new parts run side by side while features move over one at a time.
This lowers risk because every step is small, testable and reversible.
5. When does a rewrite genuinely make sense?
A rewrite is worth considering when:
- The platform is end-of-life with no safe upgrade path.
- The business model has changed so much that the old system no longer reflects how you work.
- Maintenance cost has been measured and is clearly higher than replacement cost, rather than just feeling that way.
Start with a diagnosis
All 5 questions need the same thing: a clear picture of the current state. That's why I usually start with a Health Check, so the choice between fixing, replacing piece by piece or rewriting is based on evidence before any big money is spent.
Sound like your system?
A 2–4 day Health Check tells you what to fix first and what can wait.