Every few years the legacy system comes back onto the agenda. The vendor announces an end-of-support date, or the third integration request in a row gets quoted at nine months, or the last person who understands the batch schedule announces their retirement. Someone says the word "replace," and a program starts forming around it.
What's usually missing at that point is the decision itself. Not the plan — the decision. Because the choice isn't binary, the pain isn't uniform across the system, and the option that sounds boldest has by far the widest range of outcomes.
The question is usually asked backwards
Most conversations start from the system: what do we do about the twenty-year-old order platform? That framing guarantees a system-sized answer, which guarantees a system-sized program.
The better starting question is what the business needs this capability to do in the next three years that it can't do now. Sometimes the answer is substantial — enter a new market, support a channel the architecture can't accommodate, meet a regulatory deadline. Sometimes, honestly, the answer is "nothing much; it's just old and we don't like it." Those two answers lead to completely different places, and only one of them justifies a program.
Old is not a business problem. Old, brittle, and blocking a specific commitment is.
Four options, not two
The debate usually collapses into buy-versus-build. There are four real options, and the two that get skipped are frequently the right ones.
- Leave it alone — deliberately. Not neglect: a decision, with a containment plan. Freeze functional change, wrap it in a documented API so new work happens outside it, fund its run and security costs honestly, and write down the trigger conditions that would reopen the decision. For a stable system serving a stable process, this is often the highest-return option, and it's under-used because it's the only one nobody gets credit for choosing.
- Buy the capability. Right when the process it supports isn't a source of competitive advantage — payroll, expenses, standard ledger, most CRM. The trap is that the license is the small number. The real cost is data migration, integration, and the process change required to fit the package, which is where these programs actually run over.
- Modernize incrementally. Strangle the system capability by capability, routing traffic to new components while the old one keeps running. Slower on paper, dramatically lower risk, and it preserves business rules you can't fully enumerate. We covered the mechanics in Application Modernization Without Destabilizing the Business.
- Rebuild. Justified when the capability is genuinely differentiating, the existing rules are recoverable, and the organization can fund a parallel run plus dual maintenance for as long as it takes. All three conditions, not two. Rebuilds fail on the third far more often than the first.
The four questions that decide it
You can get most of the way to an answer with these, asked honestly.
- Is this capability differentiating? Would a customer notice if it worked the way everyone else's does? If not, you're building a worse version of something you could buy. If yes, packages will require customization that erases their advantage.
- Where is the pain, precisely? Run cost, change velocity, compliance risk, or the ability to hire people who'll work on it. Each points somewhere different: cost pressure often argues for containment or rehosting, change velocity for incremental modernization, compliance exposure for a dated replacement plan, and a talent cliff for reducing the surface area rather than rewriting all of it.
- Can you recover the business rules? Twenty years of undocumented decisions live in that code, and the ones that matter are usually the ones no living person remembers. If the rules can only be recovered by reading the source, incremental strangling preserves them by construction while a rebuild has to rediscover every one — and rule discovery, not engineering, is what makes rewrites overrun.
- Can you afford to be wrong? Every option except "leave it alone" involves running two things at once for a while. Price the parallel run, the dual maintenance, the data reconciliation, and the decommissioning — then ask whether the business will still fund it in month fourteen when the new system isn't finished and the old one still needs patching.
Nobody gets criticized for proposing to replace the legacy system. That's precisely the problem: it's the option whose failure mode arrives furthest away from the person choosing it.
Decide per capability, not per system
Here's the move that changes most of these conversations. A legacy monolith is not one thing — it's five or six capabilities that happen to share a database, and they rarely deserve the same answer.
Split the system into the capabilities the business would name: pricing, order capture, fulfilment, customer master, reporting. Score each one on differentiation, on how much change the business actually wants there, and on how recoverable its rules are. What emerges is almost never a single verdict. It's a portfolio: buy this one, strangle that one, freeze the third, and decommission the fourth once you notice that two teams have quietly stopped using it.
This also solves the funding problem. A portfolio can be sequenced so each phase delivers something on its own, which means the program survives a budget review. A single system replacement has one delivery date and no value before it — which is why it's the shape most likely to be cancelled at 70% complete.
A short worked example
A manufacturer's order management platform, roughly twenty years old, was the subject of a replacement proposal costing eight figures and running three years. We spent four weeks decomposing it instead.
Pricing turned out to be genuinely differentiating — contract-specific logic that the sales organization competed on, embedded in code, partly undocumented. That got strangled: new pricing service, rules extracted incrementally with the old engine running as a check against it. Customer master was commodity, already duplicated in the CRM, and was consolidated onto the platform they already owned. Fulfilment was stable, worked well, and had no pending business demand — it was contained behind an API and explicitly frozen. Reporting was replaced in a quarter by a data extract feeding the BI tool the business had already started using unofficially.
Nothing about that portfolio is heroic, and one of the four decisions was "don't touch it." The first useful thing shipped in five months rather than three years, and the total spend came to a fraction of the replacement proposal — mostly because two thirds of the system turned out not to need replacing at all.
The honest takeaway
Before you approve a replacement, insist on the decomposition. If the proposal treats the legacy system as a single object with a single fate, it hasn't been analyzed yet — it's been reacted to.
And leave room for the unfashionable answer. A well-contained legacy system that reliably does its job, wrapped so it doesn't block anything new, is not technical debt. It's a paid-off asset, and the discipline to say so is worth more than another program.