Dealing with Open Incidents when migrating to CSDM tables

[Peter Oettle]

I am looking for best practice/previous experience with migrating Incidents from using the legacy Business Service table to using CSDM tables. In particular, I am interested in how to deal with open Incidents at the time of cutover.

Brief description: customer currently references cmdb_ci_service table in Incidents and there is much automation in place, which uses fields from the referenced cmdb_ci_service record. After moving to CSDM, the Incidents will reference the cmdb_ci_service_offering table instead. An impact analysis has been done and plans are in place to migrate the automation from using cmdb_ci_service in the Incident to using cmdb_ci_service_offering.

We dont expect issues with new Incidents after cutover, however open Incidents at the time of cutover will have been using legacy table data, which will now not be available and some Incidents may get "stuck" due to automation/flows not working.

[Kev12]

We have done many of these transformational pieces for clients of all sizes. I am not sure a 'good' practice or recommendation exists. It does depend on many factors within the company itself. But usually I see it being a three horse race.
1. The organisation decides to implement a hard stop on the old method and records are rekeyed where necessary.

2. Records are preserved, along with reference data and all associated sys_ids so that they can be refactored into new method using old sys_ids.

3. Servicenow and/or the data is manipulated and configured to co-host both old and new methods/data for a limited time.

All 3 options have good and bad characteristics for the target organisation. It needs to be an open discussion and agreement about what data is 'preserved' and at what cost and effort.

Hope that helps. Kev.