Overview of the CMDB 2.0 upgrade process

When you upgrade to CMDB 2.0, data from various CMDB classes (objects) is moved to the Base Element object. Before you decide to upgrade to CMDB 2.0, you must consider the impact of this move.

The following topics are provided:

Important considerations before upgrading to CMDB 2.0

Consider the following points before you decide to upgrade to CMDB 2.0:

• The Master-Detail Relationship type fields where a CMDB object is a child object are not supported.
• Relationships between a CMDB class and Base Element objects that points to a record for another CMDB class are not supported.
• No more than 500 custom fields are allowed on a managed package object. If you have more than 500 custom fields in all of your CMDB classes, you will be unable to move data to all of these custom fields. (You can get a report by scanning your CMDB. The scan report provides you with the number of custom fields that you have in your CMDB.) Verify if you need all these custom fields. For more information, see Overview of the CMDB scanning process.
• You have custom fields that are required in a CMDB class. You must not mark these fields as required during the upgrade process. However, after upgrading to CMDB 2.0, you can use validation rules to set the custom fields as required at a class level. For more information, see How to handle required custom fields in CMDB 1.0 classes (objects).
• You have custom fields with the same names in different CMDB classes. For such fields, first consider whether you need all these fields, or if only one field can store data for all the CIs in the Base Element object. If multiple fields with the same name are required in the Base Element object, use field name as suggested in the scan report. For more information, see Overview of the CMDB scanning process.
• You have added custom values to out-of-the-box Picklist-type fields. You will need to add these values manually to the Picklist-type fields before migrating data to the Base Element object. For more information, see Preparing for upgrade to CMDB 2.0.
• You have unique custom fields in various classes. When the limit of the unique fields and external IDs of the Base Element object is reached, an error is displayed while automatically adding the custom fields to the Base Element object. Such custom fields are added to the Base Element object. However, the Unique and External ID properties of these fields are not configured in the Base Element object.

Overview of steps to upgrade to CMDB 2.0

In CMDB 1.0, different types of configuration items (CIs) are saved in different objects (classes), such as Computer Systems, LAN Endpoints, and so on. However, in CMDB 2.0, all the CIs are stored in a single object, Base Element. Fields that store information about a CI type such as Mainframe are grouped together in a field set, Mainframe, that is added to the Base Element object.

When you upgrade to 20.14.01, the out-of-the-box fields of all the CMDB classes and the field sets of all of the out-of-the-box classes are available in the Base Element object. If fields with same name existed in different classes, the conflict is resolved, and one or all such fields are added in the Base Element object. For more information, see How same-field-name conflicts are resolved for out-of-the-box fields. Also, some fields of the Business Service object are not added to the Base Element object. For more information, see Business Service fields that are not added to Base Element.

This section provides an overview of the steps that you must perform to upgrade your CMDB. For a detailed procedure, see Upgrading to CMDB 2.0 by using the CMDB Upgrade option. BMC recommends that you read the information in this section before performing that procedure. 

The following table provides an overview of the steps to upgrade to CMDB 2.0:

Overview of the CMDB scanning process

To scan the CMDB, Salesforce queues an Apex job. This job runs based on the Apex jobs scheduled to run in Salesforce. When your CMDB scan is complete, the scan report is available in the comma-separated value (CSV) format.

The scan report lists the following customizations in your CMDB:

• Custom attributes that you have added in custom classes.
• Custom attributes that you have added in out-of-the-box classes.

If no attribute exists in a custom class, the custom class is not reported in the scan report.

The following table describes the information in a scan report:

The following information about custom fields is not provided in the scan report:

• Display format and starting number of Auto Number type of fields.
• Field description
• Number of visible lines for Picklist (Multi-Select), Text Area (Long), and Text Area (Rich) field types.
• Mask Type and Mask Character for the Text (Encrypted) field type.

While going through the scan report, verify if multiple custom fields exist in different objects for the same purpose. If you find such fields, verify that you need all these fields and perform one of the following actions:

• If you are using the custom fields for the same purpose, retain the custom field in one class object, and delete the others. For example, if you have the same custom field, Dimensions, in the Computer System and Mainframe objects, delete the custom field in one of the objects.

• If you need all of the custom fields, while adding the fields, ensure that in the Field Name field, you use the value suggested in the Suggested API Name column of the scan report. The value in the Field Name field is an internal reference value and must therefore be unique.
  For the first occurrence of a custom field, the suggested API name is the same as the custom field name. The following nomenclature is used to suggest names in the Suggested API Name column for the subsequent occurrences of the same custom field in different classes:
  
  <Acronymoftheclasstowhichthecustomattributebelongs >_<existingvalueinthe Field Name field of the custom attribute>
  
  For example, if the Docking Station field is available in the Laptops custom class (field type Number), and the Mainframe out-of-the-box class (field type Text), Docking_Station and MF_Docking_Station are the suggested API names in the scan report.

How to handle required custom fields in CMDB 1.0 classes (objects)

If you have set a custom attribute as a required field in any of the CMDB classes (objects), prepare a list of such fields. After you upgrade to CMDB 2.0, data of all CMDB 1.0 classes (objects) is saved in the Base Element object. After data is migrated to CMDB 2.0, this required field will become required for all the CIs.

If you add the custom attributes automatically, clear the Required check box of such fields in the Base Element object before migrating data.

If you are adding custom attributes manually, do not select the Required check box for the these fields in the Base Element object.

After upgrading to CMDB 2.0, to continue using these fields as required fields for a specific CI class, use validation rule on the Base Element object. The following example shows a validation rule that you can use:

UPPER(BMCSERVICEDESK_ClassNamec) == ' BMC<class in which the custom field is required>' && ISBLANK(BMCSERVICEDESK_<Required Field Name>c)

In this validation rule code, replace <class in which the custom field is required> with the name of the class for which the custom field is a required field (for example, BMC_COMPUTERSYSTEM) and <Required Field Name> with the name of the field that is a required field.

How same-field-name conflicts are resolved for out-of-the-box fields

When you upgrade to 20.14.01, fields and field sets for various CMDB classes are available in the Base Element object. If you upgrade your CMDB to version 2.0, data of all CMDB classes is migrated to the Base Element object. The following rules are used to resolve conflicts that arise when fields in different classes have the same name:

• If the type, length, precision, and decimal values for the conflicting fields are the same, only one field is added. This field can be used in multiple classes or field sets.
• If the field type is the same, but the precision, decimal, or length is different, the field with the greatest length is added, to accommodate data for shorter fields.
• Conflicts with WebPage and CountryCode field labels are resolved as follows:
  • WebPage -- The same field name is present in the Physical Location (of field type Long Text Area) and Person (of field type Text) classes. Only the field from the Physical Location class (of field type Long Text Area) is added to the Base Element object.
  • CountryCode -- The same field name is available in the Physical Location (of field type Picklist) and Organization (of field type Text) classes. Two fields are added to the Base Element object as Country of field type Text and Country Code with field type Picklist.

Business Service fields that are not added to Base Element

When you upgrade to CMDB 2.0, the following fields from the Business Service object are not added to the Base Element object. In CMDB 1.0, these fields are formula fields that reference the Base Element object and are not used in CMDB 2.0.

• ClassName
• Asset
• Description
• FKBMC BaseElement
• Instance Name
• Site
• Stage (present in the Base Element object)

Default values assigned to automatically added custom attributes

When custom attributes are added automatically, default values are assigned to some fields of some specific field types. The following table lists the fields that are assigned a default value, the type of field that is created, and the default value that is assigned to the field.

When a field of any type is added, the text in the Description field is not copied.