ITSM modernisation challenges typically surface months after the project closes, not during it. The tool is live. The implementation is signed off. Leadership expects improvement. Instead, teams quietly return to old habits. Backlogs creep back. Frustrations resurface. The phrase “we already modernised” starts to sound defensive rather than factual.
This pattern is not unusual. According to Gartner’s 2024 annual survey of CIOs and technology executives, only 48% of digital initiatives meet or exceed their business outcome targets. Not because the technology is wrong, but because the operating model underneath it does not change. The platform is new. The behaviour is not.
A note on where we stand: KlickFlow is a Freshworks Premium Partner and runs post-implementation ITSM optimisation for ANZ mid-market teams. That shapes how we deliver, not how we advise. The blockers below are platform-agnostic; they stall modernisation on any tool.
If your modernisation effort feels stalled, the next step is not more configuration. Book a diagnostic call and we will identify exactly where it has stopped and what to change first.
TL;DR
- Most ITSM modernisation challenges stall efforts for the same four reasons: legacy demand stays untouched, ownership is unclear after go-live, metrics still reward activity over outcomes, and improvement is treated as a project rather than a discipline.
- The platform change happens; the operating model change does not. A new tool running old processes produces old outcomes faster.
- Modern ITSM is defined by what work disappears: password resets agents no longer handle, recurring incidents that stop recurring, and approvals that no longer need chasing.
- Recovery rarely needs a reimplementation. Redesigning three to five high-volume workflows and fixing ownership usually produces measurable improvement within 60 days.
- Identifying which of the four blockers applies to you is the fastest way to get the modernisation back on track.
How ITSM Modernisation Quietly Becomes ITSM Implementation
Most ITSM modernisation efforts begin with genuine ambition. There is a roadmap, stakeholder workshops, and organisational alignment. Everyone understands the problem and agrees on the direction. Then execution starts.
This is where modernisation quietly becomes implementation. Processes are migrated instead of redesigned. Old workflows are rebuilt in the new tool because redesigning them takes longer than expected and the go-live date is fixed. Automation is deferred to phase two. Phase two never arrives because the team is consumed by post-go-live stabilisation. Six months later, the platform is live but the operation looks almost identical to what it replaced.
As ITIL 4 states directly, modern service management requires continual improvement as an operating discipline, not one-time change delivered as a project. When that principle is applied only at the implementation stage and then abandoned, modernisation stalls at the point the project closes.
The modernisation failure rate
According to Gartner’s 2024 CIO survey, only 48% of digital initiatives meet or exceed their business outcome targets. The most consistent finding across failed initiatives is that technology investment precedes operating model change rather than following it.
Why Tools Do Not Create Modern ITSM
One of the most persistent ITSM modernisation challenges is overestimating what a platform change can achieve on its own. Tools make work visible. They do not change how work flows. Research on IT service management finds that organisations focused on tooling see limited improvement in service quality unless governance and ownership models change at the same time.
In practice, tickets move faster but repeat issues remain. Dashboards improve but decision-making does not. Automation exists but only in isolated pockets from the initial rollout. The system looks modern. The experience does not.
The right question for a modernisation effort is not how to roll it out. It is what should stop happening once the operation is modern. That shift in framing changes everything about how the project is designed.
Modern ITSM is not defined by the features enabled on the platform. It is defined by what work disappears. Password resets that agents no longer handle. Recurring incidents that no longer recur. Approval workflows that no longer require manual chasing. If these outcomes are not present after modernisation, the operating model has not changed regardless of what the platform is capable of.
The Four ITSM Modernisation Challenges That Stall Most Efforts
Across mid-market ANZ engagements, the same four blockers appear regardless of which platform the team implemented or how the project was structured.
1. Legacy Demand Stays Untouched
Request volumes are accepted as fixed rather than analysed. The modernisation project focuses on handling existing demand more efficiently. That is a reasonable goal. But it misses the more valuable question: how much of this demand should not exist at all? In most mid-market service desks, 20 to 30% of ticket volume is generated by preventable incidents, inadequate self-service, or process gaps. Modernisation that does not address demand reduction produces a faster version of the same problem.
2. Ownership Remains Unclear After Go-Live
Tickets move through the new platform, but accountability does not change. Service categories exist but nobody is named as the outcome owner for each one. The new system has the same handoff patterns as the old one, just with better-looking dashboards. Unclear ownership is the single most reliable predictor of a backlog that returns to its pre-modernisation level within 90 days of go-live.
3. Metrics Still Reward Activity Over Outcomes
The team is measured on ticket closure speed and SLA compliance after modernisation, just as they were before. These metrics reward processing throughput. They do not reward whether recurring problems were addressed, whether self-service adoption improved, or whether the business experienced a meaningful change in IT service quality. Teams optimise for what is measured. If the measurement framework does not change, the behaviour does not change.
4. Improvement Is Treated as a Project Rather Than a Discipline
The modernisation project closes and the improvement work stops. There is no ongoing review cadence. No owner for the service improvement backlog. No mechanism to identify when a process is drifting back toward its previous state. According to HDI research, organisations that maintain a structured service improvement discipline after go-live report higher satisfaction and lower operational strain than those that treat modernisation as a one-time event. The difference is not the platform. It is whether improvement is ongoing or episodic.
What Successful ITSM Modernisation Actually Looks Like
Teams that successfully modernise and sustain the improvement share a consistent approach. They redesign services before configuring tools rather than replicating existing processes in a new platform. They reduce the number of workflows, accepting that fewer well-designed workflows outperform many poorly-designed ones. They assign clear end-to-end service ownership before go-live so accountability is built into the operating model from day one. They introduce automation after stability exists, not as a workaround for instability.
Most importantly, they define success in terms of what stops happening rather than what starts. Fewer recurring incidents. Less escalation. More self-service resolution. More strategic time for IT leadership. These are the signals that modernisation has worked.
Western Sussex Hospitals NHS Foundation Trust: modernisation that changed how IT was perceived
Western Sussex Hospitals NHS Foundation Trust replaced a legacy outsourced ITSM system that had generated organisation-wide discontent. After moving to Freshservice and redesigning how IT services were delivered, the performance of IT operations improved so significantly that the IT team shifted from being viewed negatively to being seen as a value-add by the wider organisation. Automation reduced time spent on calls, SLA adherence improved, self-service usage rose from 10% to 34%, and pressure on the IT team was relieved. The platform change was the enabler. The operating model redesign was the outcome. Source: Freshworks customer case study.
A Practical Reality Check: Has Your Modernisation Actually Worked?
If ITSM modernisation has genuinely succeeded, specific signals are present in the operation. Check each one against your current state.
| Signal | Present? | If absent, likely cause |
|---|---|---|
| Recurring incident rate has measurably reduced | Yes / No | Problem management not implemented post-go-live |
| Prioritisation is consistent and does not change daily | Yes / No | Ownership and prioritisation rules not defined |
| Self-service adoption has increased since go-live | Yes / No | Self-service portal not redesigned around user intent |
| IT leadership has meaningful strategic time | Yes / No | Operational demand not reduced through automation and demand management |
| Business stakeholder confidence in IT has improved | Yes / No | Operating model change did not accompany platform change |
If three or more of these signals are absent, the challenge is not adoption of the new platform. The operating model behind the platform has not changed. That is a design problem, not a technology problem, and it requires a different intervention than more configuration.
For teams in this position, our ITSM platform optimisation service covers post-implementation operating model redesign as a core component. For teams still planning a modernisation effort and wanting to avoid the patterns above, our article on ITSM implementation mistakes covers the structural decisions that determine whether a modernisation succeeds or stalls. You can also read our article on ITSM inefficiency for the specific operational symptoms that a stalled modernisation typically produces.
Book a 30-minute diagnostic call. We will tell you what is broken, what is not, and what to fix first.
Frequently Asked Questions
Most ITSM modernisation efforts fail because they treat the platform as the primary intervention rather than the operating model. When existing processes are migrated into a new tool without redesign, the new system produces the same outcomes as the old one. Technology investment precedes operating model change rather than following it. The result is a modern platform running an unchanged operation.
ITSM implementation is the process of deploying a platform. ITSM modernisation is the broader change to how IT services are designed, owned, measured, and improved. Implementation is a project with a start and end date. Modernisation is an ongoing discipline. Most organisations complete the implementation successfully and then stop, which is why the operational outcomes of modernisation rarely materialise.
Meaningful operational improvement should be visible within 60 to 90 days of go-live when the implementation included proper process design, service ownership definition, and a structured adoption plan. If metrics have not improved within 90 days of go-live, the most likely cause is that workflows were migrated rather than redesigned. In most cases, a focused post-implementation review can identify the specific gaps within one to two weeks and produce a prioritised remediation plan.
Yes, in most cases. A full reimplementation is rarely necessary. The most effective recovery approach is a structured operating model review that identifies which workflows were migrated without redesign, where service ownership is unclear, and what metrics need to change to drive different behaviour. In most mid-market engagements, addressing three to five high-volume workflows and establishing clear ownership produces measurable improvement within 60 days without touching the broader platform configuration.
For a mid-market ANZ IT team, successful ITSM modernisation produces five measurable outcomes within 90 days of implementation: a reduction in recurring incident rate, consistent prioritisation without daily renegotiation, measurably higher self-service adoption, more strategic time for IT leadership, and improved business stakeholder confidence in IT. If these five outcomes are absent after 90 days, the modernisation has delivered a platform change but not an operating model change.