How to replace a system without stopping it.
Big-bang rewrites put all the risk on one weekend. Here’s how I’d replace a legacy system piece by piece, while the business keeps running on it.
By Nizar Oukhchi, Solution architect
Published · 7 min read
Imagine you're asked to replace the system your company has run on for fifteen years. The plan on the slide is simple: rebuild it out of sight, then switch over on a single weekend.
It's also the riskiest plan you could pick.
It's the most common one, though, precisely because it looks so simple. So what do you do instead? I'll walk you through the approach we use: replace the system piece by piece, while the business keeps running on it.
Why big-bang rewrites go wrong
A system that has run a business for ten or fifteen years isn't just old code.
It holds years of rules that nobody wrote down. The discount that only applies to one region. The field finance reads on the last day of the month. The batch job a partner quietly depends on.
A rewrite has to rediscover every one of them. Usually after launch.
Then there's the fact that the business doesn't stand still while you rebuild. Every month you spend on the new system is a month of new requirements landing on the old one. You're aiming at a target that keeps moving.
And finally, a single switch-over date puts all the risk in one place. If anything is wrong, everything is wrong at once. Going back is hard.
How bad is that, really?
Let's do the arithmetic. Say each of twelve capabilities has a 95% chance of switching over cleanly. That sounds great! But the odds that all twelve do so on the same night are barely better than a coin toss.
Here's what that looks like:
One big switch-over multiplies small risks into a big one.
Replace it piece by piece
The alternative is often called the strangler fig pattern. It's named after a plant that grows around a tree until it can stand on its own. (Forgive the slightly grim botany.)
The idea goes like this. You put a thin layer in front of the old system. Then you move one capability at a time to new software behind that layer.
Users keep working throughout.
Each step is small enough to test, measure and undo.
It also changes when the business sees results. The first slices are in use within months, instead of everything arriving at the end. And each one delivers value, plus lessons for the next.
You can see the difference here:
| Months since kick-off | Big-bang rewrite | Piece by piece |
|---|---|---|
| M0 | 0% | 0% |
| M3 | 8% | |
| M6 | 25% | |
| M9 | 42% | |
| M12 | 58% | |
| M15 | 75% | |
| M17 | 0% | |
| M18 | 100% | 92% |
| M20 | 100% | |
| M24 | 100% | 100% |
So how do you actually do it? In practice, it comes down to six steps.
- PrepareMap what the system really doesCapabilities, integrations, data flows, users.
- PreparePick the first sliceValuable, small, few dependencies.
- PreparePut a seam in front of the old systemSwitching becomes a routing change.
- MoveMove data in stagesOne owner per record, regular reconciliation.
- MoveRun both, compare, then switchThe way back stays open.
- RetireSwitch the slice off in the old systemDeliberately, on a schedule.
Step 1: Map what the system really does
Start with an inventory. Which capabilities, integrations and data flows exist, and who uses what?
Documentation helps. But it describes what someone expected the system to do.
To learn what actually happens, read the logs, query the database, and talk to the people who use the system every day. People (me included) skip that last one far too often.
The goal is a map you can cut into slices.
Step 2: Pick the first slice carefully
The first slice should:
- Matter to the business.
- Be small enough to ship in weeks.
- Have few dependencies on the rest of the system.
A self-contained workflow, a reporting module or a single customer-facing journey are good candidates.
Why be so picky?
Because the first slice also proves the method. Choose a first slice where success is easy to see.
Step 3: Put a seam in front of the old system
You need a routing layer. An API gateway, a proxy or an integration service will do. It decides which requests go to the old system and which go to the new one.
Once that seam exists, something nice happens.
Moving a capability becomes a routing change, not a migration weekend. And moving it back is just as easy.
Step 4: Move data in stages
This is where modernizations get hard.
For each kind of record, decide which system owns it at any given moment. Never let two systems own the same thing.
Keep the two in sync with change data capture or scheduled synchronization. Then run reconciliation reports that show both sides agree.
Only then do you trust the new one. Not before.
Step 5: Run both, compare, then switch
Before a slice goes live, send it real traffic in parallel. Compare its results with what the old system produces.
Will they match? Often, they won't!
That's the point. The differences reveal the unwritten rules you missed back in step 1.
Switch over when the numbers match, one capability at a time. And keep the way back open until the new path has proven itself.
Step 6: Retire what is left
Are we done? Not quite.
Each slice that moves should be switched off in the old system, deliberately and on a schedule.
If you skip this, you end up running two systems forever. Two systems cost more than either one.
When a rewrite is the right call
I don't want to oversell this. Piece-by-piece replacement isn't always necessary.
If the system is small, has few integrations and can be frozen for the length of the rebuild, a direct rewrite can be faster. Same if the old platform can no longer run safely at all.
So the question isn't "old or new?"
It's this: how much risk can the business carry on one date?
Where to start
Most modernizations begin with a short technology audit. What exists, what it costs to run, what has to change, and in what order.
If you're weighing a modernization, here's how we approach legacy modernization. And if you'd like a second pair of eyes, tell us about your system.