We wrote about the rebuild vs extend decision back in 2017. Five years on, the advice mostly holds, but we've seen enough failed rebuilds since then to sharpen the framework. The pattern is consistent enough to be predictable, and preventable.
What You Need to Know
- Most enterprise rebuilds fail not because of technical problems but because the scope of the old system was never properly understood
- The sunk cost trap works in both directions: organisations stick with bad systems too long, then commit to rebuilds too aggressively
- A decision framework based on three factors (architecture adaptability, team capability, business timeline) produces better outcomes than gut feel
- Phased migration remains the lowest-risk approach for most situations
The Pattern
We've been involved in, or been asked to rescue, about a dozen enterprise rebuilds across our history. The ones that fail share a remarkably consistent pattern.
Phase 1: Frustration. The existing system is slow, hard to modify, and everyone complains about it. Someone senior says "we should just start over."
Phase 2: Excitement. A new technology gets chosen. The team is energised. Early progress is fast because the easy parts get built first.
Phase 3: Discovery. The team starts replicating the complex business logic from the old system and discovers there's far more of it than anyone documented. Edge cases, workarounds, regulatory requirements, integration dependencies.
Phase 4: Stall. The rebuild is now behind schedule and over budget. The old system is still running. You're paying for both. Political pressure mounts.
75%
of large-scale application rewrites are delivered late, over budget, or abandoned
Source: McKinsey Digital, Technology Transformations Survey, 2021
Phase 5: Compromise. Features get cut. The new system launches with less capability than the old one. Users revolt. Someone asks why we didn't just fix the old system.
The Sunk Cost Trap (Both Directions)
The sunk cost fallacy is well understood: don't continue investing in something just because you've already spent a lot on it. What's less discussed is that it works in both directions.
Organisations stay with failing systems because of sunk cost. But they also commit to rebuilds because of sunk cost. Once you've spent six months and $400,000 on a rebuild, admitting it was the wrong call feels impossible. So you keep going.
The hardest conversation in enterprise tech isn't "should we rebuild?" It's the one six months into a rebuild when the honest answer is "we shouldn't have." Nobody wants to have that conversation, so nobody does.
John Li
Chief Technology Officer
A Better Framework
After enough of these, we've settled on three factors that predict rebuild success better than anything else.
1. Architecture Adaptability
Can the current system's architecture accommodate the next three years of requirements? Not "is it perfect" but "can it bend?" If the database schema can grow, the API layer is reasonable, and new features can be added without rewriting existing ones, extending is almost certainly cheaper.
If the architecture is fundamentally wrong for where the business is going, that's a genuine rebuild signal. A system built as a monolith that needs to become a multi-tenant platform isn't going to get there through incremental changes.
2. Team Capability
Does the team have the skills to execute a rebuild? Not just the technical skills, but the institutional knowledge of why the current system works the way it does. The most dangerous rebuild scenario is a new team building a replacement without deep understanding of the business logic.
We've seen this go wrong twice in the last three years. A new vendor is brought in, the old team has moved on, and nobody can explain why the pricing engine has seventeen special cases. Each one exists for a reason. Lose that knowledge and the rebuild is doomed.
3. Business Timeline
How long can the business wait? A rebuild takes 12 to 24 months minimum for anything substantial. If the business needs capability in six months, a rebuild won't deliver it. If the business has a two-year window and the current system is genuinely blocking strategic goals, a rebuild might be worth the risk.
The timeline factor is the one that gets ignored most often. The business case for a rebuild usually assumes a 12-month delivery. The actual delivery is 18 to 24 months. By then, the business requirements have shifted and the rebuild is solving last year's problem.
What We Recommend
For most organisations: don't rebuild. Invest in modernising the parts that matter most. Extract the worst components into services. Wrap the legacy system in a better API layer. Improve the front end incrementally.
For the minority where a rebuild is genuinely the right call: do a proper assessment first. Map every piece of business logic. Interview every team that uses the system. Budget for 18 months, not 12. And keep the old system running until the new one has proven itself.
The boring answer is usually the right one.