ITIL for Beginners: How to Create a Backup Plan

It’s not the best time of the week when after long hours of preparation and intensive work during an implementation period your change fails. Plus, it also breaks other things. Sometimes it is clear immediately after implementation, but sometimes you only find out hours or days later. If you’re lucky, you can make an emergency change to fix a fairly obvious root cause, say missing one of the items on the deployment checklist. However, in many cases this is not possible and you will have to undo the change.

A key to a successful backup is having a plan. Yes, a backout plan, something that is often overlooked. After all, you want your backout to be an honorable surrender, not a panic attack. To limit the damage to the company and your reputation, you need to keep the situation under control. To do that, the engineering team needs to know what to do and the Service Desk needs to keep the business informed.

A backup plan is designed to put you in control. It’s your insurance policy against Murphy’s law. Let’s be honest: we don’t insure everything. Don’t make a formal back-out plan for every change. Just make sure the team can verbally describe how to go back in case things get messy.

For more complex changes you need a more formal plan. Making such a plan is one of the least beneficial activities of many technical people. Therefore, the Change Manager should be responsible for getting it done. It should be included with the rest of the change documentation, ready to be used if needed.

A good backup plan should include:

  • accessible, technical instructions,
  • specific communication instructions, with contact names.

The list of technical instructions is created by reversing the order of activities in your implementation plan and describing how to return to each of the steps performed. It could be relatively easy if most of the work could be done by restoring the most recent backup. Consider an example backup plan for such a scenario:

  • Notify the Service Desk of the backup plan initiation. (Call them, email them, or create a ticket—mention it specifically.)
  • Disable user access to the system. (How? List the actions.)
  • Restore backup created before the change was implemented. (Make a list of the necessary actions.)
  • Perform system health checks. (List them all.)
  • Enable user access.
  • Notify the Service Desk of a successful backup.

Often the plan will be more complicated than it seems. There may be many more recovery steps, involving various databases, file systems, and other parts of the IT infrastructure. The base template still applies. It must be detailed and tailored to each organization and each change. Of course, every action must have an owner, so make sure it’s clear who does what.

See also  Take good care of your employees

Communication with the Service Desk is very important. Communication in general should be part of the plan to control the situation. In addition, the business needs to know that IT is in control. The Service Desk must ensure that the image of control is propagated to the business. They can do this by communicating regularly if the impact on the business is serious enough. They also take calls from dissatisfied users and inform them of the status of the solution.

A backup plan is your insurance policy. It’s up to you to have it or not. It is recommended to have it before any complex change as business continuity and IT credibility are at stake. Start by drawing up such a plan for the most complex change coming up. Then build on that and over time you’ll have it ready for all the risky changes.