The pitch is always tempting: “Let’s just rewrite it.” Two years later the rewrite isn’t done, the old system still runs the business, and the team is exhausted. There’s a better way that delivers value the whole way through.
Why big-bang rewrites fail
A rewrite freezes feature work, reproduces years of hard-won edge cases from memory, and only pays off at the very end — if it ever ships. Meanwhile the business still depends on the system you’re trying to replace. The risk is concentrated exactly where you can least afford it.
The strangler pattern
Instead of replacing the monolith in one leap, we grow the new system around it and let the old one shrink:
- Find the seams. Identify a bounded capability — say, notifications or billing — that can be cleanly carved out.
- Put a router in front. A facade routes each request to either the legacy code or the new service, so we can move traffic gradually.
- Extract, verify, switch. Build the new service, run it in parallel, compare outputs, then flip that slice of traffic over.
- Repeat. One capability at a time, the monolith does less and less until what remains is small enough to retire.
Keeping it safe
Data is the hard part, so we migrate it incrementally with dual-writes and reconciliation rather than a risky overnight cutover. Feature flags, parallel runs and solid observability mean every step is reversible — if a slice misbehaves, we route back instantly.
The takeaway
Modernization shouldn’t mean betting the business on a multi-year rewrite. Carve the monolith down one capability at a time, ship value continuously, and keep every step reversible. Lower risk, and the lights stay on.
