Recommended methodology for merging data
The process of merging operating company data between two BMC Helix ITSM systems is not straightforward. The process involves decisions about logical entities that the application data is referring to and what the desired outcome of a merge operation should be. As a consequence, it is not possible to fully automate the process of merging all operating company data, due to the risks of making incorrect assumptions about the data.
Where there has been a structured approach to naming conventions for foundation data entities (such as Company, Site, Support Groups, and so on) and there are few duplicates in the data sets, the merging of the data may be relatively simple. However, where there is significant overlap in entities or where duplicate names have been used for different logical entities, the merge operation is more challenging and involves more activities.
Depending on the complexity of the data, achieving a successful merge may involve the following operations:
- Migration using BMC Helix Data Manager—BMC Helix Data Manager can be used to migrate subsets of data for the operating company or third party. For example, migrate only a selected list of people for an operating company who do not have accounts on the target system. Migrations using BMC Helix Data Manager will include all related data for the selected entities, providing a highly efficient way to migrate all related data such as support group membership, functional roles, application permissions, and so on. Multiple point migrations of the selected data can be performed in this way to migrate data such as support groups, people, sites, approval rules, and so on.
- Manual configuration—In some cases, manual configuration of data is simpler than migration. For example, it may be easier to manually reconcile the support groups, functional rules and application permissions across the few of the support staff who have complex changes to reconcile than to perform multiple migrations with complex filters to migrate the handful of data records that represent the configuration.
- Custom SQL scripts—In some cases, removal of selected records or transformation of data can be more easily achieved by using custom SQL scripts than by using BMC Helix Data Manager. For example, to remove the Unrestricted flag from a set of existing operating company support staff who fulfill certain criteria (for example, not in the Administrator or Incident Master permission groups), and add a list of specific company permissions to those users, then a custom SQL script may be optimal.
We recommend that operating company and third-party foundation data is merged into the target system prior to the consolidation cutover. This approach reduces the complexity and the risks of failure during the cutover, and enables the merge to be implemented as one or more low-risk changes prior to the cutover. During the cutover, none of the foundation data belonging to the operating company or third party will be migrated.
Consequently, after the operating company or third-party foundation data is merged into the target system, any further changes to the foundation data may need to be updated on the source and target systems. Therefore, this approach necessitates that the operating company or third-party data is placed under change control in the source and target systems. Any changes made to data must be replicated where necessary. For example, if a support engineer is given a new functional role in a support group, this must be added in source and target systems.