Need help in reclassifying of CI records in ServiceNow CMDB

[Swarnarghya]

There is custom CI class that got extended from cmdb_ci table. In that custom ci class there are 6 additional attributes. There are around 5.5k records existing in that custom ci class table.

Now I need to move all the CI records from the custom table to one OOB table so that there is no data loss happening at the field level. All the fields are properly mapped. What is the best practice to achieve this?

Do you suggest create similar attributes and do excel data load or is there any other suggestions.

[CMDB Whisperer · Accepted solution]

There are a few approaches you could consider:

1) If the data is to be moved without any field transformation, you can simply ensure that the target CI class has exactly the same attributes (same column name, e.g. u_custom_field_1) defined with the same or greater field size so no strings are truncated.  Then simply modify the sys_class_name to the desired target CI class name (e.g. in a Background Script or Fix Scrip), and voila, all of your data is moved to the new CI class, and all of your references to those CIs are kept intact.  NOTE: It doesn't actually matter if the target attributes are cloned from the same parent element, so long as the column name is exactly the same!

2) If you need to transform your data (e.g. move from a custom attribute to an OOB attribute, change the data type, etc.) then you can script the transform using a Fix Script.  In the Fix Script you can basically follow the same steps as in step 1, but include the necessary steps to transform the relevant fields and values according to the target class.  As before, it's generally best to keep the existing record and just change its sys_class_name attribute so that any references to the CIs are retained.

3)  If you have a particularly hairy situation and you don't care about maintaining any reference data, in theory you could populate a staging table (Import Set) and run it through a Transform Map.  This would create new CIs to replace the old ones.  It would give you the most flexibility in terms of ability to transform the data.  However, this is an edge case, and 99.9% of the time you won't need to use it, and this approach would be considered overkill.  But I've seen it done a handful of times.

I would recommend starting with option 1 and see if it works for you, and then option 2 if needed.  Make sure you test everything in a non-Production environment and validate the data before moving your Fix Script into Production.