How to Repatriate a Cloud Workload: Four Essential Considerations

It's not especially difficult to figure out why you should repatriate a cloud workload. If you've deployed an application to the cloud, then discovered that it's not meeting cost, performance, or other goals, you can make a clear case for repatriating it back on-prem.

But how to repatriate cloud workloads can be a more complicated question to puzzle. Moving workloads from the cloud back to on-prem is more complicated in many ways than moving them from on-prem to the cloud.

We can't tell you exactly how to repatriate your cloud workloads, of course, because every repatriation scenario is unique. But we can offer an overview of what to think about when planning and performing a repatriation. Keep reading for guidance on that topic.

Why Cloud Repatriation Planning Is Hard

Before diving into specific considerations for cloud workload repatriation, let's discuss why repatriation tends to be challenging.

The major reason is that businesses are primed to think in terms of getting workloads into the cloud much more than about how to move them back if they turn out not to be a good fit for the cloud. You can find thousands of articles, guides and best practice frameworks dedicated to cloud migration, but virtually no guidance that covers cloud repatriation.

Related:5 Reasons Cloud Repatriation Should Be Part of Digital Transformation

Likewise, there are virtually no tools designed to help with cloud repatriation. Cloud service providers offer a variety of solutions that can help you move applications and data into their platforms, but they almost never make it particularly easy to move workloads out of their platforms and back on-prem (which is understandable, given that they have no business incentive to help customers stop using their platforms).

What to Consider During Cloud Repatriation

This means that you're pretty much on your own when it comes to planning and implementing a cloud repatriation. You'll need to think through each of the major requirements on your own.

Let's look at those requirements, one-by-one.

Workload packaging

For starters, you'll need to think about how you'll package your workload such that it can move back on-prem.

The best way to do this will vary depending on how you operate your workload in the cloud and which hosting options you have available on-prem. If your cloud workload is a VM, you may be able to take an image of the VM and run it on-prem, provided you can support the same type of virtual machine on your own infrastructure. If it's a container, you could move the container images back on-prem, although you may need to modify their configuration to accommodate a different orchestration environment. One example in which configuration modification may be required is if you use ECS (a non-Kubernetes based container orchestrator) to run containers in the cloud but plan to use Kubernetes on-prem.

Related:Cloud Migration: A Recurring, Never-Ending Process

In other cases, you may need to repackage the workload entirely to get it to run on-prem. For example, serverless functions hosted on a cloud service like AWS Lambda can't be lifted-and-shifted back on-prem in many cases because there's no way to implement a Lambda-compatible service on your own infrastructure.

Networking

Networking, too, is likely to require some redesign as you repatriate your cloud workload. The network configurations that you'd typically use in the cloud can't be directly emulated on-prem. You'll have to set up your own on-prem subnets, VLANs, load balancers, firewalls, and so on, then update the configurations of the VMs or containers that host your workloads so that they work with your new network architecture.

Storage

Workloads that require massive amounts of storage, or that were designed to work with a specific type of cloud storage service, may also require updates during the repatriation process. You'll need to ensure that you have the on-prem storage infrastructure necessary to support the amount of data you'll be moving back on-prem. You may also have to convert storage resources like databases from cloud-based versions (such as Amazon Aurora) to types that you can operate on your own infrastructure (like MySQL).

Operations management 

Just as migrating to the cloud reduces the amount of responsibility you bear for managing physical infrastructure, repatriating from the cloud leaves you with more infrastructure to manage. As a result, you'll need to adjust your operations strategy.

You might need to hire more engineers, or modify the on-call scheduling of your existing team, so that you have the capacity to monitor and troubleshoot all of your infrastructure on your own.

You should also modify your operations strategy to ensure you're properly backing up and are prepared to recover on-prem systems. You should back up resources in the cloud, too, since even cloud environments can fail, but on-prem backup and recovery operations will require a different approach because you can't use the same tools and infrastructure as you would in the cloud.

Planning for Cloud Repatriation Success

Again, your mileage on the cloud repatriation front may vary, and there may be additional considerations to address that we haven't covered here. But at a minimum, you should make a plan for handling workload packaging, networking, storage, and IT operations to ensure a successful move from the cloud back on-prem.