When your IT service management (ITSM) tool isn’t delivering what you need, replacing it feels like the obvious answer. A fresh start on a new ITSM platform with better features, slicker automation, maybe some artificial intelligence (AI) capabilities thrown in.
We see this constantly. Organisations on their third or fourth tool in the last decade, each time convinced this will be the one that finally sorts things out. Each time, within eighteen months, the same frustrations creep back in.
Here’s what we’ve learned from watching this cycle repeat: the tool is rarely the issue.
You bring your issues with you
Migrating to a new ITSM tool doesn’t fix your bad data. It just moves your bad data to a new location.
If your configuration management is a mess, it’ll be a mess in ServiceNow, BMC, Ivanti, or anywhere else you take it.
If your incident categories don’t make sense, they won’t suddenly make sense because you’ve rebuilt them in a different ITSM tool.
If nobody can agree on what constitutes a service, you’ll still be having the same arguments six months after the new ITSM tool’s go-live.
The new tool feels better at first because you’re starting with a cleaner implementation. But you’re building on the same foundations. The same undefined processes, the same data quality issues, the same lack of agreement about what you actually need the ITSM tool to do.
Give it a year. The same issues will surface.
Most ITSM tools do the same thing
For the core ITSM capabilities most organisations use day-to-day, ITSM tools are fundamentally the same.
Yes, some have fancier interfaces. Some have significantly more bells and whistles. Some have AI features that look impressive in demos. But incident management, service request management, change management (or change enablement if you use ITIL 4 and now ITIL (Version 5)), basic reporting? They all do it. The differences between ITSM platforms matter far less than vendors would have you believe.
This is why my advice has always been to choose the vendor, not the tool. Your relationship with your ITSM tool vendor matters far more than the specific ITSM platform you’re running. A vendor who understands your organisation, responds when you need them, and genuinely invests in your success will get you further than the most feature-rich ITSM tool backed by a vendor who disappears after implementation.
When organisations tell us their tool isn’t working, we often find the real issue is that they’ve been left to fend for themselves. The vendor relationship has gone cold, support requests go unanswered, and nobody’s had a proper conversation about the ITSM tool roadmap or development in years. That’s not a tool problem.
The cost of starting over
Tool migrations can be exhausting. They likely consume enormous amounts of time, money, and organisational energy.
Your teams and end-users have to learn new interfaces, new workflows, and new ways of doing things that they could do in their sleep on the old ITSM platform. People who were already stretched thin now have a massive change project on top of their day jobs, and there’s only so many times you can tell an IT service desk team that this migration will be the last one before they stop believing you.
Before committing to that level of disruption, it’s worth being very sure your current ITSM tool genuinely can’t do what you need.
“The grass is always greener”
Every ITSM tool vendor demo looks fantastic. The interface is clean, the workflows are smooth, and the new features seem to solve issues you didn’t even know your organisation had.
What you’re not seeing is the reality of implementation. The compromises you’ll have to make. The features that work brilliantly in a demo environment but get complicated when they meet your actual data and processes.
You’re also comparing a polished sales demo against your current ITSM tool at its worst, weighed down by years of accumulated configuration decisions, workarounds, and technical debt. That’s not a fair comparison.
It’s not just about the tools
The most successful ITSM tool implementations we’ve seen have one thing in common: the customer organisations treated the tool as part of a broader organisational change, not as a solution in itself.
An ITSM tool can’t fix a culture that doesn’t value service management. It can’t overcome resistance to process adherence. It can’t create collaboration between teams that don’t talk to each other. If your people don’t want to use the ITSM tool properly, it doesn’t matter how good it is.
This is why organisations can struggle with best-in-class tools while others thrive on more basic ITSM tools or platforms. The difference isn’t the technology. It’s whether the organisation has done the harder work of getting people on board, embedding good practices, and creating an environment where the ITSM tool can actually be used as intended.
If you’re planning to change ITSM tools without addressing the cultural and organisational issues underneath, you’re setting yourself up for the same disappointments all over again.
However, if you are sourcing a new toolset, this can be a great opportunity to run a wider transformation project that results in improved processes and governance, better performance, new functionality and easier access to good data.
There are two critical areas that determine success: data and the project itself. A good, revised data model will give you the outputs and reports you need. The project to transform and implement the tool also has to remember that this requires people and business change, not just technology.
An ITSM toolset is a business application, and as such requires a holistic approach to ensure success.
What to try before you rip and replace
Consider whether you’ve outgrown your implementation rather than the tool itself. The way you set things up three years ago made sense for the organisation you were then. You’ve grown, changed, and restructured. The tool hasn’t kept pace, but that doesn’t mean it can’t. A proper review and redevelopment of your existing ITSM tool implementation might get you where you need to be without starting from scratch.
Look at your vendor relationship. When did you last have a proper conversation with them about the tool’s roadmap (and your adoption of new capabilities)? Are you getting the support you’re entitled to? Do they know what you’re struggling with? A surprising number of organisations drift away from their ITSM tool vendors after implementation and miss out on updates, advice, and support that could make a real difference. Sometimes rebuilding that relationship is worth more than any new feature set.
Be honest about whether the issue is the tool, the processes, or the culture around it. If your service definitions are unclear, that’s not a tool problem. If your data quality is poor, that’s not a tool problem. If nobody follows the processes you’ve designed, that’s definitely not a tool problem. Fix these things first, then see how the tool performs.
When changing tools might makes sense
Sometimes it is time to move on.
If your current ITSM tool vendor is sunsetting the product or no longer investing in development, staying put isn’t viable. If your organisation has fundamentally changed and the tool genuinely can’t scale or adapt to what you’ve become, a change makes sense. If the vendor relationship has broken down beyond repair, or the commercial terms no longer work, those are legitimate reasons to look elsewhere.
But these situations are less common than the industry would have you believe. ITSM tool vendors have a vested interest in selling you new platforms. Implementation partners have a vested interest in ITSM tool migration projects. Mindsets might think, “Nobody makes money from helping you get more out of what you already have.” But this is no longer true with subscription-based ITSM tools. Your existing ITSM tool vendor can avoid the customer churn and the associated loss of subscription revenue.
Start with an honest assessment
Before you write the business case for a new ITSM tool, get a proper picture of where you actually are. What’s working? What isn’t? Is the issue the tool, the implementation, the processes, or the culture? What would need to change to make your current setup work properly?
This kind of honest assessment might confirm that you do, in fact, need to move on. But it might also save you a year of change and a significant budget for an ITSM tool migration that doesn’t solve everything.
Need help? Get in touch.
