ServiceNow to Jira Service Management transformation
MRI Software made this journey — from ServiceNow to Jira Service Management — and came out with a simpler, more cost-effective, and more capable environment.
ITSM Migration vs Transformation
Share on socials
ITSM Migration vs Transformation: Why switching platforms often fails to deliver value
Zoi Raskou
Published on 30 July 2026
14 min read
Zoi Raskou
Published on 30 July 2026
14 min read
This blog explores why a simple migration often replicates existing inefficiencies, and how a transformation-led approach often delivers lasting business value.
If you've grown frustrated with your current service management platform, you've likely already begun asking the question: what next? Perhaps the licensing costs have become difficult to justify. Perhaps the promised value from your CMDB never fully materialised. Maybe your teams are working around the tool rather than with it. Whatever the trigger, the decision in front of you isn't just about which platform to choose, it's about how you approach the change itself.
That choice matters more than most leaders realise. And getting it wrong is one of the most expensive mistakes an enterprise can make.
Why the instinct to migrate often falls short
When organisations decide to move away from a legacy ITSM platform, the natural instinct is to treat it as a technical exercise. You map your existing processes, find the equivalent features in the new tool, move the data across, retrain your teams, and switch the lights on. This is what's commonly called a "lift and shift" migration, which is the most common approach taken in enterprise ITSM transitions.
The appeal is understandable. Migration feels lower risk. It preserves what already exists, which keeps stakeholders comfortable and avoids the perceived friction of change management. On paper, it looks like a straightforward path from A to B.
But here's the problem: if your current platform isn't delivering value, the technology alone isn't what’s holding your organisation back. It's the processes running on top of it, the habits embedded around it, and the lack of organisational alignment beneath it. Migrating those same processes and habits into a new tool doesn't fix any of that. It simply reproduces your existing problems in a shinier environment, as well as introducing new unforeseen problems. This can be due to compatibility issue differences between source and target functionality or feature disparities. You've paid for a transformation, but delivered an incomplete or bad copy.
The result is predictable: within six to twelve months, teams are raising the same complaints. Adoption is still patchy. New frustrations emerge from the novelty of the new tool and the clunky functionality. Data visibility issues haven't gone away. And now you've spent a significant budget on a programme that hasn't moved the needle. Arguably, the needle has shifted negatively.
What does an ITSM transformation actually mean?
A service management transformation starts from a fundamentally different premise. Rather than asking "how do we replicate what we have in the new tool?", it asks "what does good service management look like for our organisation and how do we build it?"
The focus shifts from technology to outcomes, defining the future-state operating model, understanding how services should be delivered, and determining the experience the business and its users need. Only then should organisations consider how tools, processes, and automation can enable that vision. By starting with the desired business outcomes rather than the technical implementation, organisations avoid recreating existing inefficiencies in a new platform and instead create the foundations for long-term
This distinction might sound philosophical, but it has very practical consequences for how the programme is structured, who is involved, how long it takes, and what it ultimately achieves.
A transformation treats the platform move as an opportunity for a clean slate. Not to discard institutional knowledge, but to interrogate processes, workflows, and configurations that have accumulated over the years and ask whether it's genuinely serving the business. Many enterprise organisations discover that a significant proportion of their ITSM customisations exist not because of genuine business need, but because someone built them years ago to address edge cases or isolated problems, which eventually compounded. Those customisations carry maintenance overhead, make upgrades harder, and often obscure what ITIL best practice would naturally recommend.
Transformation addresses where businesses are today and design a path to bring them to where they want to be by cutting through accumulated complexity. It simplifies, standardises and modernises core ITSM processes, establishes a business-value-first approach that avoids the drift back into over-customisation, and critically sets the organisation up to take advantage of capabilities like AI and automation that require clean, structured data and consistent ways of working to function properly.
None of that happens automatically by switching platforms. It requires deliberate design, engaged stakeholders, and a structured approach to change.
The role of Organisational Change Management and why it's non-negotiable
Of all the elements that distinguish a transformation from a migration, none is more important than Organisational Change Management (OCM). It's also the element most commonly underestimated or skipped entirely in technology-led programmes.
OCM is more than a communications plan or a training schedule. It's the sustained, structured effort and culture shift to bring people along with the change, by communicating the vision and expected benefits - to build the trust, alignment, and capability that make adoption stick long after go-live.
In practice, this means engaging the right stakeholders at the right time. Establishing the reality of how work happens today and the desired outcomes in discovery sessions with the leaders. Holding steering groups to learn about the institutional knowledge and weave in elements of the tools and processes that work. Listening to the teams, their frustrations, their ideas, their needs.
Collaborating before configuration decisions are made and weaving their feedback into the solution, co-creating value. Finally, it's about iteratively creating a solution that focuses on what the business wants to achieve, and defining a path that secures the outcome and the solution's longevity and adoption.
The reason this matters so much is that ITSM platforms touch nearly everyone in an organisation. A change to how incidents are raised, how requests are fulfilled, or how changes are approved has implications for every team that relies on IT support, which is to say, every team. If the right people haven't been involved in shaping the new ways of working, they will resist them. And resistance in ITSM isn't just an inconvenience; it translates directly into poor adoption, workarounds, and data quality degradation that undermines the value of the entire investment. As well as the cost of delay and the effect a bad ITSM solution can have on the organisation's productivity as a whole. The resistance to transforming can also contribute to hidden costs, which are harder to measure. Companies ceasing the opportunity to modernise and innovate, stay ahead of the curve. The technology may be live, but the transformation has stalled, and the opportunity is missed.
The five integrated phases of a service management transformation
Understanding what a well-structured transformation looks like in practice helps illustrate why it produces different outcomes to a migration. At its core, a transformation programme moves through five distinct phases, with each building on the last.
Onboarding is where the foundation is established. This phase is about people before technology: identifying who the transformation will impact across the business, building trust through structured stakeholder engagement, forming steering groups with the right authority, and aligning on goals before any solution design begins. Organisations that skip this phase and go straight to platform configuration are building on sand. Without genuine alignment at leadership level, every design decision becomes a negotiation, and every go-live becomes a battle for adoption.
Design follows an iterative model centred on discovery. Rather than documenting what exists and rebuilding it elsewhere, the design phase interrogates current processes through decision sprints and structured workshops, where the team works through the choices that will define the new service management model. The goal is not to preserve legacy complexity but to arrive at a solution grounded in what the business actually needs, informed by ITIL best practice and the capabilities of the platform. This phase produces clear implementation requirements and a solution design that stakeholders have genuinely shaped.
Implement and validate takes an iterative approach to ensure the solution aligns with organisational goals. Configuration is built incrementally, tested through User Acceptance Testing cycles, and refined based on direct feedback. This is not a linear build-then-test sequence; it's a loop. Feedback informs changes that are retested before moving forward. The result is a platform configuration that has been validated by the people who will use it, not simply signed off by a project manager.
Empowering people is the phase that most migrations don't have a meaningful equivalent for. Rather than standard end-user training delivered in the week before go-live, this phase invests in building genuine capability inside the organisation through; role-based enablement, solution management training, and the kind of confidence-building that allows teams to own the platform rather than depend indefinitely on external support. This is the difference between a team that can evolve their service management model as needs change, and a team that raises a support ticket every time they need to adjust a workflow.
Benefits realisation closes the loop. A transformation programme should define success in measurable terms from the outset; productivity, cost, adoption rates, AI readiness, and then actively track and report against those metrics. This phase ensures that the investment made in the transformation translates into documented, visible outcomes that justify the approach and inform the next stage of evolution.
How to tell whether you need a migration or a transformation
Not every ITSM project requires a full transformation programme. If your current processes are well-designed, your data is clean, and the only thing that needs to change is the underlying technology, a more targeted migration may be appropriate. But in practice, that description fits very few large organisations. This also depends on the platform you’re moving to. Not all platforms are compatible for a direct transfer of data.
The honest diagnostic questions to ask are these:
Are your current processes genuinely fit for purpose, or have they accumulated workarounds and exceptions over the years? If your teams regularly go outside the tool to get work done, such as through email, spreadsheets, or informal channels, that's a signal that the process design isn't working, not just the platform.
Do your service management teams and the business teams they share a consistent understanding of what good looks like? If IT and the wider organisation have different expectations of service levels, response times, and fulfilment processes, a platform change alone won't close that gap, because the gap isn't technological.
Have your senior leaders aligned on what they want service management to achieve, not just in terms of cost reduction, but in terms of business outcomes? Transformation programmes succeed when they are driven by strategic intent. If the programme is owned only by IT and framed purely as a cost reduction exercise, it will be treated as one, and the broader organisational value will never be unlocked.
If the honest answers to these questions reveal underlying problems beyond the technology, a migration will not resolve them. A transformation will. The distinction is worth being clear-eyed about before committing to an approach. If you aren’t able to have an unbiased lens, it may be worth requesting a discovery consultation from a trusted solution partner.
The question isn't just where you're going but where do you want to be as an organisation?
The decision to move away from a legacy ITSM platform is one that increasing numbers of enterprise organisations are facing. The combination of rising costs, limited value realisation, and inaccessible AI functionality is pushing leaders to reassess whether their current investment is justified, and for many, the honest answer is that it isn't.
But the value of the next decision won't be determined by which platform you choose. It will be determined by how you approach the transition. A migration gets you onto a new platform. A transformation gets you to a better operating model that is simpler, more standardised, more aligned across the business, and genuinely positioned to take advantage of what modern service management makes possible.
If you're a senior leader evaluating your options, the most important question to bring to that conversation isn't "which tool should we move to?" It's "what kind of service management organisation do we want to be and are we prepared to build it properly?"
Written by
Principal Technical Consultant