Cloud repatriation: How to avoid this scenario and get it right first time

A 2020 IDC survey discovered that 80% of respondents had repatriated workloads from public cloud environments back to on-premise or to a private cloud environment. If you want to avoid this happening to you, it’s helpful to understand what’s driving cloud repatriation.

Not all businesses are repatriating workloads because of a poor experience in the public cloud. Sometimes the reasons are because of changes in the business or regulatory environment. For example, a business expanding into a new international market may need to repatriate some workloads from the public cloud because of regional data protection requirements.

However, some businesses are repatriating workloads because the public cloud hasn’t met expectations. Below are the most common reasons why.

Even NASA has been caught out by unexpected cloud costs! When using AWS to host its Earth Science Data and Information System (ESDIS) programme, the NASA boffins hadn’t factored in egress charges.

A 2020 audit report [PDF] from NASA’s Inspector General showed data download charges, when researchers and commercial users downloaded data from its programme, hadn't been correctly modelled. It predicted that its cloud spend would increase by $30 million per annum by 2025 because of this oversight.

Less well known organisations and businesses have also found the public cloud more expensive than predicted.

This can be down to over-provisioning, when you need more resources during high demand times and are unable to scale back when demand drops. It can also be a result of using more resources than you predicted, perhaps because specific workloads have larger requirements than you thought.

As mentioned earlier, sometimes new regulatory requirements may be the driver for cloud repatriation. This can be because of a change in the business strategy (such as international expansion) or, in some cases, because the company hasn’t properly understood their regulatory risk.

Regulatory requirements are generally not a barrier to cloud migration. The cloud service providers (CSPs) work closely with international regulatory authorities to ensure they are compliant, and specific services have been developed to meet requirements like PCI-DSS, GDPR and HIPAA.

Data locality or sovereignty can be an issue, but most CSPs offer specific geographical locations for data storage. Once again, it’s all down to planning and being aware of these requirements before you select your cloud services and start migrating data to the cloud.

The cloud is often more secure than an on-premise solution, so security really shouldn’t be a barrier to digital transformation. But just as you're responsible for deploying the right tools and policies for protecting your on-premise environment, you’re also responsible for securing your cloud environment.

CSPs and security partners provide the tools you need, but it’s down to you to deploy them and correctly configure your cloud infrastructure.

Cloud repatriation because of security concerns is often a result of misconfiguration where the business experiences a data loss or breach. Instead of reconfiguring the cloud infrastructure to properly secure its data, there’s a knee jerk reaction (generally instigated by senior business leaders) to return to on-premise.

Since the cloud can deliver significant security benefits, especially for businesses that don’t have internal cybersecurity expertise, it really pays to invest resources in correctly configuring your cloud infrastructure from the start.

Another reason for cloud repatriation is network latency. That’s when it takes too long for data to pass from one point on the network to another. For example, if an end user wants to open a document or access an app, they experience a lag between triggering the request and the document or app opening.

This has a detrimental impact on productivity and the performance of business critical apps.

The issue can be resolved either by repatriating specific workloads that have a tendency towards latency to on-premise, or optimising the network.

If you haven’t migrated any workloads to the cloud and want to avoid this scenario a cloud readiness assessment will a) flag up any workloads that are problematic, and b) assess whether your network is cloud ready. You can then decide whether a hybrid cloud model with some workloads remaining on-premise and some in the cloud is the best option, or explore how to optimise your network ahead of your cloud migration.

Data discovery is essential before you migrate to the cloud. You need to know what you have, what it looks like, where it is and if it is best placed in the cloud. If you don’t do any data discovery you risk moving a mess from on-premise to the cloud - which will cost you money.

Data storage can be expensive. Cloud service providers price data storage in different tiers which are based on factors such as performance and availability. Therefore you want data in the right tier to optimise costs. For example, data that you store for compliance reasons and no longer use, shouldn’t be in a high availability tier as this will be more expensive. In fact, it may be more cost effective to store data for archiving purposes on-premise.

The common theme of all these reasons for cloud repatriation, is poor planning. Cloud repatriation, and the costs associated with it, can be avoided if you invest time in planning before you migrate anything to the cloud.

However, it’s not too late if you’ve already started that process! Cloud optimisation can help you manage costs, identify vulnerabilities and resolve networking issues.

You may still decide to repatriate some workloads and operate a hybrid cloud model, while the workloads remaining in the cloud deliver the ROI you expected from the start.