The most common request I get from clients isn't "build something new." It's "our system is 10 years old, it's breaking, and we're afraid to touch it." Legacy modernization is where I spend most of my consulting hours — and the first thing I tell every client is: don't rewrite from scratch.
Why Rewrites Fail
I've seen it happen three times in my career: a team decides to rebuild their legacy system from the ground up. Two years later, the new system has half the features of the old one, the budget is exhausted, and the old system is still running in production because the new one isn't ready.
The reason is simple: the legacy system contains years of accumulated business logic, edge cases, and workarounds that nobody documented. A rewrite attempts to replicate all of this from memory — and memory is unreliable.
The Strangler Fig Approach
Instead of replacing the system, I wrap it. Named after the strangler fig tree that grows around its host, this pattern works by:
- Identifying the highest-pain modules — Which parts of the system cause the most bugs, slowdowns, or developer frustration?
- Building modern replacements — New services that handle the same functionality, with proper tests and documentation.
- Routing traffic incrementally — A reverse proxy or API gateway sends requests to the new service for migrated features and the old system for everything else.
- Decommissioning piece by piece — Once a module is fully migrated and stable, remove it from the legacy system.
A Real Example
At a previous engagement, I modernized a .NET WCF service that had been in production for 8 years. The system handled insurance policy processing — critical, high-volume, zero tolerance for downtime.
We started with the reporting module (read-only, low risk). Built a new Go service, validated outputs against the legacy system for two weeks, then switched traffic. Total downtime: zero. Total risk: minimal.
Over 6 months, we migrated 70% of the system. The remaining 30% — deeply embedded business logic with hundreds of edge cases — stayed on the legacy stack, behind a clean API boundary. And that's fine. Not everything needs to be new.
When to Actually Rewrite
There are legitimate cases for a full rewrite: the technology is truly obsolete (no available developers), the codebase is so tangled that even small changes take weeks, or the business requirements have fundamentally changed. But even then, I recommend building the new system in parallel, not replacing the old one cold.
The safest modernization is the one your users never notice.