Cloud Repatriation: Example + 9 Considerations for Migrating from Public Cloud to Private, On-Prem + Hybrid

If you moved to the cloud hoping for cost savings and scalability only to find that your cloud costs are ballooning, your cloud performance isn’t up to snuff, or you’re always struggling to align compliance regulations with your cloud deployment, it might be time to look into cloud repatriation as an alternative to public cloud infrastructure.

If you’re moving anything from public cloud to private cloud or on-prem infrastructure, you’ll need to know a bit about the phenomenon of cloud repatriation. Here’s an overview of what cloud repatriation is, what it looks like, and how to cover your bases before doing it with your cloud infrastructure.

What is Cloud Repatriation?

Cloud repatriation is the process of moving apps, services, and data off of public clouds (like AWS, Azure, or GCP) and back to data centers, on-premises, private cloud, or a hybrid setup. Companies choose cloud repatriation to reduce cost, improve privacy, and meet changing business needs.

The Reasons Cloud Repatriation is Trending + Drivers of Reverse Migration

Common reasons for cloud repatriation include cost, data privacy, security, compliance, performance, and avoiding vendor lock-in. Cloud repatriation usually follows a change in business strategy, when an organization reconsiders its cloud deployment model.

Cloud repatriation is trending in the 2020s because many organizations feel they moved to the cloud too much, too quickly during the COVID-19 pandemic.

With a growing need for cloud services that could be accessed by a remote workforce, organizations invested in public clouds for their apps, workflows, and data. Those companies adopted public cloud providers like AWS, Azure, and GCP at an astonishing rate, sold on its availability, cost savings, and ease of adoption.

But more recently, as business strategies and needs have changed, some companies are finding that their public cloud deployments might not be aligned with their goals for a number of reasons.

Common Reasons for Cloud Repatriation

When companies decide to move off their public cloud environment, it’s often due to one of these reasons:

• Cost: Costs of computing, storage, ingress/egress (data transfer), networking, licensing, management, and more are determined by the cloud provider, and are subject to inflation and fluctuating costs. A strategic cloud repatriation can help keep costs down.
• Privacy and compliance: Using a public cloud to host sensitive data raises a lot of security questions, including where in the physical world the data is stored, who has access to it, and what happens in the event the cloud provider experiences disruptions or goes out of business. Ensuring compliance with relevant regulations is also a concern for public cloud users – they have to be sure that the public cloud they’re using can be configured to meet compliance standards like GDPR, HIPAA, and PCI DSS.
• Misconfiguration: When moving on and off the cloud, oversights and missteps that would otherwise have limited effect are suddenly much more impactful. In 2022, one misconfigured AWS S3 bucket exposed 3.2 million files of sensitive data at a Turkish airline, including flight data, source code, and personal info on airline crew.
• Performance: Public cloud can be less than ideal for workloads that need high-performance computing with low latency. Cloud repatriation can help boost performance by letting organizations pick a different cloud hosting option or moving affected resources off the cloud.
• Vendor lock-in: When you choose a public cloud provider for SaaS, PaaS, or IaaS, you’re dependent on that provider for it. Essentially, that means you need to keep paying them for access to the software, platform, or infrastructure you use up there.
• Skill gaps: A lack of deep technical know-how in the cloud tools you're using can put a huge bottleneck on your IT ops. If your team or SME is well-versed in just one vendor’s tech – say, they’re an expert in GCP but slower with AWS – that could also make your vendor lock-in problems worse.

Multi-cloud deployment is a great way to avoid being locked in to one vendor’s terms >>

Cloud Repatriation Examples: What Cloud Repatriation Really Looks Like

Real examples of cloud repatriation include Dropbox and Adobe. Both companies moved a significant portion of their infrastructure onto Amazon AWS before moving it to a combination of on-premises and hybrid cloud providers.

Cloud repatriation isn’t quite a trend yet. Many companies are comfortable with their existing public-only cloud deployments – it suits their needs from the perspectives of pricing, performance, and compliance. But for some companies, the rush to the public cloud was made without consideration for the long-term implications of public-only cloud deployment.

Dropbox is a real-world example of a company that decided to move most of its computing off of the public cloud. The company’s infrastructure was originally built on Amazon AWS, but in 2016, the company announced it had moved 90 percent of its customer data to custom-built hybrid cloud infrastructure.

In Dropbox’s case, cloud repatriation was primarily about saving money by optimizing their infrastructure. (It also happened before the COVID-19 pandemic, so there was a bit of shot-calling on Dropbox’s part.)

Of course, not every company has the time, resources, or infrastructure experience to build custom infrastructure for 900 petabytes of data. So let’s examine a fictional example of cloud repatriation to illustrate the concept:

• Company A chose Cloud Provider 1 to help scale their business.
  • They moved apps, databases, storage – pretty much everything.
  • At first, it seems like it’s paying off: Company A employees can access resources from anywhere and it’s less expensive than managing on-premises infrastructure or private cloud resources.
• Over time, Company A starts to notice issues.
  • Their bills from Cloud Provider 1 have been growing unexpectedly. Fluctuations in price and inefficient cloud resource management have led to unnecessary spending – and it’s getting a little out of hand.
  • Cloud Provider 1’s latency is higher than Company A was used to with their old infrastructure. That makes it hard to get the data and resources they need when they need it for efficient, effective operations.
  • Company A has to comply with customer data regulations, which say Company A has to store customer data in its country of operation. Cloud Provider 1 is global, so some data will have to be moved off its cloud and back to on-premises or data centers.
• Company A decides to move data, workloads, and resources back to its own infrastructure.
  • Company A conducts a cost analysis, migrates data back to their on-premises data center and additional cloud providers, and re-optimizes its apps to run on their own servers.
• As part of their cloud repatriation, Company A adopts a hybrid cloud strategy, rather than ditching public cloud completely.
  • In it, their infrastructure comprises Cloud Provider 1, Cloud Provider 3, and their own on-premises and private cloud infrastructure.
  • They use Cloud Provider 1 for their customer-facing web apps because it’s fast enough for that purpose.
  • They use Cloud Provider 3 because it can support Company A’s need to scale.
  • By adding on-premises infrastructure back into the mix, Company A can ensure security and compliance in hosting its most sensitive data.

It’s a simplified example, but those are the basic parts of a cloud repatriation effort. But what’s right for Company A isn’t going to be right for every organization. Each company considering cloud repatriation has to strike a balance between efficiency, availability, effectiveness, and security in its combination of cloud and on-premises hosting.

9 Considerations for Cloud Repatriation

When planning a move off a single cloud to a multi-cloud or hybrid environment, you should consider how much you need to move, your ideal split between public, private, and on-premises, and how you’ll keep your infrastructure consistent and secure during and after the transition.

Cloud repatriation is no small endeavor. You could be managing a few dozen, a few hundred, or many thousands of resources, and you’d still need to cover a lot of bases before you can safely migrate infrastructure from public cloud to a multi-cloud or hybrid mix.

Cloud Repatriation Pitfalls to Avoid

Here are some considerations for moving some of your apps, workloads, and data off the cloud.

• Read the fine print on your cloud vendor contracts. Review contracts with cloud providers to understand any penalties, fees, or notice periods associated with reducing or terminating services.
• Know your egress fees. While reviewing contracts, be particularly aware of data egress fees, which your public cloud provider may leverage on your way out.
• Address interdependencies. Some applications might have dependencies on cloud-native services. Consider how you'll address them after migration.
• Prepare for downtime. Cloud migration and repatriation take time. Chart the business impact of potential service interruptions or downtime and be sure to let customers and other stakeholders know how their service will be impacted.
• Don’t skip security checks. Document your security protocols and ensure that data remains secure during the transfer and once it's in your new environment.
• Double-check compliance. Depending on your industry, you might be subject to regulations that dictate where and how you can store certain kinds of data (like personally identifiable information). Check your compliance scores and know the impact of migrating to ensure that moving your infrastructure (including data storage) to a new environment doesn't run the risk of violating any regulations.

Important Questions to Ask Before a Cloud Repatriation

The above is more or less a pre-migration checklist. But there are some more subjective cloud repatriation considerations that are just as important to formalize before you go through the effort.

• What do you need to move off the cloud and why? Knowing what you’re moving and why will help you define a better infrastructure model for the future. What’s prompting your move away from your current cloud setup? Are you dissatisfied with the cost? Is compliance hard to manage? Is it slower than you thought? Are a certain vendor’s terms of service unsatisfactory? Use those answers to pick vendors, build SLAs, and map out your ideal infrastructure environment before you get started with the actual repatriation.
• How will you keep your infrastructure consistent during and after the migration? Policy as code (PaC) helps control cloud misconfiguration, which is a persistent problem in cloud ops and can leave cloud infrastructure vulnerable. Infrastructure as code (IaC) makes it easier to recreate infrastructure in your new environment. Container orchestrators like Kubernetes help manage applications across your existing environment and onto your new environment.
• How will you make sure your new environment doesn’t fall prey to the same things your original one did? Cost, performance, and compliance are among the top reasons organizations choose to go through cloud repatriation. Automated configuration management and desired state enforcement through policy as code can ensure consistency in your new environment and help you avoid repeating the same mistakes.

Using Automation + Configuration Management to Conduct a Smooth Cloud Repatriation

Moving infrastructure anywhere – on and off public cloud, mixing in private and on-prem – relies on automation for efficiency and configuration management for consistency. Automation streamlines routine repatriation tasks (provisioning, scaling, updating), while configuration management enforces a desired state (ensuring security, meeting compliance, and mitigating drift along the way).

Get a demo of Puppet automation and configuration management in action, or get in touch with the Pricing team to start planning your perfect multi- or hybrid cloud infrastructure with Puppet.

GET A DEMO    PUPPET PLANS + PRICING