Intro
Moving to a new ITSM tool?
This article is aimed at all users moving from an existing ITSM tool to a new ITSM tool.
If this is you, read on!
Before you start
Hopefully, you will have read our Tool Selection Tips, advice on Choosing the Right Toolset, our Implementation Considerations and advice on achieving an Out of the box implementation and arrived at an ITSM toolset that meets your needs.
Now you come to the point where you need to transition from your existing ITSM toolset to the new ITSM toolset. How do you do it? What should you think about?
This guide will hopefully give you some much needed advice ahead of moving to your new tool.
Key Considerations
The key considerations you need to think about are below.
Ticket Data (e.g. incidents, problems, requests, changes)
If you have an existing ITSM tool, you’ll have three types of tickets that you need to consider
- Old Tickets
Old tickets are resolved and closed, but do you want to keep them? I would advise against transition of old tickets from your existing ITSM tool to your new one. There are hidden complexities here that will suck up time and money, most notably the need to map ITSM tool fields from the old tool to the new one. Talk to your existing ITSM tool provider to ensure you understand how to extract the tickets into a database that you can query later. Sure, you’ll lose some historical data, but this issue is outweighed by having clean data in your tool - Aged Tickets
With open tickets, you have some choice over what you do with them, but once again, there is some hidden complexity here. Some of your open tickets might fall into the category of “Aged”. These are open tickets that have been sitting in your ITSM tool with little progress being made. With these, depending on the volume, you might want to decide to close any that are older than say, 3 months - In-flight Tickets
It is inevitable that at your go-live date, you are likely to have some tickets which are in progress. These can include:- Scheduled changes that haven’t yet been implemented
- Open requests that haven’t yet been fully fulfilled
- Open incidents that haven’t been resolved
- Open problems for which a workaround or root cause hasn’t yet been established
The approach you adopt for these tickets will depend upon a number of factors:
- The volume of open tickets
- How complex the workflow is
- How easy it might be to migrate them to the new tool in terms of mapping fields and workflow from the old tool to the new one
Depending upon the factors above, you might decide to:
- Migrate the tickets automatically
- Rekey the tickets manually
- Not migrate them and work with them in the old tool until they are closed
Knowledge Data
Where knowledge data is accurate and is being regularly used, this should be migrated to the ITSM tool. It is advisable to do some analysis of the use and accuracy of each article prior to migration. For example, the old articles on Windows 7 issues probably don’t need to be migrated!
Configuration Management Database (CMDB) Data
Next up, you should consider Asset and Configuration data. Every ITSM tool will contain some information on IT assets (hardware, software, etc) and potentially the relationships between these assets too. Deciding on what to do with this data will depend largely on its usefulness and data quality.
If the CMDB data is useful, accurate and largely complete, it would make sense to migrate this to your new tool. You will need to ensure that the existing attribute fields are mapped from the old tool to the new tool, to aid transition.
In terms of when to do this activity, this will depend on whether you adopt a big bang or phased implementation, which we discuss in more detail below. As a guiding principle, we would typically advise against maintaining two concurrent CMDBs in two different tools, as this introduces complexity and risk.
If your data is old, out-of-date and of questionable use, you may need to embark upon a CMDB design project, aimed at setting the objectives for what you want from the CMDB and deciding upon what CMDB content will meet your needs.
If you’re adopting a phased implementation approach, you’ll need to decide at which point the CMDB in the new tool becomes the prime CMDB, minimising the duration of any dual-running for the reasons outlined above.
If you’re adopting a big-bang approach, you’ll merely need to set a date and time when the transition will occur.
In either scenario, it is advisable to plan data migration activities and test your approach, to minimise any issues you might experience with, for example, slow data transfer speeds, or data migration errors.
Big bang or phased implementation
As mentioned above, you may need a period of dual-running if you have some open tickets to contend with.
A big-bang implementation allows for a clean go-live, which will be simpler to communicate and for stakeholders to understand.
A phased implementation may involve “swivel-chair” keying where you’re running two systems simultaneously, perhaps to allow for old tickets to reach the end of their workflow and naturally close. You may choose to migrate to the ITSM tool by ticket type, customer segment or specific IT service. Personally, I would suggest this a good option if you have lots of open tickets and is preferable to a large-scale ticket migration activity from your current tool to your new tool.
End-User Portal
It’s important to consider the end-user experience during ITSM tool transition. If the users currently use an ITSM tool portal for logging incidents, making requests and looking at knowledge articles. If you adopt a phased implementation approach, you’ll need to consider what to do about the end-user portal. As a general principle, giving end users two places to go for seeing ticket updates and logging new issues should be avoided.
A new ITSM tool gives the opportunity to improve the end-user experience, through the provision of a new portal, or refinement of an existing end-user portal. A new tool provides a great opportunity to drive adoption of the portal, thereby reducing manual effort and automating workflows for the provision of requestable items, logging of incidents or the provision of knowledge articles.
As you plan your cutover, make sure you’re also planning a coordinated communication and training program, so that your users are primed and maybe even excited to use the new portal.
Testing
We mentioned Testing briefly above, in the context of CMDB data migration. However, you must test any large-scale data migration, not only for CMDB data, but also for any ticket data. You’re likely to be dealing with large volumes of data, some of it in free-text format, and this can often result in unexpected issues of network bandwidth and data integrity. It is wise to develop a Test Strategy which defines what tests will be conducted, how, by whom and when. It will also describe the test outcomes that will be achieved and how these will be measured.
Existing tool configuration
We often encounter scenarios where clients ask for existing tool functionality or configuration features to be “migrated” from one tool to another. This represents a fundamental misunderstanding in terms of where talk of ITSM tool configuration should occur. Essentially, we’d advise against migration of any form of under-the-hood tool configuration. Your new tool will have been subject to many design meetings and it is here where you’d expect to have defined the requirements and configured these natively in the new tool. Migrating functionality and configuration is almost always impossible to achieve, so make sure you’re clear on the functionality you need in the new tool at the outset and get this configured as part of the setup.
Communication and training
Another factor that’s often overlooked is the need for effective stakeholder communications and training. The first step here is to identify the stakeholders who use the tool. Stakeholders will typically include end users, Service Desk agents, suppliers and IT support teams.
The next step will be to develop an underpinning communication and training plan.
The plan should incorporate, as a minimum, these items:
- Who is impacted?
- When will they be impacted?
- What are the key messages that you need to communicate?
- Where can users find supporting resources such as training? Will you operate a specific training program for each group?
- What will the training entail? Is there a minimum level of training required for each stakeholder group?
- How will you track training completion and ensure all impacted stakeholders are trained?
- How will you measure progress?
Training is vital in mitigating the risk of a loss of productivity and end-user engagement with the ITSM tool as you transition to the new tool. It is vital that everyone knows how to use the new tool ahead of go-live.
Adoption
Another key factor that is often overlooked is the need to drive adoption of the tool. ITSM tools have the potential to unlock amazing efficiency savings, but they rely on users fully exploiting the functionality within the tool.
For example, if you’re rolling out a new end-user portal for the logging of new requests and incidents, as well as the delivery of knowledge articles, you’ll need to ensure users not only understand the functionality that is available, but you may also need to drive adoption, perhaps through incentivisation.
Similarly, in the case of Knowledge Management, the functionality that enables you to serve knowledge articles via the user portal will be useless if no one provides any knowledge articles and users don’t know where to find that functionality.
Early life support
A final factor will be the availability of Early Life Support during the early stages of your ITSM tool implementation. The aim of this is to address any gaps in the knowledge of users of the tool, as well as to quickly identify and address any issues with functionality that have not been addressed during testing.
Conclusion
We really do hope that you’ve found the advice here useful. Please get in touch with us if you’d like to discuss your upcoming implementation. We can provide templates for the things we’ve discussed above, as well as resources to manage the whole process on your behalf.
