Almost every voice a CEO hears on this subject, the vendors, the consultants, the conference speakers, and yes, most of the pieces written by people who sell modern platforms, points the same direction: your systems are holding you back, modernize now, the cost of waiting is enormous. Some of that is true some of the time. But it is worth hearing the other side clearly, precisely because so few of the people talking have any incentive to say it: for a great many companies, at a great many moments, ripping out your systems is the wrong move, and doing it prematurely is one of the more expensive mistakes a leadership team can make.

This is an uncomfortable argument for anyone adjacent to the software industry to make, which is exactly why it is worth making honestly. The default is not neutral. It is sold. And a leadership team that mistakes "everyone says to modernize" for "we should modernize now" is outsourcing one of its most consequential and least reversible decisions to people who profit from the answer.

The failure rate is not a detail

Start with the number that the modernization pitch tends to move past quickly. Research from Boston Consulting Group and McKinsey has consistently found that roughly 70% of digital transformation initiatives fail to meet their objectives. That is not a rounding error on an otherwise safe bet. It is the base rate. When you approve a major systems replacement, you are, on the industry's own numbers, more likely than not to fall short of what you set out to achieve.

The scale of the waste is staggering when you total it. Research highlighted by the academic publisher Taylor & Francis put the global sum wasted on failed digital transformation programs at around $2.3 trillion, and the specialist's conclusion is the part the industry rarely quotes: the costly, wide-ranging overhauls are frequently not necessary, and companies tend to do better by being selective than by being ambitious. That is not an argument against ever modernizing. It is an argument against treating a full rip-and-replace as the obvious, safe, responsible default, when the evidence says it is the high-risk option dressed as the prudent one.

Premature is its own kind of failure

The cautionary cases are instructive because they are not stories of companies that refused to modernize. They are stories of companies that modernized before they were ready. Revlon's ERP replacement, rolled out prematurely and across many markets at once, disrupted its supply chain badly enough to cause tens of millions in losses, unshipped orders it could not fulfill, a measurable hit to its share price, and shareholder litigation. The technology was not the problem. The timing and the readiness were. The company would have been far better served by waiting until it could execute than by moving on a schedule that outran its own preparation.

This is the failure mode the modernization pitch never features, because it complicates the story. The risk is presented as entirely one-sided: wait and you fall behind. But moving too early carries its own severe, sometimes existential cost, and it is a cost you incur actively, by choosing to disrupt a working operation before the replacement and the organization were ready to absorb it. "Not yet" is sometimes the most responsible answer a CEO can give, and it takes more conviction than "yes," because it means resisting the pressure of everyone selling the alternative.

Why "good enough" is often genuinely good enough

There is a quieter reason to be skeptical of the reflex to replace, which is that a system's flaws are not the same as a system's costs. Every legacy system has irritations. The screens are dated, the workflows are clunky, some tasks take more clicks than they should. These are real, and they are also, frequently, not worth the price of a full replacement. The relevant question is not "is this system imperfect," because every system is imperfect, including the shiny one you would replace it with. The question is whether the imperfections are actually costing you enough to justify the risk, disruption, and expense of change.

Often they are not. A system that is unglamorous but stable, that your people know cold, that does what the business needs even if not elegantly, is an asset, not a liability, and the fact that a better one exists somewhere does not automatically make yours a problem worth solving right now. The pressure to replace frequently comes from comparison rather than from cost: you saw a demo, a competitor announced something, the current system looks old next to the new one. None of that is evidence that your current system is actually holding the business back. Aesthetic dissatisfaction is not a business case.

The honest line: this is not an argument against ever changing

It would be just as lazy to turn this into "never modernize" as it is to assume "always modernize," and the restraint case collapses into complacency the moment it stops being disciplined. Systems do genuinely outlive their usefulness. There are real moments when the current platform is actively bleeding money, capping growth, or unable to support what the business now needs, and in those moments waiting is the expensive mistake, not moving. The point is not to default to inertia. It is to default to neither, and to actually run the test instead of letting the industry's bias or your own discomfort decide.

And there is a real tension worth naming plainly, because a careful reader will feel it. The switching cost of a core system rises every year you stay, so waiting is not free, and a decision deferred too long becomes a decision made worse. Restraint and urgency are not opposites here. They are two errors on either side of a single judgment, and the discipline is to make that judgment on evidence rather than falling into whichever error your situation biases you toward.

The test most companies never run

Here is the discipline the modernization pitch skips. Before you approve ripping out a system, you should be able to answer, with actual numbers rather than adjectives, one question: what is our current system costing us, specifically, that a new one would not? Not "it's old." Not "it's frustrating." What is the quantified cost, the hours lost, the growth blocked, the decisions delayed, the money left on the table, and how does that compare against the full cost of change, including the failure rate, the disruption, and the risk that the replacement underdelivers like most of them do?

If you cannot answer that question with real figures, you are not ready to make the decision in either direction, and the honest move is to go find the numbers, not to approve the project on vibes. If you can answer it and the current cost genuinely exceeds the cost of change, then modernize with conviction, you have earned the decision. But most companies never run this test. They feel the pressure, they see the demo, they assume newer is better, and they commit to one of the riskiest and least reversible projects a company undertakes without ever quantifying the problem they are trying to solve. The case against ripping out your systems is not really a case against modernizing. It is a case against modernizing for any reason other than a proven one.

FAQs

Q1. Isn't this just an argument for complacency?
No. It is an argument against changing without a proven reason, which is different from arguing against change. Complacency is refusing to run the test at all. The discipline proposed here is to quantify what your current system actually costs versus the cost of replacing it, and to act on the answer in whichever direction it points, including replacing when the numbers justify it.

Q2. Everyone says we need to modernize. Why be skeptical?
Because almost everyone saying it has a financial interest in the answer, and the default toward modernization is sold rather than neutral. That does not make them wrong, but it means the advice should be weighed against your own quantified evidence rather than accepted on volume. The industry's own data shows most transformations fail to meet their goals, which is not what you would expect if replacement were the safe default it is presented as.

Q3. How do I know if our systems are genuinely holding us back or just dated?
Distinguish flaws from costs. Every system is imperfect, so imperfection alone proves nothing. Ask what specific, quantifiable business outcomes the current system is preventing, growth you cannot support, hours demonstrably lost, decisions measurably delayed. If you can put real numbers on those, it may be time. If the complaint is that it looks old or a competitor has something newer, that is comparison, not cost.

Q4. Doesn't waiting just let switching costs and problems compound?
It can, and that is the real tension. Switching cost does rise over time, so waiting is not free, and a change deferred too long becomes harder and more expensive. That is precisely why the decision should be made on evidence rather than on either inertia or urgency. Restraint means not moving without a proven reason, not refusing to move when the reason is proven.

Q5. What is the risk of moving too early?
Significant, and often underappreciated because the pitch emphasizes only the risk of moving too late. Premature replacement can disrupt a working operation before the new system and the organization are ready, with consequences ranging from cost overruns to serious operational failure. Well-documented cases show companies causing themselves major damage not by refusing to modernize but by doing it before they were prepared.

Q6. What test should we run before approving a systems replacement?
Quantify what your current system costs you specifically, in lost hours, blocked growth, delayed decisions, and unrealized value, and compare that against the full cost of change, including the substantial failure rate and the disruption of transition. If the current cost genuinely exceeds the cost of change, proceed. If you cannot produce those numbers, you are not ready to decide either way, and the honest next step is to find them.

Q7. Isn't a stable old system a liability we're just used to?
Not necessarily. Stability, deep familiarity across your team, and reliable coverage of what the business actually needs are genuine assets, even in an unglamorous system. Familiarity is not the same as being trapped. The existence of a better system elsewhere does not by itself make yours a liability, any more than the existence of a newer car makes a working one worthless.

Q8. When is modernizing clearly the right call?
When you can show, with real numbers, that the current system is actively costing more than the transition would, capping growth the business is otherwise ready for, or unable to support genuine new requirements. In those cases the evidence favors moving, and waiting becomes the expensive error. The point is never to avoid change, only to require that it be justified by proof rather than by pressure or aesthetics.