Every established company has one: the system nobody wants to touch. It runs the core of the business, the person who built it left years ago, and every new feature request starts with a sharp intake of breath. Eventually someone proposes the obvious fix — rewrite it.
Resist that instinct. Big-bang rewrites carry a brutal failure pattern: eighteen months of parallel development, a moving target (the old system keeps changing while you rebuild it), and a single terrifying cutover weekend. Many never ship at all; the business loses two years and keeps the legacy system anyway.
The strangler approach
The alternative has an ugly name and an excellent track record: the strangler pattern. Instead of replacing the system in one move, you grow a new system around it, redirecting one capability at a time until the old core has nothing left to do.
In practice:
- Put a front door on it. Route traffic to the legacy system through a gateway or facade you control. Nothing changes yet — but you now have a place to redirect from.
- Pick one seam. Choose a capability that is valuable, painful and reasonably separable — invoicing, customer onboarding, a reporting module. Build it new, behind the facade.
- Redirect and retire. Route that one function to the new component. The legacy code path stays in place as a fallback until the new one has earned trust — then it’s switched off.
- Repeat, in value order. Each cycle delivers working software the business can use, funds the next cycle with visible wins, and shrinks the legacy risk.
Why this works commercially, not just technically
The strangler approach changes the risk shape of modernisation. There is no all-or-nothing cutover; each step is small enough to reverse. Budget holders see delivery every quarter instead of a distant promised horizon. And if priorities shift mid-journey — they always do — you stop at a sensible point with real value banked, not with half a rewrite.
The two mistakes to avoid
Skipping the data plan. The hard part of legacy replacement is rarely the screens; it’s the data model underneath. Decide early which system is the source of truth for each entity during the transition, or you’ll spend your project reconciling.
Letting the facade become the system. The gateway is scaffolding, not a home. Teams that park logic “temporarily” in the routing layer build themselves a second legacy system. Keep it thin, keep it dumb.
Start with the map
A modernisation roadmap starts with an honest inventory: what the system does, who depends on which parts, and where the pain concentrates. That assessment typically takes weeks, not months — and it converts “we should really rewrite this someday” into a sequenced plan with a first step you can start this quarter.