What Are Best Practices for MOP Backout Plans

[dan_vincent]

I understand the MOP to be a set of steps that are taken is each area of preparation, implementation, validation and back out.

Operations staff often provide a MOP back out plan as simply, "restore from backup" or "rollback changes." Another oft-used phrase, "undo changes made in implementation plan."

As a Change Manager, this doesn't give me much to consider and it doesn't seem to be detailed enough for anyone else to follow should the implementer become unavailable after a deployment fails.

I'd like to provide an adaptable definition and example of a clear back out plan for the MOP (not too much/not too little information in it).

Any suggestions how to better define a back out plan?

Thank you,

Dan Vincent

[ian_cox]

Dan,   Yes this can be an issue especially when the developer or implementation partner is not available.   From a practical point of view what each change needs is an automated backout plan.   We ask the developer who is creating the change to create an automated back out plan.   The change and the backout plan then needs to be peer reviewed by another developer.   To make this a bit more full proof.   We then hand the change off to an admin team to implement and they are responsible for testing the back out plan in a test environment prior to going to our Change Advisory Board who will review the back out plan.

This is really critical when the change gets deployed at 6pm and then in the middle of the night an issue gets noticed,   The SOP is just to roll back the change by executing the rollback plan.   There are of course occasions where it can't be fully automated.   In this case the developer has to provide a detailed set of steps to roll back the change that can be peer reviewed and tested by the admin team.