Migrating your current ITSM solution from an older version to a newer version can be an enormous challenge. As requirements and technology change, many organizations find themselves looking to update to a different software solution so they can meet their ITSM objectives. However, the challenge of changing your ITSM solution can be daunting and if not implemented correctly, it could be a career-ending project for decision makers. Bill Addenbrooke, a SE at LANDESK, recently worked as a services consultant for an ITSM solution provider. Bill has worked on several projects where an ITSM software solution was migrated to a completely different ITSM software solution. I recently sat down with Bill and asked him some questions about lessons learned and suggestions for successful migration.

What would you say is going to be an organization’s biggest challenge when they do an ITSM migration to a completely new solution?

“Making sure everyone buys into the new solution. It is important to get Help Desk feedback from all analysts who will use it. Your Service Desk is typically the tool used by all support groups.  Get their feedback on what would really make them happy or make their lives easier in terms of interface design and how to automatic assignments at different points. Remember, they are champions of the customers they support. They can offer great insight as to what would make their customers’ lives easier.”

For Incident Management (or helpdesk ticketing), what information is most important to export or replicate from the ITSM solution getting replaced?

“Incident Categories - These are critical from a reporting standpoint. If you need to know what’s happening/trending within your environment at any given time, this is often what people use.  It also helps to get customers one kick up on that ITIL maturity scale to being proactive about problem management.”

Does the migration consultant require the associated processes, if available, to be exported along with the Incident Categories?  

“I am a huge proponent of standardizing service delivery by means of a process, and most Service Management platforms stress the same thing if they're ITIL based. Standard Incidents and Requests are often assumed to have a good process behind them until the actual time comes to migrate them to a new system. Then once a consultant starts going through this with a customer, there's a lot of holes found. Typically, processes are rebuilt in the new ITSM solution, not imported.”

What is critical information that you need to migrate or, if not already available, configure in the new ITSM solution to get meaningful reports?

“User Data from AD, or eDirectory, or from an excel spreadsheet, or whatever your system of record is for your users.  This is paramount to getting good reporting out of whatever system you go with. Going forward in the new system, you have to understand that if the user data isn't good because it isn’t CONSISTENTLY getting filled out by the analyst, you're going to struggle to get good meaningful reports about what’s happening in your Service Management environment. You will never be able to accurately get a count on how many tickets per department, or how many people are actually affected by an outage etc. Plus it just makes your Help Desk staff lives easier if they can quickly get consistent accurate data.”

Do you have any suggestions as far as “DO's” and “DON'TS?”

“Rome wasn't built in a day. If you're handling Incident Management right now, don't attempt to go to a new system and do Problem, Change, and Request Management if you're not currently doing them. Rollout your ITSM solution to your users by using a phased approach instead of doing it all at one time. Trying to bite off too much at once is by far the most common mistake I see with a new implementation. Also, don't take away what customers are used to. For example, very often customers allow End Users to submit an email as a ticket. This usually makes analyst’s lives horrible because they've got to triage each one of those requests, and often it requires more information than the end user initially gave. It's a huge time sink and is frequently something organizations want to change going forward.  Even though we offer self-service tools to aid in that very scenario, which will over time replace the need for email request, taking away the option to email a ticket as you implement a new system does not bode well for the way a new system will be received.”

Finally, what can a customer do to reduce the cost of migration services?

“I have a spreadsheet I typically like to give out.”

Bill says, “Give the consultant as much as you can about incidents, process flow, service catalog, request management, and problem management. The costs can skyrocket when the consultant has to look for information that could have been shared prior to the onsite visit.”


After meeting with Bill, it was clear that when migrating to a different ITSM solution, it is critical to:

  • Involve your analysts as you plan and design the solution.
  • Take advantage of the opportunity to change the things they find to be hurdles, problems, or just simply annoying from the current ITSM solution.
  • Identify what is working and any improvements needed to existing processes.
  • Get your analysts’ advice when designing the user interfaces because they are the ones who will be using it every day.
  • To minimize costs, get as much information about your ITSM solution up front, then send it to your migration consultant before he/she comes on-site.

This article was originally posted on marcelshaw.com