Solomon Gifford, the Senior Director of Product Development at Contegix provides a first-hand account of his first ITSM migration: the challenges and lessons learned:
I remember my first ITSM migration – we were using a very specialized ticketing system and had decided to migrate to a leading tool in Gartner’s magic quadrant for ITSM tools (ServiceNow, BMC, Ivanti, Freshworks, and Atlassian as of 2021). Each time we tried to explain our processes, the ITSM migration partner reverted to explaining how the new ITSM tool worked “Out Of The Box” (OOTB). My team and I began texting each other pictures of boxes each time the OOTB phrase was used – a work-safe alternative to a drinking game.
While the OOTB turn of phrase is intended as a metaphor for pre-packaged value, it also carries the connotation of entrapment. I’ve now served as the technical lead on two ITSM migrations and a principal advisor on a third, and the cute box memes didn’t absolve those negative connotations. Worse, unfortunately, the ITSM migration partners I was asked to work with extended the OOTB metaphor to their processes as well.
To use a shipping analogy, major shipping carriers provide a service of selling boxes and the relocation of those boxes. However, as a consumer, what I may need is some expensive fragile heirloom delivered to my sibling. The important details, like what packing material to use or the size of the box to purchase is left up to me; however, those details could very well be the difference between a successful delivery and an immeasurable loss.
My expectations when working with an ITSM migration partner has been to help me choose boxes of functionality and guide me to which features to pack into each box. However, in all three of my experiences, the integration partner has spent more time focusing on their boxes than on what I’m putting in the box.
In all three experiences, the projects had cost overruns and didn’t deliver the expected business values, and yet I felt helpless because the mistakes had already been made contractually.
The general process I’ve seen goes as follows. First, business leaders (for example the C-suite) are sold on the value the ITSM tool and negotiate the initial migration and license costs. The project is then delegated to an implementation team that manages an unrealistically low budget in a compressed timeline. Finally, after go-live, the operations team is provided what is essentially an MVP with no budget to achieve business value parity with the former ITSM tool.
I’ll cover more of those individual phases in my recommendations below, but in all three situations, the primary culprit was the initial process assumptions, not the timeline or budget. It is my hope that the recommendations below will lead you to a successful ITSM migration.
Identify an Internal Technical Lead Before Contract Signature
Business leaders are focused on business objectives, not implementation details. And they should be – their vision is what ushers change to drive efficiencies and maximize business value. However, and I say this with the utmost respect, they are often so far removed from the implementation details that their ability to communicate the scope of any migration is hampered.
Your internal technical lead cares about the details of your processes. Does the ITSM tool integrate with System X? Can it support workflows Y and Z? How does the licensing work if you have a user that only needs access to features A and B? What special exceptions or overrides have you implemented in your old tool that you will need to account for? What data flows are coming from external sources? What data is important? What data is changing when its migrated? What processes are new or are changing in the new tool?
Identifying this internal technical lead early in the process and having that person part of the early estimation efforts is integral to a successful outcome. While business leaders drive business value, the internal technical lead will represent the details and provide project continuity when you enter the implementation phase.
The internal technical lead may be the admin currently managing the “old” ITSM tool, or it may be that employee who knows where all the technical bodies are buried (to borrow the expression). They could also be a “Process Engineer” or a hands-on operations lead.
Avoid the temptation to appoint a non-technical project manager as the internal technical lead. That is a very different, and yet still important, role. A project manager will not be able to take technical ownership of the implementation – just the schedule and costs.
So what should you do if you don’t have an internal technical lead? The good news is that you can still be successful. You still want to designate someone as the internal lead to provide a primary point of contact, but a future recommendation (Demand an Agile (Iterative) Implementation) is going to be extremely important.
And on another note – if you are doing a consolidation of multiple tools into your new ITSM tool, it will likely be prudent to identify an internal technical representative for each of the source tools unless your internal technical lead has sufficient knowledge of each.
Demand a Scoping Engagement Before Committing to Migration
A good ITSM migration partner will recommend a paid scoping engagement before providing any estimates beyond “t-shirt” sizes. This is your first sign of a good partner. Otherwise, the ITSM migration partner is incentivized to lowball the estimate. They know if the budget runs over, you’ll be faced with a difficult decision to go live in an unusable state or pay more, and more often than not, you’ll just be forced to choose to pay more.
Until your ITSM partner has a good idea of the scope of the migration, they will be unable to estimate accurately. But here’s the good news – the majority of the cost of the scoping engagement can be applied to the migration. The high-level requirements gathering process doesn’t need to be done twice and can provide the roadmap for the rest of the project.
And tying this to my first recommendation (Identify an Internal Technical Lead Before Contract Signature), make sure to bring your internal technical lead to the scoping engagement. You want to uncover the details, not rush past them. Remember, the point is to get a realistic estimate.
If you can’t estimate based on a scoping engagement, assume a 50% cost increase before go-live and an additional 25% increase after go-live. If you negotiated hard during initial negotiations, these numbers may even be farther off. These are rough numbers based on my experience, but they have been surprisingly consistent.
Invest in Upfront Power User Training
There are two critical moments in an ITSM migration where the knowledge gap is most apparent. The first is during initial requirements gathering, and the second is right after go-live. I’ll address each of these separately.
Imagine for a minute that I was selling you a Stunningque and wanted to know whether you wanted to choose a flowpossible or a flowchoice? The worst thing you could do is actually choose one (you won’t find those words in a google search)! The problem is that you don’t know the vocabulary of a Stunningque.
Think through what happens in a typical ITSM Migration – a very small group of business leaders and an internal technical lead (assuming you’ve taken my recommendation to Identify an Internal Technical Lead Before Contract Signature) demo the ITSM product and capture the vision of the possible – then the ITSM migration partner begins interviewing your team members who have never even seen the tool, don’t know how it works, and don’t know the vocabulary. Even if some on your team have some experience, its likely not enough to choose between a flowpossible and a flowchoice.
You do not want your team telling the ITSM partner what they need until they know what is possible. Your ITSM migration partner and your team don’t have the same lingua franca. Both teams know different sets of terms and deal with different constraints and capabilities in the respective ITSM applications.
I’ll be honest, I’ve not seen many ITSM migration partners offer a solution to this problem, but what you need is a training that is a cross between a demo and admin training – or what I would call Power User Training. I’ve seen ITSM migration partners offer to do admin training up front, but admin training assumes you know the tool and want to master the configuration. How much will your team retain if they don’t even know the vocabulary and basic process model first?
What your team needs to know is how the tool works, what is possible, and what is the vocabulary. This will help your team start forming a mental model and the lingua franca to bridge the communication divide.
Demand an Agile (Iterative) Implementation
The typical ITSM migration process I’ve seen is roughly Requirements Definition->Implementation & Migration-> User Acceptance Testing (UAT) -> Go Live. I find it exceptionally ironic that so many ITSM migrations use a “waterfall” process to implement a tool that is sold as more “agile.” This process, however, is rife with pitfalls.
Firstly, a waterfall model starts with creating a functional requirements document (FRD). The problem with an FRD is that it doesn’t capture business value objectives. You may want “an easy way to escalate” but the FRD captures “field checkbox on issue type y.” Your ITSM partner will disappear for a period of time, only to re-emerge with a solution that fits the FRD but does not reflect the business needs. Your ITSM migration partner can deliver the checkbox without the business value and be contractually covered. With one of the ITSM migrations I was a part of, the FRD was accomplished but we couldn’t even save tickets or advance them. An FRD is a perfect opportunity for the ITSM partner to demand a project scope change with a budget increase.
Secondly, like the reasoning in my recommendation to Invest in Up Front Power User Training, until your team knows how something works in the new tool, they will not be able to communicate what is needed. An Agile (iterative) process allows that quick feedback loop, such that each iteration is not only providing value, but your team is also getting more comfortable with using the tool, meaning they will know what to ask for and how to communicate their needs.
The Agile process also means that you can prioritize items identified in the initial scoping engagement (assuming you’ve taken my recommendation to Demand a Scoping Engagement Before Committing to Migration) and deliver value early. In some instances, you may be able to migrate some teams, tools, or processes early and actually get them live before project completion. This allows your team to gain that experience of using the ITSM tool in a real-world scenario and gain the experience necessary to inform later stages.
However, even with a monolithic go-live, you do not want to get to the go-live date with 40% of items half-baked and 60% under-tested. In a typical waterfall model, user acceptance testing (UAT) is a short period where your team must drop all other responsibilities and fully test during that concentrated window. More realistically, your team doesn’t have the operational capacity to set aside that type of time commitment and the tool will go live under-tested and without sufficient support. Even if you discover issues during this late-stage UAT, as the go-live cutover date approaches, you will likely have to drop requirements to keep to the timeline and minimize ballooning costs.
Instead, UAT should be immediate after implementation of that component. I wouldn’t even wait as long as two-week sprints – instead opting for iterative cycles once or twice a week. This may feel like a large time commitment on your part, but by combining requirements elicitation with UAT in an iterative process your team builds confidence and your ITSM partner provides value quickly – and with a short iterative cycle (3-5 days) you can quickly track progress towards the budget goals.
Empower with Go-Live Training
So you’re ready to go live and your migration team is about to flip the switch – is your operations team ready? Probably not – they have their day jobs, and despite being potentially asked to test the new ITSM tool, the majority did not. The worst thing that can happen at this stage is that they stumble into the tool, use it incorrectly, and you now have data to clean up and complaining customers.
Avoid the temptation to train too early. Your users will forget the training, and they will receive early training on a more generic out of the box implementation, not the actual instance you expect them to use, so the experience will be different.
Instead, this training should be within days before go-live and should be a joint presentation between your operations leaders/trainers and your ITSM migration partner. Your team leader’s role in this training is to provide the “what” and your ITSM migration partner’s role is to provide the “how.” It can be led by either team, but it’s a combination of policy provided by you (“never escalate a ticket without reading it first”) and your ITSM migration partner (“to escalate a ticket, push this big red button”).
Also expect a second training within a week or two after go-live. At this point, your operations team has used the tool enough to have real-world questions. Prepare to take a lot of notes on “wouldn’t it be nice if” or “I wish I could” – this is why my next recommendation on Budget Resources to Realize Business Value is so important – your team in the early stages of the tool will be full of excitement to take advantage of all the promised value. You want to take advantage of that early excitement before it turns to nostalgia for your old tool.
I also recommend recording your go-live trainings for future employees. Yes, it may feel more like a Q+A at points than a real training, but until you’ve stabilized processes you will not want to develop internal training. In the meantime; however, future employees still need training.
Budget Resources to Realize Business Value
A tool doesn’t provide business value. Using the right tool efficiently provides business value. Too often business leaders budget for the cost of a license and migration but do not budget to actually realize business value. The tool you are migrating from has years of tweaks and process changes that, despite its deficiencies, your operations team has learned to use in the most efficient way possible.
Migrating away from that tool will cause your operations team to lose those efficiencies. Without dedicated budgeted resources to reach parity or to realize additional business value, your operations team will be saddled with a tool that, despite its promises, fails to meet expectations. A migration does not achieve parity, instead it is a minimal viable product (MVP) which defines acceptable data loss and minimal process parity.
Buying a fancy tool and then not investing in maximizing its potential is like riding in the trunk of a limousine. Great product. Lousy experience. The software vendor is focused on selling a license and training, but unless your business has unutilized staff, sending a few “admins” to training is insufficient to realize business value. Training is not enough - you need to budget either internal or external hours on a recurring basis to focus on achieving the software’s potential.
In my experience, a rough gauge is about ½ hour of configuration per agent per month, double that the second 3 months, and quadruple that the first 3 months after go-live. This cost is often overlooked when budgeting the running costs of the tool, but remember, the reason you decided to implement the ITSM tool is to achieve a business value.
ITSM Migration Conclusions - Putting it all together
I think too often ITSM migration projects forget the ultimate goal of driving business value and instead get sidetracked by the finances of overlapping software licensing. (Hint: don’t buy all the licenses you need until the migration is complete or use trial licenses when available!). Yes, license costs are often a driving factor, but remember the goal is not the ITSM software – it’s the business values and efficiencies that come from using the ITSM software.
Going back to the box analogy we started with at the beginning, most of the recommendations I’ve made don’t change the box. The ITSM software still has its OOTB default configuration. But enabling your team to make the right decisions is in the spirit of the idiom, “an ounce of prevention is worth a pound of cure.”
A good ITSM migration partner will both want to empower you to make good decisions and at same time want to understand your actual processes. Questions like “do you want a checkbox” or “do you want a field” are very different than “What types of things do you want to keep track of, and how do you use those pieces of information?” Maybe the recommendation will be to combine multiple binary choices into a multiselect or design an exception to a process instead of creating two processes.
Ultimately, remember the goal – you want to drive efficiency and use the tool to gain competitive market advantage. You can't do that while riding in the trunk of a limousine! So invest in your process so you can plan for success.