Rewrite, Refactor, or Strangle? A Practical Decision Framework
Rewrite, refactor, or strangle is rarely a purely technical question. Teams usually arrive at it after pain has already accumulated: delivery has slowed, the user experience is inconsistent, incident recovery is awkward, staffing has become harder, or the architecture has turned simple changes into negotiations with history.
The wrong move is expensive because each option optimises for something different. Rewrites promise reset, refactors promise continuity, and strangler approaches promise controlled transition. None of them is automatically adult or automatically naive. The job is to pick the shape that matches the actual risk.
What the Decision is Really About
The decision starts with how much of the current system still deserves to survive. If the domain model, operational behaviour, release mechanism, and team understanding are all salvageable, a refactor or strangler path usually has more going for it than a clean‑slate rewrite. If the foundations are structurally hostile to the future state, pretending otherwise only prolongs the damage.
Name the constraint that dominates the choice. A rewrite may reduce inherited coupling but demands parallel delivery and migration confidence; a refactor preserves operations but accepts slower structural gains; a strangler path needs a seam the business can run for long enough.
The Risk of the Wrong Move
Teams misread the choice when they let emotional exhaustion make the argument for them. A codebase can be frustrating without being beyond recovery, just as a polished rewrite proposal can still be strategically reckless if the business cannot absorb the freeze or the migration risk involved.
Choosing a reset because the code feels old can exchange visible mess for hidden programme risk. Conversely, insisting on incrementalism when every release depends on the same hostile foundation can turn caution into a very expensive delay.
A Practical Way to Proceed
A more dependable framework is to examine four things explicitly: change cost, operational risk, delivery continuity, and organisational memory. The more we can preserve those sensibly, the more attractive incremental change becomes. The more each of them is already broken, the more radical intervention may be justified.
Turn the four factors into evidence. Measure lead time and incident recovery, map the knowledge concentrated in people, identify a viable extraction seam, and test whether the organisation can fund old and new paths together before committing to the label.
A Worked Example: Selfridges
When I joined Selfridges in 2020, three partial modernisation attempts had left three codebases, with many changes repeated across all three. I started with a small experiment: could a React component from the newest implementation run in each section? Once that worked, we could introduce shared components progressively whilst continuing to deliver customer‑facing features.
Looking back through these four factors, repeated implementation was the change cost. The small integration experiment tested the operational risk, the existing sections kept delivery moving, and their behaviour remained available to guide the work. Refactoring each codebase separately would have left the duplication in place. A fourth replacement could have become another unfinished platform. That made progressive replacement a useful fit for this situation, rather than a reason to choose it for every project.
Keeping the Shape Healthy Over Time
We have usually picked the right shape when the migration path stays understandable to the wider organisation and when progress can be shown in meaningful increments rather than only in a distant future launch moment. Credibility matters as much as purity here.
Revisit the decision at migration milestones. If the assumed seam will not hold, operational cost is rising, or delivery continuity is worse than forecast, change the route rather than defending the original architecture presentation.
Sources Worth Keeping Nearby
Wrapping Up
Key Takeaways
- Rewrite, refactor, and strangle optimise for different forms of risk.
- Emotional fatigue is not a sound enough basis for choosing a rewrite.
- The strongest decision framework makes delivery continuity and change cost explicit.
The right intervention is the one whose delivery risk the organisation can carry whilst the system improves. Rewrite, refactor, and strangler plans should be judged by their migration evidence, not their rhetorical neatness.