In the previous chapter of this blog we discussed how Change management is a vital aspect of how successful organizations operate because it is a form of a control valve for modifications to the environment that, in some way, impact business. We started to look at a specific example that illustrates this point, let’s continue that discussion
Returning to change management: Since each server is uniquely running its own software and supporting its own business areas, it is necessary for a separate risk impact assessment to be performed on each server. These assessments might vary greatly, depending on what services they deliver or the lines of business they support. It is also very likely that the different business partners of the impacted services will have varying levels of tolerance for the amount of risk they are willing to assume.
Backout Planning: Business partners recognize and understand that implementations and deployments do not always go according to plan. Do not confuse this with ‘liking’ or ‘accepting’ failed implementations. For this reason, they want you to detail the steps that you will take in the event the migration of a server does not succeed. Given the complexity of a server migration, the back out plans, like the risk impact assessments, must be documented for each server. There cannot be one simple overarching back out that will apply to every server. Some of the same rationale holds true for back out plans as described for risk impact assessments, but there are additional elements that complicate back out plans and they are sequence and threshold. This doesn’t mean that each server ‘MUST’ have its own plan, it just means you have to assess each to determine if it does.
The sequence of the migration will drive the sequence of the back out plan since the servers are interdependent. For example, you might need to execute the back out Plan on servers that were already successfully migrated because the dependent downstream server failed and they must remain in sync with each other. In this scenario, you must account for how you will back out changes to a server that was already successfully migrated.
The threshold scenario is yet another situation where a back out is warranted, but simply cannot occur. Take for example the sequence scenario described above. If you are unable to back out the changes to those other servers, then what do you do? You need to account for this scenario because no matter what change you are making to the environment, there are times where you have gone too far to ‘back it out.’ Maybe in this scenario you recover the old servers from a backup or build a brand new server to replace the failed migration server. In either of these scenarios, you must think through the worst-case scenarios and document your plan of action if they occur.
Pre-event Risk Mitigation: In the case of a server migration, it might be beneficial to power down the servers to ensure that they are able to come back online. Since servers, unlike workstations, are designed to run all the time, their hardware is at times less resilient to being powered down then turned on again. Disk-drive failures, for example, can be very common in servers that have been running for long periods without powering down. It is not a major issue for one or two servers because an organization will have some spares. Imagine if there were forty disk-drive failures, however, when the migration occurred. It is unlikely that any organization has that many spare units available.
In the next edition of this blog we will look at ways that this risk can be mitigated
