Every large organization has one. The old system everyone complains about, that nobody fully understands, that quietly runs something the business genuinely cannot operate without. Replacing it is necessary and terrifying at the same time, because the cost of getting it wrong isn’t a late feature. It’s a stopped business.
So the instinct is the “big bang” rewrite. Build the shiny new system off to the side, flip the switch one weekend, retire the old one. It sounds clean. It’s also how the most expensive failures happen. The track record on big efforts is sobering: large IT projects run, on average, 45% over budget and deliver 56% less value than predicted (McKinsey), and small projects succeed far more often than large, complex ones (Standish via InfoQ). In our experience, big-bang replacements of core systems run years late, miss the undocumented behaviour the old system was quietly handling, and force an all-or-nothing cutover that nobody can walk back.
There’s a calmer way to do this, and it’s the one that actually works.
Strangle the old system, don’t detonate it.
The proven pattern has a slightly violent name: the strangler. You wrap the old system, route new functionality to new components, and migrate it piece by piece while both keep running side by side. Think of vines slowly growing over an old wall and taking its weight, one section at a time, until one day the wall is gone and nothing fell down. Each step delivers real value and each step is reversible on its own. You’re never one bad cutover away from disaster.
Here’s the shape of it, stage by stage.
timeline title Strangle the old core, one safe stage at a time Map it : Learn what the old system really does, edge cases and all Wrap it : Route new work to new components, old and new running together Win small : Replace a high-pain, low-blast-radius piece first Migrate : Move data and logic across in parallel, with a path back Reach the core : Take on the scariest part last, once you've earned the confidence
Do this before you touch anything.
- Understand what the system actually does. Including the undocumented edge cases it handles. This is the hardest step and the one everyone skips. The behaviour nobody wrote down is exactly what breaks the replacement, usually three weeks after go-live.
- Separate what matters from what’s just old. Not everything legacy is bad. Some of it encodes years of hard-won business logic that works. Modernize the parts holding you back, and preserve the logic that’s quietly correct.
- Protect the data. Migration is where these projects live or die. Plan it early, test it relentlessly, and always keep a path back to where you were.
Sequence by risk and value. Start where the pain is high and the blast radius is small. Win there, build confidence and capability, then work your way toward the core. Never the other way around. Betting the most critical part of the business on your very first move is how you turn a project into a headline.
Done right, modernization is a series of controlled, reversible steps, each one delivering something useful, never wagering the whole business on a single switch. It looks slower on a plan. It’s far faster in real life, because it doesn’t collapse halfway through.
Sitting on a critical system you’re afraid to touch? SDCG plans and delivers incremental modernization. We map what the old system really does, then replace it piece by piece without stopping the business. We’re independent, so we’re solving your problem, not selling you a platform. Book a free 30-minute review.
Sources
- McKinsey, Delivering large-scale IT projects on time, on budget, and on value
- InfoQ, Standish Group CHAOS report summary