Your software is showing its age. Every change takes forever. Bugs multiply. Your team dreads touching certain parts of the system.
Do you keep patching? Or burn it down and rebuild?
This is one of the hardest decisions in software ownership. Here's how to think through it.
The Temptation to Rebuild
Rebuilding is seductive:
- Start fresh with modern technology
- Fix all the accumulated problems
- Build it "right" this time
But rebuilds are risky. Most fail or take 2-3x longer than estimated. You're not just building software — you're recreating years of accumulated business logic, edge cases, and institutional knowledge.
The Temptation to Patch
Patching feels safer:
- Keep what works
- Incremental changes
- Lower upfront cost
But patching has limits. Sometimes you're putting band-aids on a broken foundation. Every patch makes the next patch harder.
Questions to Guide the Decision
1. Can you still hire for this technology?
If your system is built on technology that's dying (or dead), finding developers gets expensive. If you can't hire, you can't maintain.
Rebuild signal: The technology is obsolete and talent is scarce.
2. How much institutional knowledge lives only in the code?
Old systems accumulate business rules that no one remembers implementing. Rebuild, and you'll rediscover these rules the hard way — usually when something breaks in production.
Patch signal: The system contains irreplaceable business logic that isn't documented anywhere.
3. What's the actual pain?
Be specific. Is it:
- Performance? Often fixable without full rebuild
- Features? Sometimes patchable, sometimes architectural
- Developer productivity? Might indicate deeper problems
- Security? Depends on where the vulnerabilities are
Rebuild signal: The pain is architectural — the fundamental design can't support what you need.
4. What's the business context?
- Stable business, incremental growth → Patch probably makes sense
- Rapid scaling, new market entry → Rebuild might be worth it
- Acquisition or investment coming → Depends on what buyers/investors want
Rebuild signal: The business is transforming and needs software that can transform with it.
5. Can you run both systems in parallel?
The strangler pattern: build new components alongside old ones, gradually migrating traffic until the old system can be retired.
If yes: This dramatically reduces rebuild risk. If no: Rebuild becomes much more dangerous.
The Hybrid Approach
Full rebuild vs. full patch is a false choice. Often the answer is:
Rebuild the parts that are killing you. Patch the parts that work.
Identify the specific components causing the most pain. Can you rebuild just those while keeping stable parts intact?
This requires good architecture (or someone who can create boundaries in a messy system), but it's often the pragmatic path.
Warning Signs You're Making the Wrong Call
Rebuilding when you should patch:
- "We'll build it right this time" (you said that last time)
- No clear requirements, just "better"
- The team that built the mess is building the replacement
- Timeline is under a year for a complex system
Patching when you should rebuild:
- Every fix creates two new bugs
- Simple changes take weeks
- You've lost developers who refuse to work on it
- Security vulnerabilities you can't fully address
The Conversation to Have
Before deciding, get honest answers to:
- What will the rebuild actually cost? (Double whatever they say)
- What will continued patching cost over 3 years?
- What's the business cost of the current pain?
- What's the risk of rebuild failure?
- What's the risk of the current system failing?
This isn't a technical decision. It's a business decision with technical inputs.
The Bottom Line
There's no formula. But here's a rough guide:
Patch if:
- Core architecture is sound
- Pain is localized
- Business is stable
- You can't afford rebuild risk
Rebuild if:
- Architecture fundamentally can't support your needs
- Technology is dying
- You can run systems in parallel
- Business transformation requires it
Do nothing if:
- The pain isn't actually that bad
- You don't have clear requirements for what "better" means
- You can't commit the resources to do it properly
The worst outcome: starting a rebuild you can't finish, while letting the old system rot.
Facing the rebuild-or-patch decision? Let's evaluate your options together