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.

Note

After migration, the object-level permissions that you set on the objects from which data is migrated are retained at the UI level.

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:

StepDescriptionReference topic
Prepare for the upgradeBefore upgrading to CMDB 2.0, you must perform a few tasks, such as backing up your data. Also, you must do preparations based on customizations in your CMDB.Preparing for upgrade to CMDB 2.0
Run the CMDB scan

Before you upgrade to CMDB 2.0, you must scan your CMDB for custom fields that you have added to various CMDB classes. At Remedyforce Administration > Configure CMDB 1.0 > CMDB 2.0 Upgrade > CMDB 2.0 Upgrade, click Scan CMDB.

The scan report provides you with the following information:

  • Custom attributes in custom and out-of-the-box classes
  • Custom attributes of the Base Element object. (You do not need to add those fields to the Base Element object.)
Overview of the CMDB scanning process
Add the identified custom attributes to the Base Element objectYou can add the custom attributes automatically or manually. Referring to the scan report, add the custom attributes as fields in the Base Element object. Then, add these fields to the appropriate field sets. If you have custom classes, add field sets for the custom classes in the Base Element object.

Overview of the CMDB scanning process

Default values assigned to automatically added custom attributes

Migrate data to CMDB 2.0To move all records to the Base Element object, click the Migrate Data button on the CMDB 2.0 Upgrade.Not applicable
Verify migration of your dataYou can verify your data in the Base Element object by referring to the logs or creating a tab for the Base Element object. The links to the logs are provided on the CMDB 2.0 Upgrade page.Verifying data after migration
Switch to CMDB 2.0After you successfully migrate your data, you can start using CMDB 2.0. After you switch to CMDB 2.0, your data is saved in the Base Element object. 
(Optional)Delete CMDB 1.0 dataAfter you are satisfied that all of your data has been migrated successfully, delete the CMDB 1.0 data to free up the storage space.Not applicable
Post upgradeBased on your customizations in CMDB 1.0, you will need to perform a few more tasks after your CMDB is upgraded.CMDB 2.0 post-upgrade procedures

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:

ColumnDescription
Class LabelName of the custom or out-of-the box class as entered in the Label field.
Class API NameName of the object as entered in the Object Name field.
Is Custom Class
  • Yes value - Custom class
  • No value - Out-of-the-box class
Field LabelName of the custom attribute as entered in the Field Label field.
Field API NameName of the custom attribute that is used in internal references as entered in the Field Name field.
Suggested API NameRecommended name to be used when you add the custom attribute in the Base Element object. The benefit of using the suggested name is that you can identify the correct field when you generate reports.
Field TypeThe data type of the custom attribute. When you add a Picklist-type of attribute in the Base Element object, refer to the Picklist Values and Picklist Labels columns.
Default ValueDefault value set for a custom attribute.

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.

Note

If the language of your Salesforce organization is set to any language other than English and you are using the English version of Microsoft Excel, the scan report does not display data correctly. To display the data correctly, install the localized version of Microsoft Excel.

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.

Note

If you run the CMDB scan after adding the custom fields, the custom fields that you have added in the Base Element object are reported again in the scan report. Do not add these fields again.

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.

Field typeField to which a default value is assignedAssigned default value
FormulaTreat Blank AsBlankAsZero
GeolocationDisplay Location in DecimalTrue
AutonumberDisplay FormatA-{0000}
Rich Text FieldVisible Lines3
Long Text AreaVisible Lines10
Encrypted TextMask Characters*
Encrypted TextMask TypeAll

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

Was this page helpful? Yes No Submitting... Thank you

Comments