8 key steps of a cloud exit strategy
If your cloud-based workloads and applications need to move back on premises, you'll need a plan. Start your reverse migration with this step-by-step guide.
There are many benefits to entice organizations to migrate to the public cloud, such as the potential to reduce operational complexity and cut costs. But cloud services aren't necessarily the best place for every workload. Sometimes, the cloud ends up costing more than expected or delivering lower levels of performance. Compliance requirements might make it more difficult than expected to operate in the cloud.
Whatever the reason, you don't have to stay in the cloud. You can "repatriate" workloads back on premises by developing and executing a cloud exit strategy.
Exiting the cloud can be just as complicated as moving to the cloud in the first place. But if you plan the process in a systematic way and anticipate the challenges you might run into, it's possible to move applications from the cloud back on premises without disrupting users or losing data.
If your organization has doubts about whether a cloud-hosted application is meeting expectations, a cloud exit strategy is worth considering. Read on to learn how to perform a reverse migration to get cloud-based apps back on premises.
This article is part of
What is cloud management? Definition, benefits and guide
What is a cloud exit strategy?
A cloud exit strategy is a plan for migrating cloud-based workloads to an on-premises environment. Put another way, it's cloud migration in reverse.
A cloud exit strategy should address several key considerations for moving workloads out of the cloud:
- Which data, applications and other resources will exit the cloud, and whether some workloads might remain in the cloud after others have left.
- The on-premises infrastructure resources that are necessary to support the workloads you're repatriating from the cloud.
- The staff resources required to perform a cloud exit.
- The set of processes and procedures that the business will undertake to complete its cloud exit.
The process of exiting from the cloud is sometimes called cloud repatriation. The analogy behind the term is that cloud repatriation is similar to repatriating a person who left their country of origin.
Why is having a cloud exit strategy important?
Developing a cloud exit strategy is important because migrating workloads out of the cloud can be at least as complex as migrating them to the cloud. Without a systematic cloud exit plan in place, it's challenging to ensure that the migration proceeds smoothly and doesn't disrupt business continuity. A business could run into issues like forgetting to repatriate certain workloads or failing to acquire sufficient on-premises resources to support workloads when they exit the cloud. And, although cloud vendors provide tools to help migrate workloads to the cloud, they offer almost no tools to streamline the process of exiting the cloud.
Cloud exit strategies are also valuable because cloud services don't always turn out to deliver the value that organizations hope for when they move workloads into it. In theory, the cloud can help make workloads more scalable and improve performance by providing on-demand access to virtually unlimited infrastructure resources. In addition, the cloud is often touted as a way to reduce operational complexity by eliminating the need to manage physical infrastructure.
In practice, however, the benefits that organizations hope to achieve by migrating to the cloud don't always live up to the reality. In some cases, cloud workload performance is actually worse due to issues like poor configurations or the ability to take advantage of bare-metal hardware in on-premises data centers. The cloud can also prove less cost effective because of the challenges of navigating complex cloud pricing rules and avoiding the many "hidden" fees -- such as data egress charges and data request costs -- that can add to cloud bills. Compliance requirements can also complicate use of the cloud. For instance, new compliance rules might require an organization to ensure that its data resides in a certain geopolitical jurisdiction, which is not always possible when using the cloud.
When organizations find themselves in situations like these, they might decide that moving back on premises is the best way to achieve their goals. In that case, having a cloud exit strategy is paramount.
8 steps to create a cloud exit strategy
Developing a cloud exit strategy is a multistep process that includes planning what it will take to migrate out of the cloud, performing the migration and then validating that your workloads function properly after they're back on premises.
Here are the key steps for creating a cloud exit strategy.
1. Prepare a budget
Moving a workload back on premises can require on-premises hosting infrastructure that you don't currently have. You'll need to invest in network upgrades and new monitoring, observability and security tools to help support the on-premises workloads. In some cases, you might need to add staff.
Make sure you can allocate sufficient budget to support workloads once they are back on premises. Without proper financial preparation, you risk repatriating the workload without being able to support it once it's out of the cloud.
2. Prepare your team
If needed, make organizational changes to your team. Designate engineers to take charge of the migration project. Be sure to assign certain team members to support the app once it's back on premises, especially if you previously eliminated or reduced on-premises infrastructure support as part of a migration to the cloud. It's critical to guarantee you can bring an application back or expand it as part of the cloud repatriation process.
3. Back up data
If your cloud-hosted app creates or manages persistent data, you'll need to back up that data. The way to do that will vary depending on how the data is stored. If data lives in a database, you can take a snapshot of the database. Object storage data can be copied to external storage to create backups.
Be sure that the data backups are compatible with the data technology you plan to use to support the app once it's back on premises. Some proprietary cloud-based databases and data storage services don't have equivalents that you can run yourself on premises. You might need to convert data to get it back on premises.
4. Back up the application
The backup process will vary depending on how your application is deployed. If it's a containerized app, you can move the container images on premises without going through a complicated snapshotting process. To back up an application that is hosted directly on a VM, take a snapshot of the VM. Then convert the snapshot to a format you can host on premises.
You might choose to redeploy a new instance of your application on premises rather than attempting to migrate the cloud-based instance to your environment. This approach makes sense if the cloud-based app would be too difficult to snapshot or if you want to update to a newer version of the app than the one you have running in the cloud.
5. Prepare for emergencies
Prior to beginning the actual migration process, prepare for emergencies that could disrupt it, such as a power outage or network failure. These contingencies are rare but possible. Create a backup plan in case the migration fails or takes longer than expected.
The backup plan can amount to keeping the cloud-based instance of the application running until you can complete a successful migration to the on-premises environment. Still, make a formal plan so you don't panic if the migration doesn't go as smoothly as anticipated.
6. Perform the migration
Using the data and application backups, you can begin the migration. In most cases, you'll be able to migrate the data and application images to your on-premises environment over the network. If you have large volumes of data, you might want to consider alternative data transfer services, such as AWS Snowball.
7. Validate the new application instance
When your data and application are back on premises, run checks to ensure they perform as required before you take them live. Make sure there is no data corruption and that the state of your on-premises data is consistent with that of the cloud-based instance.
This can be tricky if your application remained operational during the migration process. It might be possible to perform a quick sync using a tool such as Rsync to align both versions of the data.
Load tests can ensure that your on-premises application can handle the traffic you expect to toss at it. Security scans are valuable for catching vulnerabilities or configuration risks you might have missed during migration.
Optional step: Expose the new app to canary users
Instead of redirecting all application requests to the on-premises app at once, consider a canary strategy. This will redirect traffic from some of the application's users to the new app while relying on the cloud-based instance to handle other requests.
With this approach, problems won't affect all users. You'll be able to fall back to the cloud-based app instance quickly in the event of serious trouble.
It can be complicated to redirect only some users to a certain application instance, so a canary strategy might not be worth the effort in all cases.
8. Take the app fully live
If your on-premises app has passed all validation checks -- and, if applicable, performed adequately for your canary users -- you can redirect all application requests to the on-premises instance. Then you can shut down the cloud instance.
This process will typically involve updating DNS records so that they point to the right instance of your app. You might also need to configure load balancers and firewalls to direct traffic properly to the on-premises application instance.
Chris Tozzi is a freelance writer, research adviser, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.
