Cloud Exit Strategy and Cloud Repatriation

Cloud computing has become a popular choice for businesses looking to take advantage of its scalability, flexibility, and cost savings. However, just because it’s a common strategy, doesn’t mean it’s being executed correctly. Some businesses are neglecting to plan for a cloud exit strategy as they transition to the cloud, which can lead to negative consequences such as prolonged downtime, decreased productivity, and even data loss if they need to alter their cloud strategy or provider.

As the cloud landscape evolves, some companies may find that their current cloud environment is no longer meeting their needs or the cost is much higher than originally anticipated. In these cases, companies may turn to cloud repatriation – the process of moving an organization’s workloads and data from a public cloud environment back to an on-premises or private cloud environment.

Having a well-defined plan for exiting the cloud is crucial when transitioning to it – and it’s never too late to define that plan if one wasn’t developed during initial cloud migration projects. It may seem like a lot of effort to plan for something that may not even be necessary, but it’s crucial to have a plan in place. Of course, no one enters a business relationship expecting it to fail, but it can happen.

When a business relationship with a cloud provider goes wrong, it can be a difficult situation – having a plan in place is mandatory. If things don’t work out, having a clear cloud exit strategy can prevent disruptions and minimize downtime. A cloud exit strategy, also known as “reverse migration” or “unclouding,” is a plan to ensure that the cloud services used by a business can be replaced without interruption and in an efficient manner. This includes both internal and external service providers in any category, such as IaaS, PaaS, or SaaS.

In this post, we will explore why more companies are turning to cloud repatriation and how a well-tested exit plan using automated provisioning can help make the procedure smoother, more efficient, and less risky.

Reasons Why Companies May Turn to Cloud Repatriation

As companies increasingly rely on cloud computing for their operations, many are beginning to consider repatriation for some of their applications/data. There are a variety of reasons for this trend:

Cost savings: Escalating cloud costs is a case for keeping certain assets on premises. Cloud computing costs can be hard to predict as they can change based on usage and other factors which can make it difficult for companies to budget for them. A high-profile example is that of Dropbox leaving AWS in favor of hosting their workloads themselves.

Security concerns: Enterprises may have concerns about the security of their data and operations in the cloud and may want to bring them back under their own control. At the end of the day, CIOs – not the cloud provider – are responsible for meeting security obligations.

Compliance requirements: Organizations may be subject to regulations that prohibit certain types of data or operations from being outsourced. The European Banking Authority, for example, requires an exit strategy for outsourced critical or important functions in its EBA Guidelines on outsourcing arrangements, including the use of the public cloud.

Performance issues: A company may experience poor performance or other technical problems with its cloud-based systems, especially as time goes on and data sets grow and integrations with other applications become increasingly important.

Vendor lock-in: Placing oneself in the hands of the hyper-scalers involves risks. A corporation may become too dependent on a single cloud provider, subjecting themselves to unreasonable rising fees or the fate of that provider (maybe they want to go back to just selling books, or what if they decided to sell customer data or metadata to marketing companies). Technology causes vendor lock-in as well – at least when it comes to proprietary technology vendors use to differentiate (i.e., your application has many dependencies on higher level PaaS offerings).

Cloud outages: While most public cloud providers deliver exceptional uptime on reliable services, even the dominant players in the market have experienced significant outages in recent years.

Customization needs: Organizations may have unique needs that cannot be met by the cloud providers’ offerings and may want to bring back certain operations in-house.

Data sovereignty: Companies may want to keep their data within a specific geographic location for legal or regulatory reasons. SaaS solutions, for example, provide little to no visibility into the underlying platform. This lack of visibility creates additional challenges – SaaS data management and the question of where it resides is a huge issue for many organizations.

Lack of control: Enterprises may feel that they have lost control of their data and operations in the cloud and want to bring them back under their own control. Or, a cloud provider might sunset a particular application or service, leaving the application team looking for a replacement solution.

Business continuity: A company may want to ensure that its data and critical applications are not dependent on a single cloud provider in case of outages or other disruptions.

Organizations that deploy applications on Azure, AWS, or Google Cloud, for all the reasons outlined above, should have a cloud exit strategy for any of the apps they implement on these clouds. Moving an app to a specific cloud provider is one thing; the question of whether you are making a potentially irreversible decision, is something else altogether.

Even if an organization never actually moves cloud workloads back on premises, an exit strategy can guide negotiations with providers and influence application design. Many organizations dislike the inability to negotiate the best prices from a cloud provider, which is well aware that the organization’s applications have a significant dependency on their services. Having a ready-to-go cloud exit strategy lets you take advantage of better pricing and more attractive discounts by giving you more leverage in financial negotiations. Simply put, a cloud exit plan is always necessary and shouldn’t be an afterthought.

The Importance of Automated Provisioning in a Cloud Exit Strategy

There are many resources available that detail what should be included in a cloud exit strategy. Usually they start with taking inventory of your cloud apps and their infrastructure elements, mapping dependencies (either manually or with a service mapping tool), re-examining SLAs so as to meet the contractual obligations outlined in SLA documents, and of course – the proactive testing of rebuilding a solution on prem that will ensure minimal downtime.

A critical part of the process is the constant provisioning of systems that can then be utilized during the repatriation process. Manual provisioning is an option, but it’s not only inefficient – it is also prone to errors that will disrupt the procedure and cause inconsistent results.

Automatic provisioning is the key to maximize efforts and deliver predictable outcomes. Automatic provisioning differs from legacy system imaging as it will produce a clean copy of the operating system and its patches, clean installs of the applications and the desired patch level, and configuration of the current security policies. This is opposed to cloning or restoring snapshots which doesn’t guarantee the current desired state. An advanced provisioning tool like Swimage will also restore data and system preferences for a complete build of a desired state.

Swimage offers the most sophisticated, hardware-independent provisioning tool on the market, purposely built for these types of situations. Many organizations use Swimage today for zero-touch, auto provisioning of whole lab environments initiated with a single click. This allows organizations the on-demand ability to move their workloads and data back to a more secure or compliant environment, or to take advantage of improved performance or cost savings. For the purpose of cloud repatriation and testing cloud exit strategies, the speed of getting all targeted systems to the desired operating state is crucial, and Swimage accomplishes this in under an hour vs days or weeks with other methods.

Takeaway

Although reasons for moving workloads and applications out of the public cloud vary, they fall into some common buckets. These include the desire to control costs, increase performance, visibility and control, and manage data in accordance with security and compliance regulations.

There is plenty of debate surrounding cloud repatriation and whether the movement is real. The hyper-scale vendors downplay it noting the flexibility/agility advantages of public clouds, while the datacenter incumbents point to the security and operational control benefits of self-managed infrastructure. While every cloud vendor references its ability to migrate workloads into its platform (as you would expect), they provide very few mentions of the feasibility of cloud exit strategies. Also, because many IT teams are stretched thin maintaining existing systems, a cloud exit strategy is often omitted from their cloud-migration planning processes.

Regardless, the movement of applications, workloads, and data between environments will not be a one-time event; it will become a standard IT practice. It’s a revolving door, not a boomerang.

Leveraging Swimage can make cloud repatriation a seamless process and reduce the burden related to cloud exit strategies. It provides a great vehicle for supporting workload portability and, consequently, a well-tested, validated, out-of-the-box cloud exit strategy.