The system everyone wants to replace is usually also the system the organization can't afford to have down for a week. That contradiction is why so many modernization projects either never start or fail the moment someone proposes a full cutover.
Why the big-bang rewrite fails
Replacing a legacy system in one large release feels efficient on paper: build the new thing, test it, switch over, done. In practice, it concentrates every risk into a single moment. Requirements drift over the months or years it takes to build the replacement. Edge cases the old system quietly handled for a decade get missed because nobody remembered they existed. And when the cutover date arrives, the organization is betting the business on a system that has never run against real production load.
We've seen this pattern often enough to treat it as a rule rather than an exception: the bigger the cutover, the higher the odds it gets delayed, descoped, or rolled back.
Modernizing in place
The alternative is incremental: replace the legacy system piece by piece, behind the same interfaces it already exposes, while both systems run in parallel. Traffic moves over gradually, one capability at a time, with the ability to roll any single piece back without touching the rest.
- Start at the seams. Identify the natural boundaries in the existing system (a reporting module, an integration, a specific workflow) and modernize one at a time rather than the whole system at once.
- Route around, don't rip out. New functionality sits in front of or alongside the legacy system, intercepting traffic for the piece being replaced while everything else keeps running unchanged.
- Keep both systems honest. Run the old and new paths side by side long enough to compare real output, not just test-case output, before fully cutting over.
- Decommission last, not first. The legacy system doesn't get switched off until the last piece has been running cleanly in production for a defined period, not on a fixed calendar date.
What this requires from an engineering partner
Incremental modernization takes longer to plan than a rewrite, and it requires genuinely understanding what the existing system does, including the undocumented behaviour nobody wrote down because it was "obvious" at the time. That's discovery work, not just migration work, and it's where a lot of modernization projects underinvest.
It also requires architecture decisions to be documented as they're made, so the reasoning behind each incremental step survives past the engineers who made it. That discipline is what keeps a multi-phase modernization from turning into its own kind of legacy mess.