Upgrading to CMDB 2.0

If you have upgraded to BMC Remedyforce 20.14.01, to use CMDB 2.0, you must perform the steps in this section. If your Application Settings menu contains the CMDB 2.0 Upgrade option, you are using CMDB 1.0.

The following topics are provided:

• • Comparison of features in CMDB 1.0 and 2.0
  • Overview of the CMDB 2.0 upgrade process
  • Preparing for upgrade to CMDB 2.0
  • Upgrading to CMDB 2.0 by using the CMDB Upgrade option
  • Verifying data after migration
  • Where to go from here
  • Related topic

Comparison of features in CMDB 1.0 and 2.0

The following table compares how different features are implemented in CMDB 1.0 and 2.0:

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
• CMDB 2.0 upgrade process
• CMDB scanning process
• How to handle required custom fields in CMDB 1.0 classes (objects)
• How same-field-name conflicts are resolved for out-of-the-box fields
• Business Service fields that are not added to Base Element
• Default values assigned to automatically added custom attributes

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 that you need all these custom fields. For more information, see CMDB scanning process.
• If you have 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).
• If you have custom fields with the same names in different CMDB classes, 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 names as suggested in the scan report. For more information, see CMDB scanning process.
• If 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.
• If 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 when custom fields are automatically added to the Base Element object. However, the Unique ID and External ID properties of these fields are not configured in the Base Element object.

CMDB 2.0 upgrade process

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:

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 for all CMDB 1.0 classes (objects) is saved in the Base Element object. After data is migrated to CMDB 2.0, this required field becomes required for all the CIs.

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

If you are add 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 a validation rule such as the following example, on the Base Element object.

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 required (for example, BMC_COMPUTERSYSTEM). Also replace <Required Field Name> with the name of the 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 for 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 — If 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 — If 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.

Preparing for upgrade to CMDB 2.0

BMC recommends that you upgrade to CMDB 2.0 on a weekend or a holiday. The process takes a few hours, depending on the number of records in your CMDB.

Complete the following actions before beginning to upgrade to CMDB 2.0:

• Take a backup of the data in your Salesforce organization.
• Assign the Remedyforce Administrator permission set to your User Details page in Salesforce or update the field-level security permissions of the Base Element fields for your profile.
   For information about the fields added to the Base Element object, see Fields in the CI classes. Do not configure field-level security for the fields of the Base Element field set. For information about configuring field-level security, see the Salesforce Help.
• Disable the scheduled import jobs (if you have any) until CMDB 2.0 is upgraded.

• Inform your users about the planned schedule of your CMDB 2.0 upgrade so that your users do not create, update, or link a CI record or import records during the upgrade. After you start upgrading to CMDB 2.0, your CMDB is locked and all data added or updated during the upgrade is lost.
   Also, if BMC FootPrints Asset Core integration is enabled, do not link or unlink a record.
  
  The following table provides a list of customizations that might be present in your CMDB. If a customization is present in your CMDB, perform the action that is listed in the table.

Upgrading to CMDB 2.0 by using the CMDB Upgrade option

Before you begin upgrading CMDB, read Preparing for upgrade to CMDB 2.0.

1. Click the Remedyforce Administration tab.
2. On the Home page, click the Application Settings tile, and from the menu, select CMDB 2.0 Upgrade.
    This option is available only if you upgrade to BMC Remedyforce 20.14.01.
3. To scan the CMDB for the list of custom attributes, click Step 1. Run the CMDB scan, and then click Scan CMDB.
    The scan progress is shown on the page. A list of custom attributes in custom and out-of-the-box classes is sent to you in an email message.
4. To see the list of custom attributes, click Last Scan Result Executed at <date and time>.
    For more information about the scan report, see CMDB scanning process.
   
   The Add Automatically and Add Manually buttons are enabled. If none of your CMDB classes contain custom fields (attributes), go to step 11.

5. To add the attributes reported in the scan report to the Base Element object, click Step 2. Add the identified custom attributes to the Base Element object.
    You can add the custom attributes automatically (step 6) or manually (step 7 ).

   Note

   If any custom attribute is required, clear the Required check box for the attribute before adding it to the Base Element object. For more information, see How to handle required custom fields in CMDB 1.0 classes (objects).

6. To add custom attributes automatically, perform the following actions:
   1. Navigate to Setup > Security Controls > Remote Site Settings.
   2. Click New Remote Site.
   3. In the Remote Site Name field, enter a name.
   4. In the Remote Site URL field, enter the URL of your BMC Remedyforce application before /apex.
       For example, enter https://BMCServiceDesk.na7.visual.force.com.
   5. Navigate back to the CMDB 2.0 Upgrade page (Remedyforce Administration > Application Settings > CMDB 2.0 Upgrade).
   6. Click Step 2. Add the identified custom attributes to the Base Element object and then click Add Automatically.
   7. Select the check boxes for the fields that you want to add to the Base Element object.

   8. Click Add Selected Fields to Base Element.

      Note

      If you choose to have fields added automatically to the Base Element object, do not click the Scan CMDB button.

      The Status column shows the progress and status of adding the selected fields to the Base Element object.
       When fields are added automatically, a default value is assigned to some attributes of a few field types. For more information, see Default values assigned to automatically added custom attributes.

7. To add custom attributes manually, perform the following actions:
   1. Navigate to Setup > Create > Objects.
   2. In the Label column, click Base Element.
   3. In the Custom Fields & Relationships section, click New.
   4. Enter the field details.
       In the Field Name field, use the value provided in the Suggested API Name column of the scan report. Otherwise, your data will not be mapped to the correct field, and the data will be lost during migration.
   5. Click Save.
   6. (Optional) To add another field, click Save & New and repeat step d and step e.
   7. After adding all of the fields, click Add Manually.
8. Click Verify Changes.
    The verification results are shown on the page. If the results show that some custom attributes are still missing, check the log. While going through the log, verify that you do not need to add the missing attributes. Data for the missing custom attributes is not migrated. To ensure that you do not lose the data, you must add all of the missing custom attributes.
9. (Optional) If you have custom classes, create field sets for the classes in the Base Element object and assign the required fields to the field set:
   1. Navigate to Setup > Create > Objects.
   2. In the Field Sets section, click New.
   3. In the Field Set Label field, enter the custom class name, for example, Mobile Devices.
   4. In the Where is this used field, enter a short description of the field set, and click Save.
   5. Drag the fields that belong to the field set (or custom class) to the In the Field Set list.
   6. Click Save.
10. (Optional) If you added custom values to out-of-the-box Picklist-type fields, add those values to the fields in the Base Element object.

11. To migrate data to the Base Element object, click Step 3. Migrate data to CMDB 2.0, and then click Migrate Data.

    Important

    The CMDB is locked while migration of data is in progress. During data migration, BMC recommends that you do not perform any actions in the Remedyforce CMDB tab.

    After the migration is complete, an email message is sent to you. The result is also shown on the CMDB 2.0 Upgrade page. If the result shows that errors occurred in the data migration, check the logs.

12. Ensure that your data has been migrated successfully by checking the logs or creating a tab for the Base Element object.
     For more information, see Verifying data after migration.
13. To start using CMDB 2.0, click Step 4. Switch to CMDB 2.0 and click Switch to CMDB 2.0.
     Until you switch to CMDB 2.0, your CMDB 1.0 data is displayed, and new and updated records are saved in CMDB 1.0 only.
14. After you have switched to CMDB 2.0, perform the post-upgrade procedures.

15. To free the space occupied by CMDB 1.0 records, click Step 5. Delete the CMDB 1.0 data, and then click Delete CMDB 1.0 data.
    The success or failure in deleting CMDB 1.0 data is shown on the screen, and an email message is sent to your email address.

    Warning

    If an error occurred during the migration to CMDB 2.0 and you selected to switch to CMDB 2.0, if you delete the CMDB 1.0 data, you will lose the data that was not migrated.

    If there is no CMDB 1.0 data and you click Delete CMDB 1.0 data, a message appears on the window and the button is disabled.

16. (Optional) To hide the CMDB 2.0 Upgrade option in the Application Settings menu, click Additional Options and then click Hide This Tab.

Verifying data after migration

After the CMDB data migration is complete, check the logs. One of the following logs is provided on the CMDB 2.0 Upgrade page:

• Success log — Shown when data is migrated successfully. The log contains Instance ID, Instance Name, and Salesforce unique record ID of the Base Element object for all migrated CIs. If the success log reaches the limit of 5 MB, no new logs are added.
• Error log — Shown when not all data is migrated successfully. The log contains exception messages, Instance ID, Instance Name, Salesforce unique record ID of the Base Element object, and error stack trace.

As an alternative to checking the success logs to verify that your migration was successful, you can create a tab for the Base Element object and check the records on the tab.

To create a tab for the Base Element object to verify data after migration

1. Navigate to Setup > Create > Objects.
2. In the Label column, click Base Element.
3. In the Page Layouts section, in the Action column, click Edit for Remedyforce Base Element.
4. Drag the fields that you have migrated to the layout, and click Save.
5. To create a tab for the Base Element object, navigate to Setup > Create > Tabs.
6. On the Custom Tabs page, click New.
7. In the Object list, select Base Element.
8. In the Tab Style list, select the required style for the tab, and click Next.
9. Select visibility preferences for the tab, and click Next.
10. Click Save.
11. Click the Base Element tab.
12. In the Action column, click Edit for any record.

Check the data in the records. If you see correct values in the fields, data migration was successful.

Where to go from here

Performing-CMDB-2-0-post-upgrade-procedures

Related topic

Enabling-new-features-in-20-14-01