ServiceNow® migration: What to do with the old ticket data

A brief overview from a large number of customer projects involving the introduction of ServiceNow. This article focuses on the handling of data and does not deal with the impact a new system can have on processes and the organization.

When new management systems are introduced, the question is almost always asked during the proposal phase. “What do we do with the old data?”. Do we leave it in the old system and not transfer it to the new system? Or do we transfer some or all of it, right down to the metadata?

Which data needs to be migrated?

Essential questions about the data from the old system should be answered:

1. Is there a contractual obligation to transfer it?If so, which one?
2. What benefits do we expect from the transfer?
3. Who must be able to access the data?
4. How must the data be accessed?

It is therefore not always just a question of budget, but also a question of contractual obligations and legal requirements as to which approach one chooses or even has to choose.

There are also reasons not to choose legacy data transfer. One of the main reasons is certainly to protect the budget. However, it is often overlooked that the old data may still serve as a “lookup” once it has been integrated into the new system.

Data import options

But what options do we have for the transfer?

1. Knowledge articles: Here the information is transferred to knowledge articles. Of course, an appropriate template is used here to maintain a uniform form, but this option is only practicable to a limited extent. In addition, these articles will probably rarely comply with the original visibility rules of the replaced system or the new standard rules. The historical progression can hardly be represented in such an article. This solution will therefore only serve as an internal lookup option and is unlikely to be used directly for customer inquiries.
2. Migration of data: A basic distinction must be made here between three types:
   • Header data and simple fields: Only the header data is transferred. If references can be easily resolved, these are gladly taken along, but the data is generally only transferred as simple string fields. No major adjustments are made here with regard to data access. Access is subject to the existing rules from the new system.
   • Maintaining the data structure: The aim here is to retain the files in their complete structure. This means that all references in the objects must be resolved (attachments, emails, locations, users, companies, assets, configuration items, products, contracts, etc.) and related to each other as they exist in the system to be replaced. The data is drawn as a comparison, but does not contain any change history or points in time.
   • Preservation of the change history and access rules: This is the most complex form of data transfer. It must be ensured that the original change times are also transferred so that the data appears in the new system like a clone of the old data. It should be noted here that complex mappings are often necessary, as values such as priority and comment types (internal comments, external comments, integration comments, etc.) are structured differently in the new system. In some replaced systems, there are far more than the two usual comment types in ServiceNow. Especially when it comes to self-built or highly customized systems.

Who has access to the migrated data?

If you migrate to a new enterprise service management system with standardized processes and authorizations, the data access authorizations do not always match the standard authorizations of the new system. If adjustments have to be made here because the standard authorizations in the new system are not sufficient, this can cause considerable effort depending on the complexity.

Which data is transferred?

Once you have decided to transfer data, in whatever form, it must be clarified whether all data should be transferred or whether there should be a selection of this data. Possible selections can, for example, relate to the status, a certain creation/resolution date or other selection criteria. The data type can also be a selection criterion. A possible decision could be that

• all incidents from the last 2 years

• all problems

• all changes for active CIs

• all customer tickets for active customers from the last 5 years

are taken over.

System integration and parallel legacy operation

With some system migrations, the legacy system remains in place. This can either be jumped to, which is a rather simple integration, or it is connected via interfaces and the data is integrated live into the new world, but this data remains in the legacy system and is not transferred. Initial costs are incurred for system integration, which depend on the depth of integration, and the costs for operating this system remain. Costs here can be operating costs (infrastructure, employees) and also any license and support costs.

As already mentioned at the beginning, the question of what to do with the data from the old system always arises. However, this question cannot be answered uniformly, as the framework conditions are rarely identical. Projects often show that if the data is also important for external parties (customers), a solution that is suitable for everyone must be ensured through data transfer/integration. This means that in the rarest of cases, all existing data is dispensed with and it depends on the type of data whether it is transferred.

Conclusion

Data from old tickets is often a wealth of knowledge, although not every ticket on its own represents a great deal of knowledge information. The questions mentioned above therefore form the basis for the choice of migration depth. It is always a mix of what “must” be migrated and what brings me the best “cost-benefit”. A critical question as to whether the data is really being used to the extent that is hoped for should always be asked. This is because the data quality in the old system is often not always “ideal” in order to really derive added value from the transfer.