Planning

Planning is an important part of moving from one software solution to another.

Switching ticketing / helpdesk / ITSM systems is a significant task that can affect business opertions for better or for worse. With correct planning and process, the transistion to a new system can be a smooth and successful one.

Get the vendor(s) involved

If possible, get the new vendor involved in the transistion from the legacy system. The vendor will have in-depth knowledge of their system, and has likely performed a similar migrations in the past. The vendor will have the knowledge, resources, experience and technical information to provide practical guidance to produce a positive outcome for your transition.

Furthermore, it may be advantageous to seek the assistance of the out-going vendor for matters such as database access, data export, technical information and configuration options.

Licensing and cost

As part of the switch to a new tool, ensure hat you understand the licensing and costs of the new system. Service Management software comes in many different options. Some vendors charge extra for functionality, or limit functionality depending on which tier of the product you purchase/subscribe to. Understand the licensing options also.

• Is it named licensing, concurrent, CALs, or a combination of these licensing options?
• Are the licenses perpetual, or subscription based?

If subscription based, what are the minimum/maximum terms? What does the renewal look like? How are new license/registration codes and renewals applied?

Ask all of these questions to the new vendor and really understand what you’re getting into. This will ensure that you can plan for, and anticipate costs, features, upgrades and functionality.

Define your requirements

Why are you moving systems? There is always a reason why a new system is being implemented. As part of this process, have a good understanding of why you’re switching, and what is going to be different. Some questions to ask:

• Why are we moving?
• What will be different?
• What things can we do better?

Have a plan!

Have a plan for moving to the new system. Include things like:

• Testing
• Gap analysis
• System owner and Key stakeholders
• How are we going to communicate the changes to stakeholders?
• Configuration of the new system
• Import data, or start from scratch?
• Pilot program
• Go live date
• Training
• What to do with the old system? Keep it live for some time, de-commission, or something else?

Feature Gap Analysis

All software is different. Don’t assume that just because your old system had a feature, or a concept, that the new software will have the same thing, or support it in some way. The reality is, all software has strengths and weaknesses, and just because you’re moving to a new system, doesn’t necessisarily mean that you’ll have parity on all features and functionality that you’re used to.

Make a honest list of what you need, what you can live with, and without. Discuss any functionality gaps with the new vendor and discuss the product roadmap.

Communicate your findings to your team and provide training for them.

Data import?…or manually enter data?

When migrating from one tool to another, at some point you will no-doubt be thinking…“Should we manually input new settings and configuration, or import the data somehow?” Depending on the new tool, it may have some form of data import available for some of the more common data structures / entity types.

Remember that not all structures and data from both systems can be exported and/or imported. Expect to learn about the various entity types and prepare to simply do some data-entry at some point.

See Exporting Data from your old system

See Importing Data into HelpMaster

Seek feedback and involve the team

Migrating to a new tool takes time. Throughout this time, consider involving key stakeholders into the process. Seek their feedback, communicate intentions, configuration concepts and ideas, processes and workflow and timelines.

Run a pilot program to gether initial feedback, performance and usability notes.

Document the new system and processes

Use this opportunity to create (or update/refresh) any documentation you may have about your service desk, processes, operations, system codes, or any other artifact that help you deliver service to your clients. Keeping up-to-date documentation will not only clarify where you are, but also serve as a reference point for on-going configuration, on-boarding new staff as well as providing a running commentary on how your business operates. This information will become invaluable as part of on-going continuous service improvement.

Use the opportunity to fix things

A new system gives you the opportunity and excuse to fix things that were never right in the previous system. In addition to the big configuration items and workflow/process, consider things like:

• Colour consistency in stylesheets and graphics used for the web portal
• Redesign and re-write email templates for better user communication
• Refresh Knowledge articles
• Tweak automation / SLA notices
• Look for better ways of achieving things - perhaps the new software has new options

Assign someone to “own” the system

Ticketing and workflow systems require on-going maintenance in terms of configuration, updates, upgrades, tweaks and adjustments along the way. On-going mapping of business processes into software workflow also requires a keen focus on both the business operations and how these can be mapped into the software.

Without a dedicated person, or persons to keep an eye on the business and how the software is supporting the business, there is a risk that the software configuration will become stale, and fall into disuse.

A system owner should also have a good relationship with the vendor, and seek their input on configuration, upgrades, sales, bugs and feature requests.

System Codes

All service management software relies heavily on the configuration of system codes (think Priority, Status, Classification, Summary codes, Asset types etc.). These codes are used as meta-data to define things like Incidents, Problems, Changes, Assets, Tickets, Call types etc.

When transistioning to a new system, don’t just re-implement the same configuration you’ve used in the previous system, but instead look objectively at the effectiveness of the old system. Were the codes used? Are there duplicates, or redundancies?

Can things be improved? Has the business changed and new models and taxonomies required?

Do we really need 6 priority codes? Do we really need a 7-level deep classification hierarchy!?

The point is…don’t just re-implement the same system codes.

Use this opportunity to analyse your requirements and start afresh with an optimised configuration. By all means, re-implement what worked in the old system, but look for ways to refine and optimise the configuration going forward. Often, when a ticketing solution is configured for the first time in an organization, there may be an element of “over engineering” of the system codes, which can reduce effectiveness, cause analysis paralysis, and diminish reporting and automation opportunities.

Commuinicate and market the new platform

Let staff and clients know what it happening. Start early. Let people know that you’re improving your processes and service delivery and will be implementing a new system.

Training and education

Adoption to a new platform relies on the success of whether people understand it, can use it and feel that it offers value. Use training and education to do this.

Logging onto the web portal

• Different mechanisms for logging on. Username/Password vs Microsoft Authentication vs SSO

Logging tickets Viewing and updating tickets Browsing the Knowledge Base Providing feedback Approvals Service Level Agreements Emailing the Service Desk Auto-responders