Should we migrate old tickets to the new ITSM tool
By ITIL® from Experience©
Migrating historical data from a legacy ticket1 system to a new ITSM tool changes the scope and effort of the project. For ITSM tools, the value of importing tickets data is usually not worth the cost and effort.
Data migration includes:
- Mapping fields between the two tools
- Deciding if all the data must be imported
- Figuring out what to do with the data when the new tool:
- Does not have an appropriate field to receive the data (e.g. discard the data, re-purpose a field or concatenate the data in another)
- Has fields that are shorter than in the old system (e.g. truncate data, search & replace common words with abbreviations)
- Has field types and format that does not support the old data (e.g. numeric, date format)
- Cannot support special characters contained in the data
- Preparing and testing scripts that:
- Extract and reformat the data for the new tool
- Import data in the new tool.
The classification and categorization of tickets also needs to be considered. First, the legacy system may not distinguish between an incident, a service request, a Request For Change (RFC) or a problem as it might simply log “tickets.” Secondly, re-using the existing categories may not be straight forward since the new tool might use a hierarchical taxonomy2 . Moreover, importing the old categories may perpetuate issues of the legacy system (see How many categories do we need).
The ticket's record structure must also be considered. For example, work notes in the legacy system might be appended to a single text field in the ticket. While in the new tool each work note might be a separate record of the ticket. In this case, each historical work note could be parsed as separate entries or it could be imported as one entry in the new tool (as long as the new field is large enough to accommodate the data). Alternatively, old tickets can be printed to a PDF and attached to a newly created ticket in the new tool with basic information; however this might limit the ability to easily search records.
The partially completed work needs to be assessed and planned accordingly for a smooth transition. Scheduled service events like scheduled onsite support visits or training sessions and process delays can be a challenge such as reminder to contact the client when their borrowed equipment is overdue to be returned. Moreover, when the legacy tool has a workflow-engine3 partially completed workflows processes need to be carefully planned.
Regardless of these technical issues, the key question is: What is the value of migrating this data?
From our experience people and especially the Service Desk want access to the old data to4 :
- Produce reports;
- Search for past resolutions (i.e. knowledge base);
- Access asset information contained in purchase requests (e.g. license key, warranty) and, of course to;
- Process tickets that will be open when the new tool goes live.
Migrating the data to meet these needs has challenges and costs.
Regarding reports, it is important to realize that existing reports will need to be adjusted for the new tool field names and classification. Given that the new tool usually has more data available than the older tool, like SLA metrics, reports will evolve over time as the new tool capabilities are understood. In addition, by re-enabling old reports risks perpetuating the current service management practices. Some people may also be concerned about the production of the annual report if the data is not migrated. However, management usually understands that, for the first year, the annual report will need to be assembled from two sources and that the accuracy of year-over-year comparison will suffer due to changes in the ticket classification and reporting methods.
It is important to realize that the value of the information contained in past tickets erodes over time as the organization replaces its configuration items (e.g. life cycle). Of course some claim the need to search for past resolutions or asset information. However, when asked the last time they did so, people often answer that they might need to do so or that the information will be needed when they get to implementing pro-active Problem Management.
As for open and incomplete tickets, easier methods are available than to migrate legacy data to the new ITSM tool. These will be discussed in a future article.
From experience, all concerns and needs can be addressed by keeping the legacy system or its database available as read-only for a pre-determined period of time. Moreover, the usefulness of transaction data is finite. Accordingly, some organizations have an Information Management policy whereby transaction data is kept for two years after their completion. Even records of assets have a defined usefulness where in some jurisdictions, asset records must be kept for six years after the asset’s disposal.
In closing, migrating old data in the new ITSM tool may carry over the organization's poor service management practices.
Last updated on: 2017-06-19
Published on: 2015-06-01
"Because it can be done, does not mean it should be done. Make sure that the ITSM technology does not outpace the process & people's capabilities and level of maturity." Denis Matte
Related:
- How to ensure that applications and servers are decommissioned
- Who is responsible to administer the ITSM Tool after it goes live
- How to track issues and enhancements users have with the ITSM tool once it goes live
- Do people need training if the ITSM tool is easy to learn
From Around the Web:
• Data Migration http://www.infotechnet.org/ntca/DataMigration.htm
Category:
Implementation > Project Management
Implementation > Technology (ITSM Tools)
Copyright 2015 - 2017 ITIL® from Experience© - D.Matte