ITSM Migration Pack considerations

Global data

The standard Global data Migration Pack includes all core Global data that can be configured for a Remedy ITSM application.

To improve the performance of the data migration, disable parts of the application that do not have a Global data configuration. For example, Global approval chains are rarely customized and require a postmigration manual action to rebuild them. If these have not been modified in the source, you can simply disable the approval chains, thereby reducing the migration time by a small amount but with a significant reduction in the post migration steps.

Consult BMC Support if you want to discuss how to optimize your specific data migration.

For more information, see Including-or-excluding-forms-from-migration.

Request ID transformation

BMC Helix Data Manager allows data to be matched on import by using any combination of fields. By default, BMC Helix Data Manager maps records using Request ID. However, on many forms, GUID (179) or a combination of other fields is used for mapping. To ensure data does not clash, BMC Helix Data Manager automatically prefixes all Request IDs for forms that use non-Request ID matching.

See also Registering-source-and-target-systems.

Service Level Management data

Service Level Management migration with BMC Helix Data Manager includes SLA template data  (which includes review periods, milestones, rules, comments, owners, and targets).

The migration pack migrates SLA targets that are not linked to the BMC Sample SLA targets

If you modified the sample data for your system, modify the filter to include this data.

If SLM was extended to non-conventional forms such as Task or Problem, the forms will be configured in the current system as a new SLM data source. Custom data for the forms are automatically migrated with BMC Helix Data Manager. The custom data sources must be built in the target system by triggering the addition of new fields first to support SLM tracking and then the generation of the generic SLM filters.

When upgrading to a fresh installation of BMC Remedy ITSM, you must build all of the SLM data sources (including those provided out-of-the-box). BMC Helix Data Manager automates the discovery and building of SLM data sources. You can then configure these data sources as part of the migration of customizations.

See the topic Discovering-and-building-service-level-management-objects.

Computed groups

Computed groups are special AR System groups for which the membership is automatically assigned based on the other groups for which the user is a member. For example, the Cost Manager computed group [802] is defined with the following qualification:

" Cost Manager" OR "Asset Admin" OR "Contract Config" OR "Contract Admin" OR "Incident Master" OR "Problem Master"

This qualification includes only OR statements, so a user will inherit this computed group membership if the user is a member of any of these groups. You can define AND and NOT statements in a computed group definition. NOT statements are not used in the out-of-the-box computed groups. AND statements are used only for two out-of-the-box computed groups—DSL administrator and DSL User.

Computed group membership is assigned when any of the following events occur:

• A user is created via the API
• A user is added or removed from a group within a computed group
• A computed group definition is changed

Because BMC Helix Data Manager moves user records at the database layer, the computed groups for a user migrated from another version of ITSM are not automatically recalculated for the new ITSM 9.1 or later. Between ITSM 7.6.04 and 8.1 to ITSM 9.1 and later, there are several minor changes to application-level computed group definitions, which must be applied to users.

Additionally, if the target system has extra modules installed, consider any new out-of-the-box computed groups that might not have existed in the source system.

When migrating users by using BMC Helix Data Manager, you can use a data update script to apply changes in computed group membership to these migrated users. The script scans the full list of computed groups in the new ITSM system, and the existing computed groups membership for each user is updated. The script automatically updates computed groups for all computed groups using OR statements and the two out-of-the-box groups (which use AND statements). This script does not automatically apply computed group memberships where the membership is defined by using NOT or AND statements.

If you are using the RKM module, the target system might have some manually defined computed groups that use these types of qualification statements.

Users who are migrated from the source system will already have the correct membership of these computed groups, and no recalculation is necessary (the migrated data will be correct, and the script does not need to make any changes).

If the computed groups in your source system have been customized, you should migrate these changes to the target system. If you are not migrating these customizations, contact BMC Support for advice on how to manage this change as part of your upgrade process.

If you want to make a change to the out-of-the-box computed groups as part of the upgrade process, contact BMC Support for advice on managing this change.

Archive data

For forms that have been configured for archiving, a duplicate form is created in which to store the archive data. When an archive job is run, the configured archive rules are executed. Any qualifying records are copied to the archive form, and the original records are deleted from the source form.

The archived records remain identical to the original with the only change being to the Create Date. This is updated to reflect the date that the record was copied to the archive. The original Create Date is stored in a new field called Original Create Date (Field: 451). BMC Helix Data Manager identifies the form as an archive and adjusts the delta identification to be driven from the Create Date field.

If you are migrating archive forms that use an initial bulk load and a follow-up delta, consider temporarily disabling archiving between loads to minimize the change to archive and parent forms and to reduce the delta load.

See the topic Disabling-and-enabling-archive-log-mode-for-import-and-export.