Almost every company has one: the system that runs a critical part of the business, that only one or two people fully understand, and that everyone is afraid to touch. New features take months, hosting costs keep rising, and a full rewrite feels like betting the company.
The good news is that you don't have to choose between living with it forever and replacing it in one risky jump. You can replace it one slice at a time.
Why big-bang rewrites go wrong
- The old system keeps changing while the new one is being built, so the target keeps moving.
- Years of edge cases live in the old code and nobody wrote them down.
- Nothing reaches users until the very end, so problems are found late and all at once.
- There's no easy way back if launch day goes badly.
The slice-by-slice approach
- Map what the system actually does. Talk to the people who use it every day, list every job it performs, and find which ones hurt most.
- Put a clean API in front of it. New features and integrations talk to the API, not directly to the old system, so the old system stops being a dependency for everything new.
- Pick the first slice. Choose something valuable but low-risk, such as reporting, a customer-facing screen, or one workflow.
- Build the new slice on modern infrastructure and run it alongside the old one. Compare their outputs on real data until they match.
- Switch traffic over gradually, a few users or one region first, with a quick way to switch back.
- Retire that part of the old system only once the new slice has been proven in production. Then pick the next slice.
Engineers call this the strangler fig pattern: the new system grows around the old one until the old one can be removed.
Protect the data first
Data is where modernization projects get hurt. Before moving anything, profile it: find duplicates, missing values and the fields that mean different things in different places. Plan migrations to be repeatable, test them on copies of production data, and reconcile totals after every run.
What to measure
- Time to ship a change, before and after each slice.
- Incidents and support tickets linked to the old system.
- Hosting and licence cost per month.
- How many people can safely work on the system.
What we'd tell a friend: If you can only do one thing this quarter, write down everything the old system does and who depends on it. That document alone makes every later step cheaper and safer.