Someone at your company has said it: “We need to rewrite the whole thing from scratch.” It sounds decisive. It sounds like progress. And it almost always fails.
After thirty years in this industry, I have seen the “big rewrite” attempted dozens of times. The success rate is somewhere around 30%. The other 70% either get cancelled, run massively over budget, or ship something worse than what they replaced.
Why rewrites fail
The fundamental problem with a rewrite is that you are trying to hit a moving target while running a business on the existing system. The old system is still evolving — bug fixes, feature requests, regulatory changes. The new system has to replicate years of business logic that nobody fully understands.
The second year of a rewrite project is where things get ugly. The team is tired. The business is frustrated. Features that were “simple” in the old system turn out to be complicated edge cases that nobody documented.
The strangler pattern
Instead of replacing the system all at once, you replace it piece by piece. The name comes from the strangler fig — a vine that gradually grows around a tree until it replaces the original trunk entirely.
In practice, this means:
- Identify the most painful part of the legacy system
- Build a modern replacement for just that piece
- Route traffic to the new component while keeping everything else running
- Repeat until the old system is gone
The benefits
The strangler approach has several advantages over a rewrite:
- You deliver value continuously instead of waiting 18 months for a big bang
- Risk is contained — if one component fails, the rest still works
- The team stays motivated because they see progress weekly
- The business can reprioritize at any point without losing the investment
- You learn from each migration, making subsequent ones faster
The best modernization is one the business barely notices. Systems get better gradually, without anyone having to “switch over” on a scary Tuesday night.
Where to start
Map your legacy system’s components by two criteria: business pain and technical risk. Start with the component that scores highest on both. That gives you the best return on investment and the most compelling internal case study.
Do not start with the database. That is where most modernization projects go wrong. Start at the edges — the user-facing components — and work inward.
If you are facing a legacy modernization decision and want a second opinion, let’s talk through it. Thirty minutes, no cost, honest assessment.
