I don't normally chime in much, but I do want to point out a couple of things:
1) From a precautionary perspective, the article that John references speaks to what happens to the information in your records if you "downgrade", "upgrade", or "switch" the class. This is very important if you have information populated that you do not want to lose. Being familiar with the table/dictionary structure of where your classes/tables are extending from, and knowing what attributes belong to which tables will help you understand potentially which information could be lost when you change the classes. If you are not familiar with the tables and dictionaries for the cmdb_ci tables, then I would recommend spending a little study time here before you re-class
2) Also an example from my past. Last year I began supporting an instance that I wasn't around for during the original CMDB implementation and several years worth of item maintenance. During a review of the CMDB, I discovered I could not do a full export (XLS, CSV) of the CMDB like I was used to in the previous instance I was supporting. I also noticed that the CMDB pages would occasionally lock up when viewing all items. Where it locked up changed depending on which page of items I was on and how it was sorted.
What I discovered was that there were a couple of orphaned CI's. In this situation, ours were orphaned because the class they were associated to had been deleted. The item records were promoted up to the cmdb_ci table automatically, but the reference to the old class was still on the record. We could not access the CI records through the UI as the broken reference would cause the screen load to halt when accessing the record directly or through a list/report. After getting the sys_id for the items and determining that we had no Task (Inc, Prb, Chg, etc) or other transactional historical records associated to these items, with the assistance of HI support we were able to remove these orphaned CI records. This was complicated by having these orphaned CI's recreated with CI's of the same name.
If there had been INC/PRB/CHG records associated to these orphaned CI's when we deleted, then we would have now caused the referential issues John mentioned above, records referencing the CI that no longer exists. Remediation by re-associating to a valid CI would be needed to prevent undesired outcomes such as seeing a sys_id on a report or screen instead of a CI as expected. Task references are the biggest from an operational reporting perspective, but the clean-up could extend to other areas of the platform where the CI is referenced.
The lesson here is that if you decide to delete an unneeded class, ensure you have no items assigned to that class before doing so. ServiceNow does a good job of cascade deleting to help you keep clean references, but in this case the items were moved to the cmdb_ci table and not deleted, thereby introducing the orphaned reference. Also make sure whoever has delete rights on your CMDB has been trained and understands what they are doing before they delete items or classes
Daniel S.
