Low-cost computing infrastructure, seamless scaling of applications and easy integration into development practices have largely been confined to public cloud services like Amazon AWS, a nexus of forces, including the maturing of OpenStack implementations, container tools/implementations and SDx (SDN, SDDC, SDS) will lead to enterprises achieving cloud-like capabilities in-house.

Today Individuals, SMB and Large Enterprises everyone has some kind of Cloud services. These relationships will not last forever; sometimes we need to make a change, and sometimes events beyond our control make it so we can't stay with what 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.

Having a cloud exit strategy simply means having some idea of how an enterprise will perform transition from the existing cloud services currently in use to 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.

 

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
• How it is using these cloud services 

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, 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 which are far costly, 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.

As an enterprise completes this process, one important consideration to keep in mind is the confidentiality, integrity and availability of services during the transition. Pay careful attention to the Security and User Acceptance Criteria set earlier. For example, if data migration is required, does the transition plan accommodate protecting that data during the move? Once the transition is complete how end users will response to a change?

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.