Service desk systems are of great importance to most IT departments. They are used to manage not only incidents and service requests, but also for authorizations and the management of internal projects. Moreover, data obtained from an ITSM system can be used for time accounting, invoicing and cost estimates. Finally, yet importantly, tickets and their metadata build a structured and searchable request history and knowledge base.
In the event a ticketing system needs to be merged with another system or has to be completely shut down, it is important that this precious data be preserved.
There are different import strategies we can follow depending on the source system of the tickets that need to be imported and the data that needs to be retrievable after the migration. Furthermore, we can think of this as an opportunity, where we can clean up data and properly map ticket properties (i.e. a new service catalog with a new mapping of services, categories, ticket types or a completely new organizational structure containing new queues and roles).
Available export and import scripts that work directly at the database level (and hence can execute large migrations in limited time) can best perform the ticket migration from another instance of OTRS or EriZone to the latest version of EriZone. The entire ticket history, all articles, attachments, dynamics fields, etc. can all be migrated and a mapping of the tickets to new services, queues, and ticket types is possible. In case of an upgrade from an older OTRS version, this type of migration reduces service downtime and facilitates the testing and configuration of the target system.
We can use the function BulkImportTickets to import tickets from other systems and data sources. Using the EriZone API, we can import ticket lists (exported as CSV files) directly into the system. These csv files should only contain the ticket with the initial customer request. Additional ticket follow-ups (agent responses, customer responses and internal notes) need to be provided in an additional table. To allow a correct assignment, the original customers and agents need to exist in the target system. If the import files are not provided as a list, but have a different, more complex structure, i.e. structured XML or JSON, then we may need to develop customer-specific import filters.
An alternative method since EriZone 5 is the usage of the Generic Interface to export and/or import the ticket data via REST calls. Here, data extraction depends on the REST interface provided by the source system. For systems based on OTRS, so-called connectors are available that allow for a direct connection with EriZone to import the data. Imports from other systems into EriZone via the REST API can be performed with a single HTTP call per ticket.