How to modernize a legacy system without stopping the business.
Why big-bang rewrites go wrong, and a step-by-step way to replace a legacy system while it keeps running: map, slice, route, migrate, compare, retire.
Published · 7 min read
The riskiest way to replace a legacy system is to rebuild it out of sight and switch over on a single weekend. It is also the most common plan, because it looks simple on a slide. This article describes the alternative 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 is more than old code. It holds years of rules that nobody wrote down: the discount that only applies to one region, the field that finance reads on the last day of the month, the batch job a partner depends on. A rewrite has to rediscover all of them, usually after launch.
The business also keeps moving while you rebuild. Every month spent on the new system is a month of new requirements landing on the old one, and the target keeps shifting.
Finally, a single switch-over date puts all the risk in one place. If anything is wrong, everything is wrong at once, and going back is hard.
The arithmetic is stark. If each of twelve capabilities has a 95% chance of switching over cleanly, the odds that all twelve do so on the same night are barely better than a coin toss.
Replace it piece by piece
The alternative is often called the strangler fig pattern, after the plant that grows around a tree until it can stand on its own. You put a thin layer in front of the old system, then 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 and lessons for the next.
| 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% |
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.
1. Map what the system really does
Start with an inventory of capabilities, integrations and data flows, and of who uses what. Documentation helps, but logs, database queries and conversations with the people who use the system every day tell you what actually happens. The goal is a map you can cut into slices.
2. Pick the first slice carefully
The first slice should matter to the business, be small enough to ship in weeks, and 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. The first slice also proves the method, so choose one where success is easy to see.
3. Put a seam in front of the old system
A routing layer, such as an API gateway, a proxy or an integration service, decides which requests go to the old system and which go to the new one. Once that seam exists, moving a capability is a routing change rather than a migration weekend, and moving it back is just as easy.
4. Move data in stages
Data is where modernizations get hard. Decide, for each kind of record, which system owns it at any given moment, and never let two systems own the same thing. Keep the systems in sync with change data capture or scheduled synchronization, and run reconciliation reports that show the two sides agree before you trust the new one.
5. Run both, compare, then switch
Before a slice goes live, send it real traffic in parallel and compare the results with what the old system produces. Differences reveal the unwritten rules you missed. Switch over when the numbers match, one capability at a time, and keep the way back open until the new path has proven itself.
6. Retire what is left
Each slice that moves should be switched off in the old system, deliberately and on a schedule. Otherwise you end up running two systems forever, which is more expensive than either one.
When a rewrite is the right call
Piece-by-piece replacement is not 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. The same goes when the old platform can no longer run safely at all. The question to ask is not "old or new?" but "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 are weighing one, our legacy modernization service describes how we approach it, and you can tell us about your system.