You’ve inherited a legacy system and your team is pushing hard for a complete rewrite. The codebase is messy, they say. It’ll be faster to start fresh.
But this decision isn’t just technical—it’s strategic. And it’s got game theory implications that can make or break your next year.
You’ve got three paths: complete rewrite (big bang), incremental refactoring, or the strangler fig pattern. Each one has different payoffs and risks. Most teams fall into the sunk cost trap—continuing failed rewrites because of money already spent.
This article is part of our comprehensive guide on game theory for technical leadership, where we explore strategic frameworks that help CTOs make better decisions. Here, we’re going to apply game theory to migration decisions: sunk costs, option value, and credible commitment. You’ll understand when walking away from legacy code is rational versus throwing good money after bad.
What Is the Strangler Fig Pattern and When Should You Use It?
The strangler fig pattern lets you gradually replace legacy systems by building new functionality alongside old code. Martin Fowler coined the term after strangler fig plants that grow around host trees, eventually replacing them.
A facade or proxy intercepts requests going to your legacy system. It routes those requests to either the legacy application or new services. Over time, the new system slowly strangles the old one as features migrate incrementally.
Unlike big bang rewrites, your production system stays operational throughout.
The routing layer directs traffic to new or old components based on migration progress. You can pause, pivot, or reverse migration decisions as you learn. That’s what preserving your ability to change course looks like.
Use the strangler fig when your legacy system is business-critical and downtime would be unacceptable. Both systems operate side by side to ensure continuous availability.
What Is the Difference Between Refactoring and Rewriting Code?
Refactoring means restructuring existing code without changing external behaviour. You’re improving the internal structure—breaking large functions into smaller methods, eliminating redundancy, organising for better readability.
Rewriting means building a new house and abandoning the old one entirely. You’re discarding the old codebase and building from scratch.
Refactoring preserves institutional knowledge embedded in code. That messy legacy system contains years of bug fixes and edge-case handling. Rewrites sacrifice proven functionality for the appeal of a clean slate.
Refactoring is incremental and reversible. You can stop, change direction, or double back if the path isn’t working. Rewrites are commitment-heavy. You’re all-in until you reach feature parity.
Code review discovers why existing code works the way it does—bug fixes, edge cases, undocumented requirements. Rewrites often rediscover problems the old code already solved.
Why Do Big Bang Rewrites Usually Fail?
Joel Spolsky wrote that rewrites are the single worst strategic mistake any software company can make.
Netscape made this mistake. Their 6.0 rewrite took three years while competitors gained market share. The old Netscape code was messy but it worked pretty well on an awful lot of real world systems.
Existing code contains years of bug fixes. Rewrites underestimate the complexity hidden in “messy” legacy systems. Edge cases no one thought of before are the same ones no one thinks of now.
Feature parity takes longer than expected. The business can’t wait. You generate no revenue during the rewrite while competitors iterate and ship.
Then there’s the sunk cost fallacy. Teams keep failed rewrites going: “We’ve invested too much to stop now.” That’s escalation of commitment—doubling down on a failing strategy.
The all-or-nothing cutover means no learning before full deployment.
What Is the Sunk Cost Fallacy in Software Rewrite Decisions?
The sunk cost fallacy is the inability to let go of poor decisions because you already invested a lot.
“We’ve already spent six months on the rewrite, we can’t stop now.” That’s the classic fallacy right there.
Rational decision-making means evaluating future costs and benefits. Past investment shouldn’t determine whether you continue a failing project.
The tricky part is distinguishing this from technical debt. Technical debt is future cost of rework. Sunk cost is past investment.
Run this test: “If I were starting from zero today, would I choose this same path?” If the answer is no, you’re in the sunk cost trap.
Game theory frames this clearly. Sunk costs are irrelevant to optimal future strategy. What matters is expected value of future outcomes.
You need to distinguish between preserving your ability to change course (which is valuable) and throwing good money after bad (which is the sunk cost trap). Understanding this distinction means looking at what keeping your options open actually means—the same strategic thinking applies when evaluating vendor lock-in economics and switching costs.
How Does Option Value Apply to Migration Strategy Decisions?
Option value is the strategic worth of keeping future choices available. In financial markets, options give you the right but not the obligation to take action.
Migration strategy works the same way. The strangler fig maximises option value through incremental progress with continuous reassessment. You can pause, pivot, or reverse decisions as circumstances change. This concept of preserving strategic options appears across many technical leadership decisions.
Big bang rewrites destroy option value. You commit irrevocably with no reversibility.
Reversibility matters. How difficult would it be to reverse the decision? How much time will you lose? Can you adjust over time?
Higher uncertainty favours preserving options rather than committing irrevocably. The strangler fig may cost more but it buys strategic freedom. When you’re uncertain, that premium for flexibility pays off.
Big Bang Migration vs Incremental Migration: What Are the Real Trade-offs?
Big bang means complete cutover in a single event—an all-or-nothing deployment.
Incremental means gradual migration. Features move over time with parallel systems during transition.
Big bang advantages: clean cutover, no dual-system maintenance, faster theoretical completion.
Big bang risks: no learning before full deployment, single point of failure, irreversible commitment.
Incremental migration allows controlled, smaller releases making it easier to refactor along the way. You learn during migration. You deliver continuous value.
Incremental costs: dual-system complexity, longer calendar time, routing layer overhead.
The real trade-off is speed versus safety. Commitment versus optionality.
Big bang migrations can overwhelm teams and introduce substantial risk compared to incremental approaches that deliver continuous value.
Rewrite vs Refactor vs Strangler Fig: Which Migration Strategy Should You Choose?
The decision depends on system criticality, risk tolerance, time constraints, and uncertainty level.
Rewrite when the system is genuinely unsalvageable. When the technology is completely obsolete and starting fresh is cheaper than repair. These cases are rare.
Refactor when existing architecture is sound and incremental improvements suffice.
Strangler fig when the system is business-critical and cannot tolerate downtime. When there’s high uncertainty about the migration approach. When you need reversibility.
Think payoff matrix. Rewrite is high-risk, high-reward. Refactor is low-risk, low-reward. Strangler fig balances both with preserved optionality.
The chosen migration approach significantly impacts your ability to manage technical debt. Watch out for sunk cost risk in big rewrites. The governance mechanisms and incentive structures around shared services and technical debt also influence which migration strategy will succeed.
Key questions: How critical is the system? How uncertain is the path? Do you need reversibility?
When Is a Complete Rewrite Justified Versus Iterative Refactoring?
Technical bankruptcy is when the legacy system is genuinely unsalvageable. Technology obsolescence means the platform is no longer supported or has unfixable security vulnerabilities.
Run a cost-benefit analysis. Is rewrite cheaper than cumulative refactoring costs?
Fundamental paradigm shift matters. When architecture is heavily misaligned with current technology standards or requires major restructuring—like redesigning the database schema—a full rewrite becomes practical.
Warning: “The code is messy” is insufficient reason. Rewarded with a blank slate, the same people will recreate the same problem.
Beware disguised sunk cost thinking. “We have too much technical debt” conflates sunk cost with future cost.
Rational test: If starting from zero today, would building a new system be optimal? If yes, rewrite might be justified.
Even when rewrite is justified, consider strangler fig for de-risking.
How to Evaluate Whether Your Legacy System Needs Refactoring or Rewriting?
Use a multi-dimensional framework: business criticality, technical health, skill availability, opportunity cost.
Technical debt audit should include code-level analysis detecting inefficiencies using metrics like cyclomatic complexity and code duplication. Architecture evaluation identifies tightly coupled components. Production metrics measure downtime and deployment failures.
Code quality metrics matter. Test coverage, coupling, complexity, documentation.
Architecture evaluation asks: Does the system have scalability limits? Security vulnerabilities? Obsolete technology?
Team capability is often overlooked. Does your team have skills to maintain legacy or build new?
Business alignment: Does current architecture support your strategic direction?
Use a cost-impact matrix to classify technical debt. High-impact, low-cost fixes are quick wins. High-impact, high-cost challenges are architecture modernisation.
Avoid emotional decisions. “I hate this codebase” is not strategic rationale.
How to Implement the Strangler Fig Pattern Without Breaking Production?
Start with the routing layer. This directs traffic to legacy or new system based on feature. Use an API gateway, service mesh, or custom router.
Choose a low-risk feature for initial migration. Build confidence before tackling complex features.
Build the new feature in the new system alongside legacy. Implement feature flags—runtime toggles that enable or disable features without redeployment.
Deploy with a dark launch. New code goes to production but doesn’t serve user traffic.
Gradual rollout next. Percentage-based traffic splitting—1%, then 5%, then 25%, eventually 100%. Monitor metrics at each stage.
Maintain rollback capability. Instant revert if problems detected.
Data consistency techniques matter. Dual-write patterns update both legacy and new databases during transition. Change data capture monitors transactions and replicates changes.
Retire the legacy feature only after new version is proven stable. Then repeat.
How to Recognise and Avoid the Sunk Cost Trap in Migration Projects?
Warning signs: “We’ve invested too much to stop now” reasoning. Project metrics diverging—timeline stretching, costs escalating.
Escalation of commitment means increasing investment in a failing strategy. Team morale declining. Business value not materialising.
Opportunity cost mounting—competitors iterating while you rebuild.
Recognition checklist: If starting from zero today, would you choose this path? If no, you’re in the trap.
Evaluate only future costs and benefits. Ignore sunk costs—they’re gone regardless.
Exit strategies matter. Graceful termination is possible. Salvage useful work. Return to refactor or strangler fig.
The hard part is psychological. Continuing a failing strategy because of past investment is irrational.
How to Create a Credible Migration Threat When Negotiating with Vendors?
Credible commitment means your migration threat is believable because you’ve invested in making it real.
Cheap talk—just threatening without investment—is not credible.
Making threats credible requires actual strangler fig progress. A working proof of concept reduces vendor lock-in. A dedicated team demonstrates seriousness.
Having options and making vendors aware increases your leverage.
When vendors believe you can actually leave, contract terms improve.
The strangler fig keeps the migration threat alive even after you negotiate a better deal.
Negotiate a detailed exit plan highlighting when and how to terminate. This shows you’ve thought through the exit.
Bluffing risk is real. Empty threats damage future credibility.
Sometimes building the exit option is more valuable than exercising it.
FAQ Section
What is technical debt and does it justify a rewrite?
Technical debt is future cost of rework from choosing quick solutions over better approaches. It represents the implied cost you’ll pay later for taking shortcuts now. Technical debt alone does NOT justify rewrites. You need to evaluate whether refactoring is cheaper than rewriting, considering both the cost of paying down the debt gradually versus starting fresh.
How long does strangler fig migration typically take?
Highly variable—months to years depending on system size. Unlike big bang rewrites with theoretical end dates, strangler fig delivers value incrementally throughout. Focus on continuous delivery rather than completion timeline.
Can I pause a strangler fig migration if business priorities change?
Yes. That’s one of the big advantages. Strangler fig allows pausing, pivoting, or reversing migration decisions as circumstances change. Big bang rewrites commit irrevocably. This flexibility is valuable when priorities shift or when you discover the initial approach needs adjustment.
What if my team insists on a rewrite because the code is “messy”?
“Messy code” is insufficient justification. Question whether messiness reflects actual technical bankruptcy or developer preference for greenfield projects. Consider that existing code contains years of bug fixes that rewrites must rediscover.
How do I know if I’m in a sunk cost trap?
Apply the “start from zero” test: if beginning today with zero prior investment, would you choose the current path? If no, you’re in a sunk cost trap. Also watch for escalating investment despite worsening metrics and “too much invested to stop” reasoning.
What is the difference between dark launch and feature flags?
Dark launch means new code deployed to production but not serving user traffic—used for testing infrastructure. Feature flags are runtime toggles enabling or disabling features without redeployment—used for gradual rollout and instant rollback. Both are de-risking techniques often used together.
Can strangler fig work for monolith-to-microservices migration?
Yes—strangler fig is ideal for decomposing monoliths. Build new microservices alongside the monolith. The routing layer directs traffic based on feature migration progress. You gradually extract functionality while preserving production stability.
How do I maintain team morale during long migration projects?
Strangler fig helps by delivering incremental value rather than a “big reveal” after years of work. Celebrate feature milestones. Maintain production stability throughout. Show business impact of migrated features. Avoid the rewrite morale trap—years of work with nothing to show.
What is technical bankruptcy and when should I declare it?
Technical bankruptcy is the rational decision that a legacy system is unsalvageable and a fresh start is cheaper than repair. Declare when technology is genuinely obsolete, fundamental architecture is incompatible with requirements, and cost-benefit analysis favours rewrite. It’s a rare condition—most systems are salvageable.
How does reversibility affect migration strategy choice?
Reversibility is ability to undo migration decisions if problems emerge. Strangler fig maximises reversibility through incremental steps and rollback capability. Big bang eliminates reversibility—single cutover with no return path. Value reversibility when uncertainty is high.
Can I use strangler fig to improve vendor negotiating position without actually migrating?
Strategically viable but ethically complex. Building a credible exit option creates real negotiating leverage even if you don’t intend to complete migration. However, bluffing without follow-through damages future credibility. The option value framework suggests keeping the exit option alive is legitimate strategy.
For a complete overview of how game theory concepts like credible commitment, sunk cost fallacy, and option value apply across technical leadership decisions, see our comprehensive guide to game theory for technical leadership.
