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.
While many boasts the benefits of cloud, it isn't necessarily the best place for all applications. Some enterprise may not like the loss of control from what they were used to on premises. Enterprises could also lose visibility because of the limited capabilities from provider tools. Even cost can be an issue when egress rates rise due to the amount of data traveling outside the provider's cloud. Whatever the reason, you do not have to stay in cloud.
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 may 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. Learn how to perform a reverse migration to get cloud-based apps back on premises.
1. Prepare a budget
Moving a workload back on premises may require on-prem hosting infrastructure that you do not currently have in place. Invest in network upgrades and new monitoring, observability and/or security tools to help support your on-premises workloads. In some cases, you may 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 may need to convert data to get it back on premises.
4. Back up app
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 are able to complete a successful migration to the on-premises environment. Still, make a formal plan so that 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 may want to consider alternative data transfer services, such as AWS Snowball.
7. Validate the new application instance
When your data and app are back on premises, run checks to ensure they perform as required before you take them live. Make sure that 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 may 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 may 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-based instance.
This process will typically involve updating DNS records so that they point to right instance of your app. You may also need to configure load balancers and firewalls to direct traffic properly to the on-premises application instance.