Someone on your team wants to replace a platform you already run. You’ve heard the reasons: there’s too much tech debt, the code needs a rewrite, or another vendor is simply better.
They might be right. Before you approve the switch, ask what problem replacing it would solve that fixing what you have can’t.
A vendor comparison won’t answer that. It ranks products against the requirements someone picked, but it never weighs the switch against improving the platform you already own. For that, ask for two business cases, one for replacing and one for fixing, and judge them side by side. The four questions below build both cases, and the replace, fix or wait table shows which call they support.
Why the Person Pushing the Switch Is a Risk
On Signed, Max Clark has a warning about the person telling you there’s too much tech debt, or that you should drop one vendor for another. He says that’s probably the most dangerous person in your company. His examples are the comparisons IT teams argue about: Google versus Microsoft, Cisco versus Juniper, CrowdStrike versus Sentinel. Focusing on those, he says, means focusing on the wrong thing.
Part of the reason is who does the checking. A switch is usually evaluated by the team that owns the platform. Security compares security tools, the network team compares network vendors, and each comparison can be honest and accurate. But nobody is assigned to check what the change does to the systems next to it, and on a lean IT team that job often has no owner at all. The person pushing the switch can be right about their platform and still not see what the change does to the rest of yours.
Tech debt is still real. Older platforms carry security, reliability and maintenance costs, and replacing one is sometimes the right call. Make that call on the business case, not on the demo. If a modernization push is behind the request, here’s what’s at stake when vendors are the loudest voices in the room.
What Else a Platform Switch Affects
Your environment is a set of blocks that work together: sign in and identity, devices, network, security tools and the apps your people use. Standard interfaces help them connect, but changing one block can still affect authentication, data, workflows and who supports what. Replace the identity system, for example, and every app your people sign in to through it, plus device enrollment and remote access, may need to be reconnected and tested. Some products come out cleanly. Others are wired into everything.
So map the dependencies and check each one. Don’t assume every connection needs rebuilding, and don’t assume none do.
Then count the cost that rarely makes it into the business case: the time a migration pulls from engineering, operations, testing and support. That time comes out of projects the business already approved.
What you already run also limits which replacements are realistic. Two Questions to Answer Before You Compare a Single Vendor covers how to use that before your first vendor meeting.
Four Questions to Answer Before You Replace It
These are the four questions Max asks before any platform swap. Each one ends in a decision test you can answer in writing.
What does the business need?
Name the actual problem and check whether the current platform can solve it at a cost and risk you can accept. Put three things on paper: the requirement, where today’s platform falls short, and evidence that the replacement closes the gap.
Decision test: can the current platform meet the requirement at an acceptable cost and risk, or is replacement justified?
What are you already running?
List the systems, contracts, renewal dates, processes and skills a replacement would touch. Sort them into what must change, what can stay and what still needs technical testing.
Decision test: what will we have to replace, rebuild, retrain or run in parallel, and has someone outside the platform’s own team reviewed that list?
Where are you heading?
Check the platform against changes the business has committed to, such as an acquisition, a growth target, a new regulation or a new operating model. Leave out plans that are still only possible.
Decision test: does this choice support the plans we’ve committed to without setting up the next replacement project?
How do you win?
Define the improvement you expect, how you’ll measure it, what it costs to get there and who owns the result. Set milestones during the migration, not just a review a year after go live.
Decision test: what measurable improvement justifies the cost, the risk and the engineering time?
When to Replace, Fix or Wait
Your four answers point to one of three calls.
| Decision | When it makes sense |
|---|---|
| Replace | The current platform can’t meet an important requirement, or meeting it would cost more or create more risk than replacing it. The expected benefit has to justify the full cost and risk of the transition. |
| Fix what you have | The problem comes from configuration, process, implementation or features you aren’t using, not from a real limit of the platform. |
| Wait | The business need isn’t established, key dependencies are still unknown, or the numbers don’t work yet. Use the time to gather the missing evidence, and set a review date or trigger for deciding again. |
To make the call, ask whoever is proposing the switch for two business cases: one for replacing the platform and one for improving what you have. Build both on the same requirements and time horizon. Use the same cost lines in each: licensing, implementation, internal labor, ongoing support, transition risk and the work your team would have to put aside. If improving the current platform isn’t viable, the case should say why. A replacement that only wins on features hasn’t made its case.
What to Bring to the Approval Meeting
- The problem you’re solving.
- Why the current platform can’t solve it at an acceptable cost and risk.
- The systems, contracts and teams the change affects, reviewed by someone outside the team that owns the platform.
- The full cost of replacing compared with keeping and improving, including the work it delays.
- The measurable result that makes the switch worth it.
If any of the five is missing, the decision isn’t ready. Set a date to revisit it and name the evidence that would settle it. When all five are answered, fund the business case that does more for the business, whether that’s the new platform or the one you already own.
ITBroker.com helps buyers compare replacing, fixing and keeping on the same terms, before vendor proposals shape the decision.
