Managing the gold build image
The onboarding process depends on careful management of the database image that will be used for the new production system when the customer goes live.
The following table lists the key backup points for the gold build image.
Image | Contents |
|---|---|
Backup for baseline (Step 1 in Build phase) | Out-of-the-box BMC Helix ITSM with no data. This is effectively the BMC Helix ITSM baseline installation. |
Package code changes and update gold baseline (Step 11 in Customize-and-system-test-phase) | BMC Helix ITSM with all in-scope customizations from the on- premise systems after unit test validation. No data from the on-premises system is included in the image. |
Restore gold backup and deploy system test fixes (Step 18 in Customize-and-system-test-phase) | BMC Helix ITSM with all in-scope customizations from the on- premise systems after system test validation. No data from the on-premises system is included in the image. |
Restore gold backup and deploy UAT fixes (Step 21 in User-acceptance-test-phase) | BMC Helix ITSM with all in-scope customizations from the on- premises systems after validation in UAT round 1. No data from the on-premises system is included in the image. |
We recommend that you keep data out of the gold image because:
- Database backups will be much smaller.
- Holding data in the gold image restricts the activities you can perform.
Server references in the gold image
The gold image database backup is originally taken from the onboarding (that is, development) database and contains references to that environment in the data tables. Furthermore, the data migrated from the on-premises system also contains references to the on-premises systems and environments.
As part of the process of deploying this database into the production or QA system, the environment and server references must be updated appropriately for the target system. Use BMC Helix Data Manager to identify and update these references, and to deploy appropriate environment configuration such as server group operation rankings.
Using BMC Helix Data Manager significantly reduces the time taken to copy the database to other environments compared with the manual update of these references.
This database copy process forms part of the final cutover from the on-premises system to BMC Helix. This final cutover is a time-sensitive operation. The BMC Helix Data Manager approach for updating server references typically reduces outage times by 10 to 15 hours compared with the manual process.
Managing data for a parallel system migration
When migrating to BMC Service Management Cloud, you are effectively creating a new parallel production system.
The basic principles of data management for a parallel system migration are that data should be mastered in only one system at one time. Effectively the on-premises production system holds the master copy of all data until the point of cutover.
The gold image is the copy of the database that will be used for the new production system. If you move data into the gold image you must ensure that this data is not changed independently of the on-premises production system.
If you move data into the gold image you must protect that data being changed by any member of the project team, but also by the AR System server itself that will run scheduled actions such as updating SLA measurements or sending notifications.
It is possible to configure an AR System server to block scheduled actions; however, this configuration will prevent SLA Targets and Agreements being built, or CMDB class and attributes being changed. This is not ideal.
The easiest way to comply with data management best practices is not to import data into your gold image.
We recommend only importing data into the database as part of the preparation for the cutover process, for example:
- Export all data from the on-premises system and FTP to the cloud a couple of days before the cutover outage.
- Restore the gold image and import this full data set.
- During the cutover outage, migrate the delta data changes from the on-premises system.
You can retain the full export from the on-premises system as a BMC Helix Data Manager data package on the onboarding system for as long as needed, thereby minimizing data migration activities.
Managing production and emulated cutover
The process of moving to a new production system is complex and involves multiple parties, a series of complex technical actions, and a limited time window.
For the success of the project, the process of delivering the production cutover must be documented and practiced, and the output of that process must go into the user acceptance test (UAT) validation.
We recommend that an emulated cutover is performed prior to UAT 1 and UAT2. This ensures that you have a fresh set of data so that you can test time-sensitive and in-flight data as part of UAT. During the cutover process, you can then deliver a working production system and validate it.
For the cutover process, follow these guidelines:
- Document the cutover process in a spreadsheet detailing the duration, start and stop times, and the person responsible for the action. Also create a reference document that describes the detailed technical steps. You can download a .
- Schedule regular conference calls throughout the cutover process. Resources who have actions during the cutover must report their progress and results during the meetings. This ensures that any issues or delays are reported in a timely fashion. Managing a cutover by email is not effective and leads to delays and miscommunication.
- Ensure that you always have a person who is the cutover lead throughout the process. This responsibility may need to change hands several times if the cutover spans more than 8 hours.
- Ensure that (where possible) complex technical actions are performed within reasonable working hours. While you should minimize the outage time that impacts users, treating technical staff with respect and avoiding working in the small hours will provide better results for everyone.