Can you change the Hierarchy of CMDB Classes after they've already been created?

[Colin Wilson]

Imagine a class structure as follows:

• Config Item [cmdb_ci]
  • Facility Hardware [cmdb_ci_facility_hardware]
    • Furniture [u_cmdb_ci_facility_furniture]
      • Desk [u_cmdb_ci_facility_desk]
      • Table [u_cmdb_ci_facility_table]
      • Chair [u_cmdb_ci_facility_chair]
    • Lectern [u_cmdb_ci_lectern]
    • Podium [u_cmdb_ci_podiums]
    • HVAC [cmdb_ci_hvac]
  • Hardware [cmdb_ci_hardware]

Is there an OOB way to move the Lectern / Podium classes so they are underneath the furniture class? The lectern/podium tables were created way before and without much thought as to an organizational hierarchy for furniture type stuff.

For argument's sake, assume that Facility Hardware and all extending classes have no (or the same) custom added attributes, identification rules, reconciliation rules, or suggested relationships. 

[CMDB Whisperer · Accepted solution]

There is (or at least used to be) several ways to do this, though this functionality has been decremented bit by bit over the last several years.  At last check one method still worked (as of Orlando I think?), but only with custom classes.  And even when doing so, the reparenting was not captured in an update set, nor could it be manually added to an update set, so you had to do the reparenting separately in each instance.  And if there were any identically named fields in both class branches that were not inherited, this resulted in errors.  So, if you want to do it, hold your breath, cross your fingers, shake well before using, some assembly required.  Because of these I would not recommend doing this, even if it is still possible.  Rather I would suggest a low impact data migration approach.  Create a new class under the desired structure, and make sure it has all of the appropriate fields, and then simply reclassify the original CI to the new CI class.  Tip: as long as the field name of the field is exactly the same as the source field, the data will be retained when you change the class name to the new CI class.  Now your original CI will exist under a new table, but I believe it will retain the original sys_id value.  The only thing you will lose is the audit history, as those records don't get updated to the new table name.

[Erik26]

The best option create one field for u_cmdb_ci_facility_furniture maybe name filed purpose the type catalog and show three option Chair, Table and Desk

[CMDB Whisperer]

It's also worth asking why you are managing furniture as configuration items at all.  What are you going to be doing with these?  Would there be an incident entered against a chair?  Would someone want to submit a change request against a table?  And why are these extending Facility Hardware when they aren't really hardware?  Wondering if you might be better off just managing these as assets and not CIs.

[Colin Wilson]

*cough* uhh.... totally not because I forgot that was possible *cough*

so used to managing IT assets in which you have both. thanks for this advice, this is the actual solution but not specifically to the question. Your other response was very helpful also tho. 

Thanks!