First, respect what the old system holds
A system that has run a business for many years contains more than old code. It contains every rule, exception and correction that was added because something went wrong once. Much of that is written nowhere else. The people who asked for it may have left.
This is why replacing legacy software is harder than it looks. The visible features are easy to list. The invisible behavior, such as how a rounding rule works or what happens to an order placed on the last day of the month, is found only when the new system gets it wrong. Any plan has to deal with that knowledge, not only with the technology.
There are more than two routes
| Route | What it means | Fits when |
|---|---|---|
| Keep and contain | Leave the system alone and put a modern interface or API in front of it | It is stable, rarely changes and mainly needs to connect to newer tools |
| Rehost | Move it to current infrastructure with as few changes as possible | The hardware or hosting is the risk, not the software |
| Refactor | Improve the code inside, in steps, without changing what it does | The logic is right and the code is hard to change safely |
| Replace in pieces | Build new parts beside the old system and move functions across one at a time | The system is large, critical and must keep running throughout |
| Rewrite | Build a complete new system, then switch | The system is small, or the old design blocks everything you need |
| Buy a product | Retire the system in favor of an existing product | What it does has become standard since it was built |
Modernize covers the first three routes and often the fourth. Replace covers the last two. Replacing in pieces is both, which is why it is so often the answer.
When each one fits
Lean toward modernizing when
- The system still matches how the business works
- The pain is speed, stability, security or the cost of changes
- It is too critical to switch off, even for a day
- Its rules are complex and poorly documented
- Budget must be spent in stages, with value at each stage
Lean toward replacing when
- The business process has changed and the system fights it
- The technology can no longer be supported or secured at all
- A product now does the same job well
- The system is small enough to rebuild with confidence
- The data model itself is wrong for what you need next
Why the full rewrite is the riskiest route
- Nothing is delivered until the end. The business pays for a long time before it sees any benefit, and the old system must be maintained in parallel
- The target moves. While the new system is built, the business keeps changing the old one. The rewrite chases it
- Hidden rules surface late. Behavior nobody listed appears in testing, or after the switch
- The switch is a single event. All the risk is concentrated in one weekend
- Estimates are weakest here. A rewrite is sized from the visible features, which are the smaller part
None of this means a rewrite is always wrong. For a small system, or one whose design truly blocks you, it can be the cleanest path. It means the choice should be made knowingly, with the alternatives priced.
How replacing piece by piece works
- 01
Put a layer in front
All requests go through a new entry point that can send each one to the old system or to a new part.
- 02
Choose a first slice
A function that is valuable, well understood and loosely connected to the rest.
- 03
Build it new, and run both
For a time the new part and the old one handle the same cases, and the results are compared.
- 04
Switch that slice
Traffic for that function moves to the new part. The old code for it is retired.
- 05
Repeat
Each slice delivers value and teaches something about the rules hidden in the next one.
The old system shrinks until what remains can be switched off or kept contained. At every point the business has a working system, and the project can pause without leaving anything half done.
When the system is a SaaS product with paying customers
A SaaS product raises the stakes of this decision. An internal system can be switched over a weekend with staff warned in advance. A product with paying customers cannot pause, and each customer notices the day something they relied on behaves differently.
- Customers keep asking for features. A rebuild that freezes the product while it catches up hands the market to competitors. Incremental work lets releases continue.
- Feature parity is larger than it looks. Years of small behaviors, settings and edge cases exist only in the old code and in customers' habits.
- Data moves customer by customer. Each account has its own history and configuration, so migration is many small moves, each of which must be reversible.
- Two products cost double. While old and new run side by side, both need hosting, support and fixes.
For these reasons the incremental route is the usual one for SaaS. New parts are built beside the old product, behind the same sign-in and billing, and traffic is moved to them one area at a time. Customers are migrated in groups, starting with those who asked for what the new parts offer.
A full rebuild remains the right call in a narrower set of cases: the data model itself blocks what customers now need, the old stack can no longer be hosted or staffed safely, or the product is small enough that parity is quick to reach.
A worked example
A wholesaler's order system
The company is invented. Its order system was built long ago on a platform that few engineers now know.
- The painNew features take months, the one developer who understands it is close to retirement, and customers want to order online.
- The tempting planRewrite everything on a modern stack and switch over next year.
- What an assessment foundPricing rules with hundreds of customer-specific exceptions, documented only in the code. A full rewrite would have to rediscover each one.
- The plan chosenAn API in front of the old system first, so that a new customer ordering site could be built at once. Then pricing moved into a new service and was run in parallel until its results matched. Stock and invoicing follow, one at a time.
Customers ordered online in the first stage, long before the old system was gone. The pricing rules were verified against real orders instead of being trusted to a specification.
What to assess before you choose
Assessment checklist
0 of 8 checkedAn independent technical code audit answers most of these with evidence, and is a sensible first expense before a larger one.
What to do next
Run the assessment, then price at least two routes side by side, including the cost of keeping the old system alive during each. Our legacy software modernization page explains how we approach the work, and custom vs off-the-shelf covers the case where a product may now fit.
If you would like a view on your system, tell us what it does and where it hurts. We will say which route we would look at first.
Common questions
How do we know whether our software counts as legacy?
Age alone does not decide it. A system is legacy when changing it has become slow or risky, when the platform is no longer supported, or when few people can maintain it. A ten-year-old system that is tested, documented and on a supported platform is simply mature.
Is modernizing cheaper than replacing?
Often, because work is spread out and each stage returns value. It is not always cheaper in total. If the system no longer fits the business, money spent improving it is spent in the wrong place. The fair comparison prices each route in full, including running the old system during the work.
Can we modernize without stopping the business?
Yes, and that is the main argument for working in pieces. A layer in front of the old system lets new parts take over one function at a time, with both running side by side until the new part is proven. There is no single switch-over day.
What happens to our data?
It moves in stages or at once, depending on the route. In either case it should be profiled first, cleaned, migrated in trial runs and reconciled against the old system. Historical data that the new system does not need can be archived in a readable form instead of migrated.
