There is Zero Reason, Anymore, to Buy an Overpriced ITSM or ESM

As I sat burning midnight tokens, a realization hit me.

For a long time, moving from one ITSM to another carried a set of roadblocks - some real, some perceived, and the two frequently indistinguishable from the inside. That was especially true when the product you were leaving was a premium one, expensive enough that leaving it felt like an admission of something.

So in this piece I want to go through the objections one at a time and work out which of them still hold. Not the marketing version of the objections. The ones people actually say in the room, including the ones they only say after the third meeting.

I should be clear about where I sit. We build a competing product, so read this as an argument rather than an audit. But I have written it honestly, which means three of these objections survive and I say so.

The ones that should genuinely stop you

Let me start here, because a piece that dismisses every objection convinces nobody.

You use the platform for far more than service management. If you are running IT operations management, security operations, governance and risk, and application development on the same platform, then service management is one module of many and replacing it is not the question you are actually asking. Nothing below applies to you in the way it applies to everybody else.

You have a mature CMDB that other things depend on. Not a CMDB that exists but the one that is actually current, fed by discovery, and driving change risk assessment and impact analysis. That is genuinely hard to rebuild and genuinely valuable. Most organizations do not have this, and the ones that do know exactly who they are.

Your regulator requires a specific certification the alternative does not hold. Rare, decisive, and nothing to argue with.

Strip those three out, what is left is the rest of this article, and my argument is that none of it is a reason.

"We have too much built in it"

This is the objection I hear most, and the way it is phrased hides the real concern.

The stated version is about time, that a migration will take eighteen months and consume a team we do not have. The actual version, once you get there, is that nobody knows what is in the system. Forty integrations built over nine years, two hundred workflows, half of them created by people who left. The fear is not the effort of moving so much as the discovery.

Two things are worth saying about that. The first is that AI has changed migration economics substantially: what used to be a discovery and rebuild exercise measured in quarters is now measured in weeks, and we run transitions in fifteen to thirty days, with workflows read and translated rather than reverse-engineered by hand.

The second point matters more. The undocumented estate you are afraid to move is a problem whether or not you move. Every year it gets harder to change, more people who understood it leave, and more of your operating model depends on things nobody can explain. A migration forces the audit you have been postponing. That is uncomfortable and it is not a reason to stay.

Worth asking: of those two hundred workflows, how many fired in the last ninety days? In my experience the number surprises people, and it usually surprises them downward.

"No other product can do what ours does"

Frequently true, and almost always irrelevant.

The premium platforms genuinely do more, but the question is not what the product can do. Rather, it is what you use, and whether the things you use are the things that justify the price.

So run the comparison properly. List the capabilities you actually depend on - not the ones in the contract but the ones that would break something if they disappeared tomorrow. Then compare that list, rather than the feature matrix, against the alternative.

Most organizations find the list is shorter than they expected, and that a meaningful part of it is service management fundamentals available in any serious product. The differentiating capabilities are real but few, and the price is attached to the whole platform rather than to those few.

There is a second version of this objection worth naming. It sounds something on the lines of "nobody else can do it at our scale." Scale claims are testable. Ask for a reference at your size and your complexity, and ask what happened in month six rather than at go-live.

"My career is linked to this product"

Nobody says this out loud in a vendor meeting. Almost everybody thinks it, and it decides more of these evaluations than any technical factor.

I want to treat it seriously rather than dismiss it, because the concern is rational. Someone with a decade of expertise, several certifications and a professional network built inside one ecosystem is being asked to consider giving up a large part of what makes them valuable. That is a real cost to a real person, and telling them it should not matter is both wrong and ineffective.

Two honest observations;

1. The scarce skill in this field is shifting, and it is shifting quickly. Knowing how to configure a particular platform is worth less every year. Knowing how to design service delivery, decide what should be automated, govern what agents are permitted to do, and measure whether any of it worked. That is worth more every year, and it is portable. The people who came through the last platform transition well were the ones who moved toward the design problem and away from the configuration one.
2. The platform you are certified in is changing underneath you regardless. Every major vendor in this space is rebuilding around AI, which means the specific knowledge is depreciating whether you switch or not.

The person whose career is genuinely at risk is not the one who moved. The risk sits with whoever spent five more years becoming expert in a configuration model that stopped mattering.

"Security"

Sometimes this is a real question. More often it is a proxy, and the tell is that it arrives without specifics.

When it is real, it is answerable: certifications, data residency, tenant isolation, what the AI is permitted to read, retention, who can see what, and whether the audit trail would satisfy someone asking a difficult question a year later. Any serious vendor should answer all of that in a document, and you should ask for it early rather than late.

When it is a proxy, what sits underneath is usually one of three things. Procurement fatigue, because a new vendor means a new security review and nobody wants to run one. Vendor risk, meaning you are worried about betting on a smaller company. Or genuine uncertainty about AI specifically, which is reasonable and deserves its own conversation rather than being folded into a general security objection.

All three are worth discussing. None of them is a security problem, and conflating them prevents any of them getting resolved.

"Ours is an ESM platform, not just ITSM"

The useful distinction here is between what you licensed and what you run.

Plenty of organizations bought the HR module, the facilities module and the legal module, and use approximately one of them. If HR is genuinely running on the platform, i.e. their own catalog, their own workflows, their own case management, with HR administering it themselves, that would be a serious dependency and worth weighing.

If HR has a form on the portal and everything real still happens in a shared mailbox, then you licensed ESM and did not implement it. That is not a reason to stay. If anything it is a reason to look, because the thing you paid for did not happen and it is worth asking why.

The question I would put to any organization making this objection: what proportion of HR requests actually arrive through the platform? The answer is usually available and usually low.

"We are locked into the contract"

True, and it is a timing question rather than a decision question.

You will pay until renewal whatever you decide, so the contract does not determine what you should do, only when you can do it. Treating a contractual constraint as a strategic decision is how organizations end up three years further in, having renewed once more because the evaluation never started.

The practical move is to run the evaluation now, on the timeline the contract allows, so that renewal becomes a decision rather than a default. Evaluations take months, and contracts renew in an afternoon.

"We have ten years of ticket history"

Ticket history matters less than people expect, and the reason is worth sitting with.

Historical tickets are useful for two things: trend reporting and training automation. The reporting is generally exportable. And for automation, recent data is far more valuable than old data. E.g. service desk ticket volume from 2017 may describe workflows, an application estate and a working pattern that no longer exists.

There is also a question hiding here. If a decade of ticket data is genuinely central to how you operate, it should be feeding something. If it sits in a system nobody queries except at audit time, it is an archive rather than an asset, and archives can be exported.

"We can hire certified people for this platform tomorrow"

Fair, and it is worth turning around.

Needing a supply of certified specialists is a cost, not a benefit. The reason that market exists is that the platform requires it. A product that a non-technical person in HR can configure does not have a certification ecosystem, and that absence is the point rather than a gap.

The question to ask is not whether you can hire for it, but how many of those people you need and what you are paying them to do.

"Will you still exist in five years?"

The most legitimate objection on this list after the three at the top, and it deserves a straight answer rather than reassurance.

It also cuts both ways at the moment. Three of the most prominent AI service management products were acquired within four months of each other. The incumbents are buying the disruptors, and the product you chose last year may have different owners and a different roadmap this year. Continuity is not something the large vendors can promise either.

What you can reasonably ask any vendor: who owns you, what happens to the roadmap on acquisition, what the data export path looks like, and what the contractual position is if the product you bought becomes a component of something else. Ask us that too.

"Nobody got fired for buying the incumbent"

Nobody says this one out loud either, and it is the institutional version of the career objection that is deciding a great many evaluations.

The observation I would make is that the defensibility of that position has a shelf life. The argument held when the alternative was an unproven startup and the incumbent was obviously safe, and it holds less well when the incumbent's own pricing is a line item your CFO asks about annually and the alternatives have named customers at your scale.

At some point the safe choice becomes the one you have to explain.

The verdict for you

Take the three genuine objections off the table first: platform breadth well beyond service management, a mature CMDB other things depend on, and a regulatory certification you specifically require. If any of those apply to you, this article is not about your situation.

If none of them apply, look at what is left: undocumented complexity that is a problem either way, capabilities you do not use, careers that are shifting regardless, security concerns that are usually procurement concerns, ESM you licensed and did not implement, a contract that dictates timing rather than direction, history that is exportable, a certification market that exists because the product needs one, and a preference for the incumbent that used to be the safe answer.

None of those is a reason. Several of them are habits, and a couple of them are fears that deserve a proper conversation rather than a shrug.

My position is not that everyone should leave their ITSM. My position is that most organizations have never seriously asked, and the objections that stopped them from asking no longer hold.