Merging operating company data

Service provider companies may offer a mixture of IT support, service management, and hardware and software services to third-party companies who do not want to perform these services internally. Service providers who offer these services, frequently operate large multitenant BMC Helix ITSM systems to track and manage the services and support they offer to their customers. Typically, there are a mixture of end-customer and service provider support teams who use BMC Helix ITSM to manage tickets for a particular customer.

BMC Helix ITSM supports this business model by enabling the service provider to be set up as an "operating company" within the application and to configure users to have access to the data of customers on the system. However, when multiple BMC Helix ITSM systems are supporting multiple customers, some of the service provider resources can provide support to customers hosted on different BMC Helix ITSM systems. This can add significant operational overheads and be a business driver for the consolidation of systems.

Impacted entities

Consolidating systems where the same operating company or third-party companies exist in one or more of the systems being consolidated requires careful management. The following entities may be affected by the consolidation.

Merge operations

Achieving a successful merge of a duplicated operating company or third-party company involves the high-level operations discussed below.

Migrating any foundation data entities that exist in the source system but do not exist in the target system

Any operating company support staff who exist in the source system but do not exist in the target system must be migrated.

As part of the migration, any references the migrated entity has to data that already exists on the source and target system must be updated to refer to the target system. For example, the operating company entity always exists on the source and target system. All people records that are migrated must be updated so that the company name and multitenancy group ID refer to the target system's operating company.

Selectively updating foundation entities that exist in both systems

Consider the simple case of an operating company engineer who exists on both systems and is a member of the following support groups:

• Source system
  • Database Support
  • Application Support
• Target system
  • Database Support

In this case, the engineer needs access granted to the Application Support group as it appears that they already have access to the Database Support group. Assuming that the Database Support groups in the source and target systems represent the same logical entity, the membership of that team from the source system should not be migrated because it already exists.

However, if the source Database Support group actually represents a different logical entity than the Database Support group on the target system, the Database Support group must be migrated from the source system, and given a different name that does not clash with the existing support group. Then, the engineer must be granted access to the migrated and renamed Database Support group.

This analysis and logical reconciliation of the data held in the source and target systems cannot be automated and depends on understanding of the business operations.

Updating references to entities in migrated transactional, global, and foundation data

When migrating data such as tickets or application rules that replicate non-normalized data or hold unique identifier references to entities, it is essential that the data is updated to reflect the correct entity in the target system. For example, consider the following incidents that are assigned to operating company support groups for resolution.