Every enterprise IT leader has experienced a version of this conversation. A renewal quote arrives, immediately triggering tough questions about whether the IT service management (ITSM) platform’s increasing cost matches its actual business value. Procurement asks whether the licenses previously paid for are being used, engineering points to the prior upgrade that dragged on for months, and the board lands on the inevitable question: “Is it time to switch ITSM platforms?”
It is a fair question, and it deserves a better answer than the one both sides of the market tend to give. Incumbent vendors will tell you that migration is prohibitively risky, and that the cost and risk of that change far outweigh the benefits. Challengers will tell you that migrating is fast, pain-free, and far cheaper to deliver initially and to run the platform on an ongoing basis. Given the motivations of the respective sides, neither argument provides a solid basis for a decision worth potentially millions over a contract term.
The reality lies somewhere in between. Changing your ITSM platform is entirely achievable, and many enterprises do it successfully every year – but the difficulty rarely sits where organizations expect it to. Adding new technology is relatively straightforward, but several factors beyond the tool itself determine whether the chosen ITSM platform delivers on its promises or becomes a reincarnation of its predecessor.
1. Why organizations consider changing ITSM platform
Given the time, cost, and disruption involved, nobody replaces their ITSM platform on a whim. The decision is rarely triggered by a single event. Usually, it results from an accumulation of several pressures:
The commercials no longer stack up
The renewal value is materially higher, doesn’t correlate to the value of new capability being offered, and senior leaders are asking financial questions that cannot be justified with confidence.
Oversubscription paired with underutilization
Modules were purchased as part of a bundle but were never fully implemented. Capability that was sold sits dormant while the annual fee is paid in full. The gap between what is licensed and what is used continues to widen as new features and enhancements are released.
The estate has fragmented
Mergers, acquisitions, and departmental purchasing have left multiple service desks, overlapping ITSM toolsets and service data spread across systems that do not talk to each other – with no single source of the truth of the technology estate.
Levels of technical debt have become untenable
Years of custom development, undocumented changes, and non-adherence to best practice recommendations make every upgrade a project in its own right, and every ITSM platform change a potential risk.
The tooling and the Target Operating Model (TOM) are misaligned
Clients are demanding product-centric teams, value-stream reporting, and automation at machine speed. The incumbent ITSM platform is configured for ITIL-aligned tiered support, ticket queues, and human handoffs – requiring significant investment to reimagine.
The technology is genuinely end-of-life
The product is being sunset, the on-premises installed version is no longer being supported, or a homegrown system that once worked has become an unsupported liability – and increasingly a security exposure.
Artificial intelligence (AI) aspirations exceed the platform’s capability
The board expects agentic AI automation. The incumbent ITSM toolset either doesn’t offer the capability, or prices it in a way that makes the business case either not stack up or too opaque to determine with any certainty.
The relationship has deteriorated
Lack of support quality, limited vendor input into strategy and roadmapping (save for where it drives license consumption), and aggressive sales tactics have resulted in an erosion of trust – providing a legitimate reason for change even where the technology is working relatively well.
The decision to switch hinges on both the quantity and severity of these triggers. A small number of low-severity issues can likely be worked through. Four or five combined suggest underlying problems that signing a renewal won’t solve.
2. What the market data says on ITSM platform churn
ITSM.tools has run an ITSM tool churn poll regularly since 2017. Its most recent poll (Q3 2025) surveyed 229 respondents on how they feel regarding their primary ITSM tool (and why they did – or will – change it).
The headline is more encouraging than it has been in the past. Some 47% of respondents stated they were happy with their current tool – a notable improvement on the 37% recorded in 2023. At the other end of the spectrum, however, 40% were actively replacing their platform, planning to replace it, or re-implementing what they already have.
How organizations feel about their primary ITSM tool
| Response | 2023 | 2025 | Change |
|---|---|---|---|
| It’s great, we’ve used it for years | 27% | 31% | +4 |
| It’s great, it’s less than two years old | 10% | 16% | +6 |
| We are replacing it (now or soon) | 27% | 19% | -8 |
| We’ll replace it when we can | 15% | 11% | -4 |
| We are or will re-implement the existing tool | 4% | 10% | +6 |
| Undecided / no tool / other | 19% | 13% | -6 |
Source: ITSM.tools ITSM Tool Churn poll, Q3 2025, n=229
The most revealing figure is the one that rose fastest: re-implementations of existing toolsets more than doubled, from 4% to 10%. A growing number of organizations have concluded that their issue was never the product – it was how it was implemented, configured, and operated.
The reasons for change have barely moved in nearly a decade. Tool dissatisfaction relating to usability, flexibility, customization or manual effort tops the list at 16%. High costs – maintenance fees, administrative effort, and upgrade costs – sit second at 14%, having doubled their share between 2019 and 2023 and held there since. End-of-life or outdated tooling is third at 12%.
Interestingly, the rate of tool churn has remained mostly unchanged for the eight years the polls have been running. The inference from this data is that a sizeable number of ITSM tooling replacements do not solve the underlying issues – they simply relocate them to a new toolset.
One new survey entrant does stand out. For the first time, respondents could cite that they “wanted AI capabilities that worked” as their primary reason for change – and 5% did. While this is a small number today, it is also the fastest-emerging driver in the dataset, and I would expect it to grow rapidly given the market direction.
The cost picture is broader than any one vendor
It is tempting to interpret rising ITSM platform costs as a direct result of dominant providers’ pricing strategies; however, the broader data suggests something more systemic. Vertice’s 2026 SaaS Inflation Index puts SaaS price inflation at 13.2% – its highest recorded level and close to 5x the standard consumer inflation rate across G7 countries. SaaS cost per employee has risen from approximately $7,900 in 2023 to $8,700 in 2024 and $9,100 by the end of 2025 – and roughly $1 in every $8 of corporate spend now goes on software.
Against a backdrop of global IT spend forecasted to grow 10.8% in 2026 to $6.15 trillion – largely driven by investments in AI-related hardware and software – ITSM platforms are now having to compete for budget against technology that boards consider an urgent strategic imperative. This competition, more than any individual price increase, is what puts ITSM platform costs under the microscope.
3. So how hard is it to change ITSM platform? The five factors to consider
The technology is almost always the easy part. Modern platforms are designed to be configured rapidly, and a competent implementation team can stand up core incident, problem, request, and change management processes in weeks. In my experience, the difficulty tends to be concentrated in five places, and it is worth considering each as part of the decision-making process.
Data
The decision to migrate or archive your data materially affects migration effort and risk. The case for doing so typically depends on the type of data being considered:
Ticket and case history
This is usually the largest volume, highest complexity, and delivers the least value. Migrating years of closed incidents, problems, requests, and changes into a new ITSM platform will interfere with AI and machine learning capabilities, complicate proactive problem management, impact system performance, and potentially incur storage costs – all in addition to a significant throwaway investment in cost and effort to map schemas between the two ITSM platforms and thoroughly test the data export/import process.
The issue only compounds if the ITSM platform holds ticket data from broader processes – HR cases, risk data, facilities requests, and such like.
Recommendation: don’t migrate ticket data – archive it off, make it accessible to key individuals (auditors, major incident managers, etc.) and retain it for as long as needed.
Master data
Master data presents a distinct migration challenge because it underpins every core process across your IT service ecosystem – from user profiles and asset ownership to service catalogs, foundation taxonomies, and vendor details.
The primary decision factor for master data is whether your ITSM platform or a separate system of record masters the data:
- Where data is mastered elsewhere – integrate directly with your authoritative sources rather than exporting from your existing ITSM platform. This helps ensure the data will remain current as the organization changes.
- Where data is mastered within your ITSM platform – often this scenario presents where an authoritative source didn’t exist, or an integration would have proved too complex, which may no longer be the case. When you can’t pull data from an authoritative source, use the migration opportunity to cleanse it so what you import into the new ITSM platform is complete and correct.
Recommendation: Do not blindly export master data. Integrate directly with primary authoritative systems where possible, and where migration is needed, take the opportunity to rationalize, clean, and map remaining static datasets into the target platform’s native model.
Configuration data
The key differentiator when deciding what configuration management data (CMDB) to import is whether the data is discoverable or non-discoverable:
- For discoverable data, configure the new toolset’s discovery capabilities to scan the estate, de-duplicate records, and populate the CMDB with automatically discovered, dependency-mapped configuration items (CIs), using the prior ITSM platform’s CMDB as a comparable baseline to determine completeness and correctness.
- Non-discoverable data can’t, by its very nature, be discovered automatically in the new ITSM platform, and therefore will require either migrating from old to new, or re-keying. The preferred mechanism will likely be determined by the volume of data involved and whether the effort to re-key outweighs the effort to transform data from one ITSM platform schema to another. In either case, take the migration as an opportunity to validate the correctness of your non-discoverable data, as it is essential to ensure the health of your CMDB and the processes and automation that depend on it.
Recommendation: Don’t import discoverable data – discover it directly in the new ITSM platform. Do import non-discoverable data, and validate it for completeness and correctness as you do.
Knowledge articles
Knowledge base content is high value but is rarely migration-ready. Articles often reference screens that no longer exist, processes that have changed, and links that result in 404s.
Thankfully, generative AI (GenAI) tools can now be leveraged to expedite cleansing and updating these knowledge articles – transforming what was previously an enormously labor-intensive task into an initiative that is not only manageable, but a value-add that should be explored regardless of whether the decision is switching toolsets.
Recommendation: cleanse and update knowledge articles, and import into your new platform. Build out robust knowledge management processes (automated and manual) to continually improve and maintain the currency of your knowledge base.
A note on data extraction
Historically, while not outright charging for data extraction, some SaaS vendors have limited how data can be exported, capped the number of rows per transaction, or charged professional services fees for full database exports.
Fortunately, regulators (in the EU at least) have taken action to remove barriers and exit fees associated with switching cloud products – with full removal coming into force in January 2027. ITSM SaaS tooling fits within this scope, and while the UK doesn’t have an equivalent regulation, we may start to see ITSM platform vendors adopting a single global strategy which caters to these regulations and reduces exit friction.
Integrations
No ITSM platform is an island: monitoring and event feeds, identity and directory services, HR and finance systems, asset discovery, CI/CD toolchains, telephony and chat, and supplier portals all connect in.
To scope a potential migration, it’s critical to understand all existing integrations, the use cases they serve, and the processes they support. Assessing the existing integration inventory against the new ITSM platform’s requirements will determine how many integrations to configure and each integration’s relative complexity.
While reviewing the integrations, also consider whether they support current ways of working or should be reconfigured to support a target future state. For example, an inbound integration from a monitoring tool to create an incident record for human investigation could be reimagined as ingesting event data that an AIOps capability can triage and diagnose, and an agentic capability can remediate without human intervention.
Process and technical debt
Every longstanding implementation accumulates customization that once made sense – a mandatory field added after an audit finding, a custom process for that one edge case, a limitation worked around that the vendor has since fixed.
During migration, the temptation is to replicate functionality that exists today, because replicating is defensible and questioning is uncomfortable. This is the single most reliable way to spend a great deal of time, cost, and effort only to end up back where you started.
This is where a good architect differentiates themselves from the rest. Respectfully challenging a business requirement and rejecting a request for customization is a difficult conversation, but it will invariably lead to a more sustainable long-term solution. It’s often not the case that a requirement cannot be met, but that the new ITSM platform offers a different, customization-free approach to achieving the outcomes needed – a good architect will point that out, rather than incorporating customizations without question.
People and organization
An ITSM platform migration changes how large volumes of people do their jobs. Service desk analysts lose a decade of muscle memory, and resolver groups across infrastructure, application support, and third-party suppliers all have to relearn queues, forms, and escalation paths.
The issue with most technology projects (not just ITSM tooling replacements) is an underinvestment in the people aspect – the organizational change management needed to ensure stakeholders are engaged with, trained on, and supportive of the new ITSM platform.
Prosci’s benchmarking research, drawing on more than 2,600 change practitioners, found that 88% of projects with excellent organizational change management met or exceeded their objectives, compared with 73% for good, 39% for fair, and just 13% for poor. Projects with excellent organizational change management were around seven times more likely to meet objectives and nearly five times more likely to finish on or ahead of schedule than those with poor change management.
Commercial and contractual
The incumbent vendor is not going to tell you that your deadline for moving elsewhere is coming up – the onus will be on the client to establish:
- Notice periods/auto-renewals – and whether the window to serve notice has already passed
- Whether the contract structure allows a partial exit, or whether the license is all-or-nothing until expiry
- Whether any negotiated discounts on the incumbent are contingent on scope that a phased exit would breach
- The likely length of the dual-running period – almost every enterprise migration involves paying for two platforms simultaneously for some months.
While an understanding of the financial implications is key to building a robust business case, it also gives you the full picture to support negotiations. Being candid with potential new tooling partners about the material costs of change gives them a chance to help structure a deal that ensures the business case stacks up. I’ve seen first-hand the financial engineering that can close a deal, and if you never ask, you’ll never know.
4. ITSM platform Agentic AI considerations
Agentic AI is increasingly a reason organizations look elsewhere and is often one of the more compelling benefits of moving; however, it introduces a new category of migration risk that did not exist three years ago.
As a driver
Gartner expects agentic AI to autonomously resolve 80% of common customer service issues by 2029, with an associated 30% reduction in operational costs. Boards have read the same forecasts and are directing their teams to harness its capabilities. Where an incumbent ITSM platform cannot demonstrate credible agentic capability – or gates it behind a tier or a consumption model the business case will not carry – that becomes a strategic argument for change rather than a feature comparison.
As a prize
The benefit case is genuine, but it is conditional. As I outlined in a prior article on whether IT service management is still necessary in the age of agentic AI, autonomous agents can only work with the data available to them. An AI agent cannot resolve a ticket, execute a change, or assess blast radius correctly if it is working from incomplete, siloed, or out-of-date asset and dependency data. A migration that delivers a robust data foundation is one of the few opportunities to make agentic capability work as vendors advertise. An implementation built on bad data only expedited the existing confusion.
As a portability risk
A new problem, but one that deserves direct attention – if you have invested effort in building AI capability on your current ITSM platform, how much of it moves?
The answer depends on which category your existing agentic capabilities are aligned to:
What does not port
Platform-native agent definitions, skills, prompt libraries, guardrail configurations, and the orchestration logic built in a vendor’s own agent studio are highly unlikely to be portable. The good news is that challenger vendors will likely offer the same or similar capabilities out of the box – lean on these vendors to help determine what (if any) functionality will be lost, and how the migration to new agentic capabilities can be safely expedited.
What might port
Integration patterns are becoming more portable if architected to utilize the Model Context Protocol – an emerging common standard for connecting AI systems to tools and data. Where your AI agents reach external systems through open protocols rather than proprietary connectors, that layer is far more transferable. While this might be the direction of travel, the standards are young, and adoption across ITSM vendors is uneven.
What ports fully – and matters most
The data that underpins your ITSM platform may not in and of itself be agentic, but it is what ultimately determines the performance of your AI agents. A mature AI agent operating on incomplete or incorrect data will consistently underperform a basic AI agent running on a clean, well-structured foundation. Automated decision-making doesn’t overcome poor data quality; it just scales its impact.
5. How to accelerate and de-risk an ITSM platform migration
Migrations that go badly tend to fail for similar reasons, and so do the ones that go well. These factors make the biggest difference in practice.
- Scope discipline. Agree the scope at the outset and stick to it, adding enhancements that invariably crop up during design and build to a roadmap rather than incorporating them. Leverage out-of-the-box features, configure where needed, and customize only by exception with a named owner and a business justification. The single biggest predictor of a successful migration is a team empowered to say no.
- Migrate less. See the earlier sections on data. Every decision not to migrate shortens the critical path and reduces risk.
- Leverage vendor migration tooling and pre-built connectors. Most major ITSM platform vendors now offer competitive migration accelerators, schema mapping templates, and pre-built integrations for common enterprise platforms. Assess these capabilities when comparing toolsets and factor them into your decision-making, rather than waiting until you’re in the design phase.
- Use AI to support the migration. Rewrite and rationalize knowledge articles, assess and translate workflow logic, generate and execute test scripts, and map legacy fields to new schemas – work that consumed months of analyst time is now measured in weeks.
- Engage your stakeholders. Ensure an organizational change management workstream is included from the outset – identifying who is impacted, how they will be impacted, and managing comms, training, and engagement is key to ensuring buy-in and adoption of the new tool.
- Executive sponsorship. No migration is drama-free. Every ITSM platform project will reach a point where emotions run high, and there are disagreements – the programs that succeed have a sponsor who will hold the line, and who understands they are sponsoring an operating model change rather than a tooling purchase.
6. Where the right partner makes the difference to ITSM platform change
Most enterprises involve a third party when migrating their ITSM platform, and the choice of partner materially impacts the project’s success. It is worth being clear about what the different parties are incentivized to do.
- Independence from the ITSM platform decision. A specialist partner aligned to one toolset is not well placed to advise on which ITSM platform is right for you. That answer is best from an agnostic partner most incentivized to give the right advice.
- Front-loading the decisions that cost most to reverse. Scope, data, integration architecture, process design, and the customization policy should all be decided early and signed off. An experienced partner will ensure this happens, as changes later in the project will lead to overruns.
- Time & Materials (T&M) vs Fixed Cost. Some partners will only contract on a T&M basis, citing the flexibility this model enables. Viewed through a different lens, however, the same model could incentivize scope creep and delayed decision-making. A partner that truly understands the ITSM platform they are implementing and takes the time to get to know the client will rarely have a problem committing to a fixed-price, fixed-outcome engagement.
- Onshore vs nearshore vs offshore. Delivery models are rarely one-size-fits-all. While onshore teams offer local presence and effortless cultural alignment, nearshore and offshore models can provide cost efficiencies, extended time-zone coverage, and access to broader talent pools. Ultimately, the priority should be balancing the cost against the quality and certainty of delivery, and selecting a partner whose culture, communication style, and governance naturally align with your existing ways of working.
7. Conclusion on changing ITSM platform
So, how hard is it to change ITSM platforms? Easier than the incumbent implies, but harder than the challengers suggest.
The technology will migrate, modern platforms configure rapidly, migration tooling is mature, and AI has removed significant effort from the project. Overall success depends on having an accurate picture of your dependencies, a documented understanding of your integrations, the discipline to redesign processes rather than replicate them, and a serious commitment to the people side of the change.
The key question isn’t “how hard is it to switch?”, but “what exactly are we trying to fix?” Answering that question precisely will determine whether switching is the right option and will inform the business outcomes needed from a migration to succeed.
ITSM Platform Change FAQs
There are two: the first is replicating your existing issues in a new ITSM platform. If processes are inefficient, data is unreliable, or customizations are rife, migrating them as-is to a new tool will yield the same outcomes. The second big risk is under-resourcing organizational change management, with research finding that projects with poor change management met their objectives just 13% of the time, against 88% for those with excellent change management.
Re-implement when the complaints are about usability, process design, cluttered forms, or manual effort, as these are configuration issues that will likely follow you to the new platform. Replace when the ITSM platform cannot support your target operating model (TOM), is end of life, the vendor relationship has broken down, or when the commercial model no longer stacks up.
First, understand what you are trying to fix, rather than treating the project as a like-for-like replacement. Stick to out-of-the-box configuration, with exceptions only where there is a named owner and a genuine business justification. Redesign processes in line with the new ITSM platform rather than replicating what you do today. Rebuild rather than migrate configuration data that can be discovered. Define the operating model before the platform is configured – not after go-live.
Twelve to eighteen months before renewal is generally the sweet spot – partly for practical reasons, as a proper evaluation, business case, and procurement cycle takes time – and partly for commercial reasons, as your negotiating position with the incumbent is strongest when you have a genuine, evidenced alternative and enough runway to act on it.
Vendor professional services, large systems integrators, and boutique consulting firms can all have a role to play – the key is matching their strengths to your specific scope, budget, and culture.
Vendor Professional Services: Best for deep platform product expertise, but often limited in broader process and organizational change management strategy.
Large Systems Integrators (SIs): Best for massive scale where significant engineering is required, though typically with higher overhead and less agility.
Boutique Consultancies: Best for deep domain focus, senior attention, and agile delivery, though may need to partner with on/nearshore SIs where significant scale is required.
