Every legacy modernisation project starts with the same tempting idea: freeze feature work, rewrite the system properly this time, and cut over once it's done. Almost every one of those projects either blows past its timeline, gets cancelled before it ships, or delivers a rewrite that's already outdated by the time it launches. The alternative — incremental modernisation — is less satisfying to plan but dramatically more likely to actually ship.
Why the big-bang rewrite fails
A legacy system encodes years of edge cases, business rules and quiet fixes that nobody wrote down. A rewrite has to rediscover all of that from scratch, usually without the original context, while the business keeps changing underneath it. By the time the new system is feature-complete against the old one's requirements from eighteen months ago, the old system has moved on — and so has the business.
The strangler fig pattern
Instead of replacing the whole system at once, route traffic for one capability at a time to a new implementation, while the legacy system continues to handle everything else. Over time, the new system grows around the old one until nothing depends on the legacy code, and it can be safely retired — the same way a strangler fig grows around a host tree. Each step is small enough to test, ship and roll back independently.
Sequence by risk and value, not by what's easiest
The temptation is to modernise the easiest module first to build momentum. It's usually better to sequence by where the legacy system is causing the most pain — the module that breaks most often, or blocks the most roadmap items — even if it's harder. That's where modernisation actually earns its budget, and where stakeholders see the value early enough to keep supporting the project.
Zero-downtime cutovers are a practice, not a hope
Each migration step should ship behind a mechanism that lets you route traffic gradually and roll back instantly if something's wrong — feature flags, canary releases, or a proxy layer that can switch a percentage of traffic between old and new implementations. Pair that with thorough parity testing between old and new before a full cutover, and downtime becomes something you plan away rather than something you hope doesn't happen.
The business keeps shipping while you modernise
The biggest practical advantage of incremental modernisation is that it doesn't require a feature freeze. Because only one slice of the system changes at a time, the rest of the team keeps shipping product work in parallel — which is also what keeps the project funded long enough to finish.
Technical debt didn't accumulate in a big bang, and it rarely needs to be paid off in one either. The teams that successfully retire a legacy system are the ones that treated modernisation as an ongoing engineering discipline, not a one-time heroic project.