Managing Approved Change Migrations

The ITIL Change Management process has quite a bit to say about request management, but not as much about management of the deployment of technical changes created to meet the change request requirements. This article brings to light some of the deeper technical decisions required around when to deploy technical changes, their timing and surrounding controls.

ITIL process

The ITIL Change Management process includes information about;

• Gathering and prioritizing change requests
• Executing the requests within agreed time
• Enabling the organization to meet governance and regulation
  change-requirements
• Monitoring changes from the time of request all the way through to deployment into production while understanding affected assets

Migration scheduling

There are several standard approaches to scheduling migrations; different approaches can be used for each migration target:

• Immediate migration as the approval occurs - typically used for BAU bug fixes and minor enhancements
• Regular planned migrations (eg. daily at 5pm or Fridays at 5pm) - typically used for BAU bug fixes and minor enhancements
• Irregular planned migrations - typically used for PROJECT work to go-live with a planned release date

The other major variable for performing a change migration is the derived approver for the migration status. The approver may also be varied depending on the change type:

• Emergency Bug Fixes
• Regular Bug Fix / Minor Enhancements
• Planned Enhancements
• Project

Considerations when migrating to QA / Testing and Production:

Here are some recommendations for an organization's change migration approach.

QA / Testing:

Approvals: Consider using the request fields (Owner and Programmer) as the derived approver for a QA migration

Timing: Consider scheduling the Rev-Trac migration job on event /RSC/TRIGGER to perform immediate migrations upon approval

Production:

Approvals: Utilize the organization structure to its full potential, ensuring that the correct users are authorizing the migration to production. There is potential to enforce multiple users approve the migration to production.

Timing: For smaller changes schedule the migration job to occur during a safe period, where users may not be affected if a problem occurs. For project scenarios, it is often best to queue the transports, but manually trigger a migration job. This allows for someone to check that all changes are included in the release and perform the migration when suited to the organization.

Sequencing: The challenges faced in ensuring the correct sequence of transports can often require the assistance of a technical user during the migration to production. An easy way around this is to require that a management type approver performs a 'pre-production approval', while a technical user performs the approval which triggers the migration. This will allow for the technical user to resolve any sequencing issues prior to migration occurring.

For more information about handling your change migrations, please contact consulting@xrsc.com

Chris's Bio
Chris Drake is a Software Consultant and Pre-sales Engineer at Revelation Software Concepts. He performs Rev-Trac Software Implementations, Rev-Trac Administrator and End User Training and Customer Change Control Strategic Planning. Chris joined RSC in 2007 as part of the support and QA team. Chris loves playing sports, driving fast cars, horse racing and good food!

You may also find interesting:
SAP Change Intelligence