ITSM tool migration is inevitable. The IT service management (ITSM) tool landscape is constantly shifting. Products are sunsetted (Cherwell Service Management), licensing models change (Jira Data Center vs. Jira Cloud), companies merge and consolidate platforms, and organizations simply outgrow their ITSM tools. At some point, you’ll migrate ITSM tool, whether you planned to or not.
When that moment comes, having a data strategy and not just a list of ITSM tool feature requirements is what separates a smooth transition from a painful one – helping set you up for success and ultimately reducing the amount of time, effort, and risk required to migrate.
The Hidden Complexity of ITSM Data
I’ve had a lot of conversations with vendors, consultants, and practitioners and heard the same sentence fairly frequently: “Every one of these ITSM platforms can track tickets.” While this is true on the surface, it glosses over just how complex ITSM really is and the difficulties of ITSM tool migration.
Even a “simple” incident history is not just the incidents themselves, but the services and configuration items they impact, the notes and communications that occurred before resolution, any attachments that may have been collected, etc. Multiply that across all of the ITIL processes and practices, and you end up with a complicated web of data.
Additionally, each ITSM tool has its own way of storing “the same” information: Cherwell has business objects and specifics forms, Halo has ticket types, other tools have service categorizations hierarchies, and still others allow you to choose your own rules. Then, there is also how all this data is stored in databases behind the scenes and/or how (if) it is accessible via an API.
Three ITSM Tool Migration Strategies
There are potentially several ways to handle the migration of data from one ITSM tool to another (aside from the non-approach of simply not migrating anything over, which could be accomplished by either abandoning the data entirely or by exporting a backup and leaving it to collect dust until needed), but I’ll focus on three representative ITSM tool migration strategies illustrating the two extremes and then one that is essentially the best of both worlds.
Option 1: Full Historical Migration of the ITSM Tool
The first ITSM tool migration option is to copy everything from the old system to the new system. Every incident, every change, every problem, every asset, etc. And every related item. And every attachment.
Even if you decide to draw the line at only certain types of data, or to collapse the history into a single field, or drop attachments, this is still a monumental amount of data. The cost to migrate it all over – and ensure it copies successfully – is significant, as is the technical risk in ensuring that every field in ITSM tool A is mapped to a corresponding field in ITSM tool B, that every date is stored with the right time zone offset, and all your custom data gets transferred appropriately.
This option is expensive, risky, and ultimately results in a copy of the data that is almost, but not exactly like the original data. Additionally, it forces the design of your new ITSM tool to immediately be coupled to the decisions of the past solely to support data from the old ITSM tool.
Option 2: Migrating Only Active Work
At the other end of the ITSM tool migration spectrum, you could just migrate the incidents that are currently being worked on and resolved, the changes that haven’t yet been completed, any assets that are still active, and knowledge articles that aren’t retired. If your focus is on the items that are still in flight, it’s probably not a risk that the data that came across isn’t exactly the same data as was held in the old ITSM tool.
What is a risk is all the data you’re not copying across. What happens if you need to look up an incident from three years ago? What happens if you have an audit and need to review all the changes made in a given month? What if you have HR data in your ITSM enterprise service management (ESM) tool?
Option 3: Archive the Past, Migrate What Matters (Recommended)
What if you could have your cake and eat it, too? The ideal scenario would be to retain a full backup (archive) of your previous system (and use a tool like Synapse Software’s Cortex to keep it available, searchable, and browsable) and migrate a small fraction of your records to initialize your new ITSM platform with your organization’s current state.
In this way, you and your IT service desk don’t miss a beat: all of the work that’s currently in progress is still immediately available (just in a different system), but all of the old records are still available if needed and in a familiar format to satisfy even the most stringent data retention requirements.
Common ITSM Tool Migration Pitfalls
There are a few things to watch out for, no matter which data migration option you choose. Even if you archive everything (my recommendation) and also migrate the information that absolutely needs to come over to your new ITSM tool, there are some potential pitfalls:
Underestimating Data Volume
Both when planning disk space for your archive and when deciding which records to bring over, be sure to consider the implications of the volume of data. The size of your archive may influence whether you choose to archive it in a cloud storage service or on your local data center storage solution. When it comes to the volume of tickets to migrate, it’s a lot easier to spot-check a few dozen than a few hundred.
Ignoring Attachments and Record History
This is a sneaky one. During your ITSM tool migration, you might think that the most important aspect of the data is the current state and everything that is logged directly on the record, but don’t assume that’s always the case. Even if your process doesn’t include additional related items, it’s likely that any feature your old ITSM tool had was used in one way or another. Maintaining a full archive of the old data ensures that everything remains available even if you don’t migrate it all.
Breaking Reporting Continuity
You’re probably going to have to rebuild many different reports to work with your new ITSM tool, but what about reporting across the two systems, especially if your transition occurred in the middle of a reporting cycle? This may be a compelling argument for migrating many records, but you may only need the main record and not all its related information. However, it may also be feasible to use the archive to report on older periods and the new ITSM tool to report on newer periods.
Losing Compliance and Audit Data
Regardless of how large your company is and what industry you’re in, it is extremely likely that at least some of your data has to be retained for some period of time. Knowing what data falls into this category and how you need to access it (and prove that it’s the same data that was previously used to make decisions) is not something you want to leave to chance.
Over-Customizing the New ITSM Platform
If you’re going to migrate ITSM tool data, you need a place for the data to live. However, if you start customizing your new ITSM tool to match the requirements of your old ITSM tool, you’re immediately compromising to meet the design decisions (both good and bad) from the old ITSM tool, and you may even prevent yourself from being able to take advantage of the new opportunities offered by your new ITSM tool.
A Smarter Philosophy for ITSM Tool Migration
After helping dozens of companies switch systems, my advice to ITSM leaders is simple: treat ITSM tool migration as a data strategy project, not just a platform decision. Choose the right tool for your future without being constrained by your past. Archive the old, migrate what matters to the business, and start day one without bottlenecks on an ITSM tool built to help your team win.
Further Reading
Brian Parks
Brian Parks is the Founder and CEO of Synapse Software, the builders of Cortex, a platform for ITSM data archiving and automation used during migrations from platforms like Cherwell, ServiceNow, Ivanti, and Jira. Brian was formerly a Senior Software Engineer at Cherwell Software on their ITSM product.
