Data loss or performance issues might occur when changing the class of a configuration item or reclassifying a configuration item.


Current versions and patches.

Issue Details

Issues can occur if you change the Class Name [sys_class_name] for certain CIs in the CMDB (for example, cmdb_ci_linux_server to cmdb_ci_solaris_server


Note the following important things to know when running this task:
  • If you change the Class of a CI, you might lose some field data that does not exist on the target table. For example, a Linux server has a field called Kernel Release that does not exist on the Solaris server table. If you change a CI from cmdb_ci_linux_server to cmdb_ci_solaris_server, any data in this Kernel Release field will be lost. You need to be aware of and account for issues like this before you make this sort of change.

  • If you perform the Class change from the UI, due to Transaction Quota limits [sysrule_quota], the transaction might get canceled, which could lead to a loss of data.


  1. Choose a limited number of CIs to change the class in each step. (~20 to 40 CIs)

  2. Write a scheduled job [sysauto_script] and properly fill in and execute the following script as an admin.

    Sample code:

    function ChangeCIClass() {
    var lv_limit = 40; // We can have some restricted values like 20-40
    var lv_temp = 1;

    var gr = new GlideRecord('<<old_ci_class_name>>'); // Must not be cmdb or cmdb_ci
    gr.addEncodedQuery("<<custom_query>>"); // Your query that gives you the records for which you wanted to change the class.
    while( && gr.isValidRecord() && lv_temp &lt; lv_limit) {
    gr.sys_class_name = 'new_class_name';


Additional Information

For more information about transaction quota rules, see the following product documentation topics:

For more information about changing classes, see the product documentation topic Reclassify a CI.

Article Information

Last Updated:2019-08-30 02:22:35