Changing the Class of an Existing CI

[Nia McCash]

How does ServiceNow handle a Configuration Item (CI) class change?  I see that this is possible but I'm not sure what the logic and the rules are when this happens.  For example, it seems that fields (including data) that exist in the previous class get dropped/deleted when the CI is changed to a new class that does not have those fields. Is there any way to intercept this process to add custom mappings?

Are there any other considerations I should keep in mind in changing a CI class?

Are there recommended best practices on how CI class changes should be handled? Or, is it generally a bad idea and should be avoided?

[Steve McCarty]

My immediate reaction is that it is generally a bad idea to change CI classes.  Each CI class sits in a separate table, they all extend from the same base, but they are separate.  So to change the class you are essentially deleting the record from the old table and adding in a record on the new one.  You could create some business rules or scripts to move data from one to the other, but you would lose any references to the old CI in other tables.  That would include any task based table like incident, problem, change, service catalog requests, security incidents, or any custom built tasks in your instance.  It can also create problems if you use asset management.  Each CI that is in a class that ties to an asset model category, has a one to one relationship between asset and CI.  If you change the CI class you could break that relationship and lose the purchase information and other financial info on the asset record.

Are there specific CIs you are trying to move from one class to another?

[Nia McCash]

When I tried changing a CI class in my personal dev instance (I do this from list view by double clicking and editing the class field/column), I noticed that the sys_id is preserved and therefore references to the record should be preserved - which is great.

In my case, there is no asset tied to the CI but I can imagine why that might be an issue and will test. 

We have an urgent need to get an equipment reservation system in place in the platform but don't have the time to model the equipment appropriately in the system.  For now, it would be enough to have a CI record with a name (and no other attributes) that we can begin associating with tasks and other records.  

I was thinking of creating the CI as a cmdb_ci generic item in the hopes that it can later be converted to the appropriate CI class once we have the time to consider the other attributes we may need. 

If anyone has further advice on the matter, we'd really appreciate it.

[Nia McCash · Accepted solution]

Should have looked at the documentation before I asked this. Looks like this is a 'supported' action and there is useful documentation at these resources: 

• https://docs.servicenow.com/bundle/kingston-servicenow-platform/page/product/configuration-managemen...
• https://hi.service-now.com/kb_view.do?sysparm_article=KB0689637&linkId=53678269

If anyone has any experience, gotchas, or any other info they'd like to share on the matter, please feel free to continue to reply to the post.

[VaranAwesomenow]

Thanks Nia for the post.