Modernize Without Stopping the Business
Summary: Every aging core system eventually reaches the point where it slows the roadmap more than it supports it. The instinct is to replace it all at once. That is usually the riskiest path: the old system keeps changing while the new one is built, and the value arrives only at the end, if it arrives. Incremental modernization replaces the system piece by piece while the business keeps running. This article explains how it works, the signs you need it, and the questions to ask before approving a plan.
Signs the core system is holding you back
- Simple changes take weeks because no one is sure what else they will break.
- Only one or two people understand how critical parts work.
- New products or integrations get turned down because “the system can’t do that.”
- Reporting depends on exports, spreadsheets, and manual reconciliation.
- Hosting, licensing, or support costs keep rising for a system that does less than you need.
One of these is normal. Three or more usually means the system has become a constraint on the business, not just a technical nuisance.
Why the big rewrite is so risky
A full rewrite asks the business to fund a second system for months or years before it delivers anything. During that time:
- The target moves. The old system keeps getting fixes and features, and the new one has to chase them.
- Hidden behavior gets lost. Years of rules and workarounds live in the old code, often undocumented. A rewrite discovers them late, usually in production.
- Value arrives all at once, at the end. If budget or patience runs out at 80%, the business has spent the money and still runs on the old system.
- Cutover is a single, high-stakes day. Everything changes at once, so everything can fail at once.
How incremental modernization works
The approach is often called the strangler fig pattern, after a vine that grows around a tree until it replaces it [1]. In business terms:
- Map what the system actually does. Interview the people who use it and trace the data. The goal is an inventory of functions, including the undocumented ones.
- Pick the first slice by business value and risk. Choose a piece that is painful today and reasonably separable, such as invoicing, scheduling, or a customer portal.
- Build the new piece beside the old one. Both run at once. The new piece takes over one function while the old system handles everything else.
- Shift work over gradually. Move one team, region, or transaction type at a time, with a way to switch back if something goes wrong.
- Retire what is no longer used. Each retired piece lowers cost and risk. Then repeat with the next slice.
The business sees results after the first slice, not at the end. Each step is small enough to reverse. And the plan can change as you learn, without writing off what has already been built.
What keeps it safe
- Parallel runs. New and old produce the same output for a period, and differences get investigated before switching.
- Rehearsed data migration. Move the data several times in a test environment before the real move.
- Monitoring from day one. Know when something breaks before customers do.
- A clear rollback path for every step.
Questions to ask before you approve a plan
- What will the business be able to do after the first slice, and when?
- How will we find the rules the old system enforces that no one wrote down?
- What happens if we stop after phase two? Are we better off, or stuck between systems?
- How do we switch back if a step goes wrong?
- Who on our team will own and understand the new system?
A plan that can’t answer these is a rewrite with milestones attached. A plan that can is a series of small, reversible decisions, which is how a business keeps running while its foundation is replaced.