Would You Set $5 Million on Fire and Call it Strategy?

The Burning Platform That Wasn't on Fire

Imagine you own a car that refuses to die. Not in a tragic, smoke-billowing-on-the-side-of-the-road kind of way, but in that stubborn, almost disrespectful way where it just keeps working long past when anyone thinks it should. I mean, this car’s paint has faded into a color that no longer exists in any manufacturer's catalog. The dashboard occasionally lights up like a Christmas tree for no clear reason. Every time you turn that key in the ignition, you think it could be the time it dies on you for good. Without fail, it keeps getting you to your destination.

You know this car better than anyone else ever could. You know that if it is cold outside, you give it an extra second before turning the key. You know the exact pressure point on the driver-side door that makes it close properly. You know which warning lights actually matter and which ones have been lying to you for the last three years. It’s not a 5-star experience by any means, but it does the job.

Then one day, you pull into a dealership. Within minutes, someone is explaining why your car is a liability. The safety features are outdated. The fuel efficiency is suboptimal. The technology is obsolete. There are newer models with autonomous driving capabilities, predictive maintenance alerts, and dashboards that look like they belong in a spaceship. There is also a limited-time financing offer that makes the whole thing feel oddly urgent, like keeping your current car might actually be irresponsible.

I think this moment is comparable to the exact moment most organizations find themselves in when the conversation about replacing a legacy system begins. All of a sudden, the conversation shifts from performance to perception, from outcomes to optics, and from necessity to momentum. What’s that saying... comparison is the thief of joy? Or in this case, functionality.

Start Here: Why Isn't It Working?

Whatever you do, don’t ask what your current system can’t do. That’s a bad place to start. Vendors thrive when they get you thinking all of the “what ifs”. A better approach, that is more likely to save you from an unnecessary upgrade, is to ask what your current system supports.

At the end of the day, every modern platform will appear superior because it is designed to showcase breadth, not fit. And the slide deck and the test environment are extremely crisp. In an instance like this, keep in mind that it’s like comparing your current car to a prototype concept vehicle and feeling disappointed that yours can’t park itself or change colors like a mood ring. So... ask a much better question: Why isn’t our current system working? Don’t be shy about it either. If you hate your system, explain why. Just keep in mind that if the conversation gravitates toward how the system is being used, managed, and supported, it introduces the uncomfortable possibility that the constraint is not technological at all.

A quick example for you, in one assessment, leadership was fully convinced they had selected the wrong ERP. Complaints about how the system was slow, requests took too long, and the business felt unsupported were frequent. Maybe they needed a replacement? It sounds cut and dry. Right? Wrong. When we examined the environment more closely, the issue had nothing to do with the software. IT requests were being submitted through scattered emails, tracked nowhere, and executed based on memory. There was no intake structure, no prioritization framework, and no delivery discipline. Is it the system's fault that it was being used poorly?

Replacing the legacy system in this case would have been a terrible mistake. Each category of organizational issue requires a different type of solution. A people problem can’t be solved with software. A process problem cannot be solved with a licensing agreement. A policy problem cannot be solved with a user interface redesign. When those lines get blurred, technology becomes the default answer to every question, regardless of whether it is the right one. Before you do anything, you have to understand why it is not working.

The Economics Your Vendor Won't Lead With

After you understand why your current system isn’t working and you begin looking at new systems, your attention turns to the financial implications of a new system. I’ll tell you a secret. Vendors are very good at telling a clean financial story. Implementation is framed as roughly one year of licensing, subscription costs feel predictable, and the investment looks reasonable when viewed in isolation. The problem is that this version leaves out how quickly costs expand once the project is underway, especially when assumptions meet operational complexity. Trust me, they inevitably will.

Licensing for a mid-sized organization can easily exceed half a million dollars annually and will increase over time. Implementation typically lands closer to two times the first year’s licensing once integrations, data migration, and inevitable scope expansion are factored in. Over seven years, direct vendor spend alone can cross several million dollars, and that’s before considering what happens inside the business or how long value actually takes to materialize.

Just think about it. What happens when your best people get pulled into the project, leadership attention shifts, and productivity dips during transition? Compare that to your current system, where licenses are already paid, and operational knowledge is embedded. It doesn’t seem so bad. Replacement can make sense, but the financial case needs to be grounded in real outcomes, not a simplified cost narrative that ignores execution.

When Replacement Is Actually the Right Call

At some point in this process, you have to acknowledge that replacement can be the right decision. Just don’t let the decision be led by frustration alone. The decision to move on should be made because your system is actively holding back your strategy, not when it simply feels outdated or inconvenient. If there are capabilities the business needs in order to grow that cannot be supported, even with reasonable extensions or integrations, then we’re talking about a real constraint worth taking seriously. You will feel this in execution, not in theory, whether that shows up as an inability to support new operations, integrate with partners, or scale without constant workarounds.

Growth is usually where this starts to show up in a more obvious way. As organizations expand into new markets, take on more complexity, or acquire other businesses, systems that once worked just fine don’t quite cut it. Again, this does not automatically mean replacement is the right move. More often than not, the issue is not the system itself; it is how it has been configured, governed, and maintained over time. If you don’t take the time to separate those two things, you run the risk of replacing something that could have been stabilized with far less cost and far less disruption.

AI has an interesting way of accelerating this conversation, and not always in a productive direction. It gets brought up as justification for replacement, but it’s rarely a good reason a business needs to change platforms. Most systems today can integrate with AI tools in some capacity, so the limitation is usually not capability; it’s data. If your data is inconsistent, incomplete, or poorly governed, introducing AI does not solve that problem. Faster insights do not help if they are built on unreliable inputs.

At the end of the day, the decision to replace should tie back to a specific outcome the business is trying to achieve. What capability is missing today that cannot reasonably be solved within your current environment? What constraint is actually preventing progress in a measurable way? If those answers are not clear, the decision is likely being driven by trend, pressure, or perception instead of an actual business need.

The Work That Has to Happen First

Before making any decision, please make sure you have a clear understanding of how the business actually operates. Process mapping is a great place to start. It shows where work breaks down, where dependencies exist, and where knowledge is sitting in people’s heads instead of in a system. Without that, it becomes very difficult to tell whether the system is the problem or just the place where the problem is showing up.

From there, you have to separate the issue into people, process, policy, or technology. Each of those requires a different solution, and this is where most organizations get it wrong. Technology becomes the default answer because it is the most visible and easiest to justify, not because it is the right fix. If you misdiagnose the problem, you end up making a large investment that simply moves the issue instead of resolving it.

This is also where leadership discipline matters. High-level directives like modernization or AI adoption sound good, but they do not mean anything without context. You have to translate them into specific outcomes. What capabilities are actually missing, where is the business being slowed down, and what does success look like in practical terms over the next few years? Working backward from those answers leads to better decisions and keeps you from solving the wrong problem with the right tool.

Most organizations do not struggle because they chose the wrong system. They struggle because they did not fully understand the problem before trying to solve it. Without that clarity, replacement often recreates the same issues in a new environment, just with a higher price tag and more complexity layered on top. The organizations that get this right slow down just enough to evaluate based on fit, not perception, and make decisions tied to outcomes instead of momentum.

See you next time, Kyler