The system everyone depends on and nobody wants to touch
Almost every established organization has one. It might be an order management system written fifteen years ago, a policy administration platform, or a scheduling tool that started life as a spreadsheet and kept growing. It works, mostly. It also holds the business back: changes take months, the people who understand it are retiring, it cannot talk to anything new, and every security review ends with a list of concerns nobody can afford to fix.
The natural reaction is to replace it. Write the new system from scratch, switch over on a chosen weekend, and finally move on. That plan has an appealing simplicity and a poor track record.
Why big-bang rewrites fail
Rewrites fail for reasons that are predictable, and that is what makes them avoidable.
- The old system knows things nobody wrote down. Years of fixes, edge cases and regulatory adjustments live only in the code. A rewrite rediscovers them one production incident at a time.
- The business does not pause. While the new system is being built, the old one keeps changing, and the target keeps moving.
- Value arrives at the very end. For a year or more, the organization pays for two systems and benefits from neither. Budgets and patience run out before the switch.
- Everything is at risk at once. A single cutover concentrates all the risk into one weekend, with no easy way back.
None of this means legacy systems cannot be replaced. It means they should be replaced the way you would renovate a building that people still live in: room by room, with the lights on.
Modernize in slices
The approach we use is often called the strangler fig pattern, after the plant that grows around a tree until it can stand on its own. A new system grows around the old one, taking over one capability at a time, until the old system has nothing left to do and can be switched off.
1. Understand what the system really does
Before changing anything, map the system as it actually behaves, not as the documentation claims. Which business capabilities does it support? Who uses each one, and how often? Which parts change most, cause most incidents or block the most important plans? This is also where modern AI tools have become genuinely useful: they help engineers read and summarize unfamiliar code far faster, and they help surface the business rules buried inside it. The output is a map that tells you where to start.
2. Put a front door in place
Introduce a layer between the old system and everything that talks to it, typically a set of APIs or a routing layer. At first it simply passes requests through. Its value is that, from now on, any capability can be redirected to a new implementation without the people and systems calling it noticing.
3. Pin down current behavior with tests
Write tests that capture what the system does today, including the odd behaviors, before you replace any part of it. These are sometimes called characterization tests. They are not a judgment on whether the behavior is right. They are a safety net that tells you when the new implementation behaves differently, so that every difference is a decision rather than a surprise.
4. Move one capability at a time
Pick a slice that is valuable and reasonably self-contained: customer notifications, pricing, a reporting module, a single product line. Build it properly in the new platform, run it alongside the old one and compare the results, then switch traffic over gradually. Each slice delivers value on its own, and each one makes the next easier.
5. Plan the data, not just the code
Data is usually the hardest part. Decide early which system is the source of truth for each type of record at each stage, and how the two will stay consistent while both are running. Migrating data in phases, with reconciliation checks, is slower than a single bulk move and far safer.
6. Switch off what you have replaced
Modernization only pays off when old components are actually retired. Make decommissioning an explicit milestone for every slice, with its own owner and date. Otherwise you end up running two systems indefinitely, which is the most expensive outcome of all.
Rewrite, refactor or replace?
Not every part of a legacy estate deserves the same treatment.
| Situation | Usually the right move |
|---|---|
| Commodity capability, such as payroll or email | Replace with a proven product |
| Core to how you compete, and changing often | Rebuild it as a modern service |
| Stable, rarely changed, works well | Leave it, and protect it behind the new front door |
| Sound design but outdated technology | Refactor and move it to a modern platform |
The aim is not a perfectly modern estate. It is an estate where the parts that matter most can change at the speed the business needs.
How to tell it is working
Track progress in terms the business recognizes:
- The share of transactions or users served by the new platform.
- Lead time for a typical change, before and after each slice.
- Incidents and recovery time in modernized areas compared with the rest.
- Running costs retired as old components are switched off.
If these numbers move every quarter, the program is working, and it can be paused, reprioritized or accelerated at any point without losing what has already been delivered. That flexibility is the real advantage over a rewrite.
The best time to start
Legacy systems rarely fail all at once. They become slower to change, harder to secure and more expensive to run, until one day a strategic plan quietly dies because "the system can't do that". Starting with a single, well-chosen slice costs far less than waiting for that day.
Our Software Modernization team works exactly this way: a clear map, a first slice delivered in weeks, and steady progress that never asks the business to stop.
