vali_111 - Fotolia
Have you heard the old fishing adage that "the time to patch the hole in the boat is before you leave the dock"?
The point of this saying should be obvious; namely, that there are actions -- such as fixing the leaky boat -- where forethought and planning can avert major catastrophe. And, as most practitioners well know by now, nothing could be truer when it comes to the cloud.
Despite this, there is one area where oftentimes organizations fail to plan as fully as in other areas of cloud management: when a cloud relationship fails. The fact that this is less carefully planned than other areas shouldn't be terribly surprising, though, it's human nature. After all, nobody goes into a cloud partnership (or any other relationship for that matter) thinking it will fail -- and planning for potential failure down the road can be challenging to discuss with peers at the beginning of a cloud partnership, especially when their minds are fixed on cost savings, increased agility and other potential benefits.
But the fact of the matter is that things happen. Vendors go out of business, business needs change and more appealing offerings enter the marketplace. In short, sometimes cloud relationships don't last; sometimes we need to make a change, and sometimes events beyond our control make it so we can't stay on a service we love. When that happens, having a plan can mean the difference between a slight hiccup that the organization can quickly move past versus chaos, downtime and major disruption to the business.
The point is, having a cloud exit strategy is like insurance: fantastic for you if you never need it, but if you do, heaven help you if you don't have it.
What is a cloud exit strategy?
Having a cloud exit strategy simply means having some idea of how an enterprise will transition from the existing cloud services currently in use to one or more alternatives. In other words, the cloud exit strategy is putting together a course of action to ensure whatever cloud services support activities the business is doing now can be replaced without major disruption.
Note that cloud exit strategies apply to both internal and external service provider relationships -- focusing on either what we're replacing or what we're replacing it with. Likewise, planning can address any type of cloud service: IaaS, PaaS or SaaS. The specifics of what alternatives are selected will obviously vary depending on the deployment model, but an exit strategy can and should account for any service that supports business activities.
Planning will vary depending on the specific service used. Meaning, what an enterprise finds to replace the lead tracking and sales support SaaS application is probably significantly different from the service it would use to replace an IaaS environment. This means the planning will need to be done on a service-by-service basis. Sometimes (such as in the case of virtual instances at an IaaS provider) the "alternatives" might look very similar -- or in fact be almost exactly the same as -- from a technology standpoint anyway -- to what an enterprise is currently using. Other times, such as is the case with a SaaS application, enterprises may find that a direct "forklift replace" isn't as viable, and that more creative solutions will need to be sought.
Creating a cloud exit strategy
The first requirement involved in creating a cloud exit strategy for an organization is that it understands two things: what cloud services it is currently using, and how it is using them. Enterprises want to understand the first piece -- what cloud services are in use -- because they want to make sure their plan is comprehensive; an enterprise doesn't want to find out down the road that it missed a critical application supporting a key business area. For large centralized deployments (such as, for example, an enterprise IaaS partner), this is probably relatively straightforward. For smaller, limited-scale or "one-off" situations (such as SaaS services used by the business), this might be harder to do. There are cloud discovery technologies that exist in the marketplace, but organizations can also derive information from business impact analysis activities that you may already conduct for other purposes, for example, business continuity planning (BCP).
An organization should also understand how services are being used to ensure alternatives are reasonable and meet the goals of the end users who currently employ the technologies. For something like SaaS, this is a critical step. Why? Because SaaS is likely unique to the service provider that supplies it; to migrate, an organization will need to find something that meets those same goals. Even for an IaaS migration, though, where dealing with something fungible such as hypervisor capacity, it's still important because enterprises will want to identify any unexpected "gotchas" that stem from the specific way the service is being used.
Once an organization has these two data points, it will want to create the specific exit strategies for the services it has identified. Note that there could be quite a few services in use, so organizations may wish to prioritize accordingly; for example, you may want to start with smaller service providers, service providers at a higher risk, or service providers where you may consider a migration or discontinuation of service anyway (e.g., due to cost, performance, features, among other reasons). Enterprises will want to engineer an alternative solution and supporting migration path that meets the business needs as discussed above; be sure to identify costs involved, key players that need to be involved, and how you'll get access to critical resources -- such as the data you have at the existing service provider.
Note that you don't need to boil the ocean here for every service -- similar to a BCP planning exercise, some services have more "cushion" when it comes to ironing out kinks. For those that are less critical, an enterprise might decide to only plan enough to obtain a "rough idea" of what its transition plan would look like. For more critical services, organizations should have all their "i's" dotted and "t's" crossed so they can execute their plain in a manner of hours or days rather than weeks. Either way, you should identify how long you anticipate the transition will take when the time comes.
As an enterprise completes this process, one important consideration to keep in mind is the confidentiality, integrity and availability of services during the transition, i.e., security. Just as an organization would systematically evaluate the security of a new service being brought into the fold, so too should it apply the same methodology on the services replacing existing ones. Also pay careful attention to the security of the transition effort itself. For example, if data migration is required, does the transition plan accommodate protecting that data during the move? If the answer is no, are there controls such as encryption, backup, assessment and the like that can be implemented that would close the gap? Again, just as you would appropriately secure any other activity, ensure security goals are met during this process as well.
Planning a cloud exit strategy in advance can be a godsend should circumstances require it. While there is some time investment required to put the plan together, it can mean less "unknowns" when it comes to vendor lock-in for cloud deployments, and it can mean faster resumption of business activities in the event that a service provider becomes unavailable. In addition, the same data used in your cloud exit strategy can also help support BCP and DR activities.
About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, Moyle served as vice president and information security officer at Merrill Lynch Investment Managers.
Get help building a cloud service provider inventory