Cloud repatriation: when it pays and when it doesn't

Workload repatriation, meaning moving applications or data out of the public cloud and into your own datacenter or a colocation provider, is coming up more and more often. Sometimes the conversation starts with a bill that grew faster than the business; other times with a data sovereignty requirement or a change in strategy. In almost every case it is framed as a position: "the cloud is more expensive" or "going back is a mistake".

Both statements are too broad to be useful. The cloud and your own infrastructure have different economics, and each workload fits one or the other better depending on how it behaves and how it is built. This article proposes a way to decide workload by workload, with no dogma in either direction.

Why the question is coming up now

There are three reasons worth separating. The first is financial maturity: many organizations that migrated quickly now have several years of consumption data and can compare with real numbers rather than estimates. Practices such as those in the FinOps Foundation's FinOps Framework help make that analysis systematic rather than reactive.

The second is the cost of leaving. Moving data out of a provider has a price, and that charge has historically been a barrier to switching. That is changing, through regulation and through the providers' own decisions, as we will see below.

The third is sovereignty. Industries such as banking, insurance and healthcare, in Latin America and in Spain, face requirements on where certain data is stored and processed, and who can access it. Sometimes a suitable cloud region exists; sometimes it does not.

None of the three reasons alone means you should repatriate. They mean the decision deserves an explicit analysis.

Two axes to classify each workload

As a first filter, we recommend placing each workload on a matrix with two axes.

• Demand predictability. A stable workload, with similar consumption month after month and foreseeable growth, gets little out of the cloud's elasticity. A workload with seasonal peaks, campaigns or uncertain growth gets a lot out of it.
• Dependence on managed services. A workload running on virtual machines or containers with standard components can be moved with relative ease. One that uses proprietary managed databases, queues, serverless functions, or the provider's analytics or AI services would have to rebuild those capabilities elsewhere.

The matrix does not decide; it sorts. A workload in the "repatriation candidate" quadrant may still be better off in the cloud for reasons of resilience, talent or speed of change. And a workload in "stay in the cloud" may have to leave because of a sovereignty requirement. What it does is prevent two common mistakes: repatriating an elastic workload that will need oversized hardware for its peaks, and repatriating a workload that depends on managed services that would have to be replaced one by one.

Total cost, not just compute

The most common argument for repatriation compares the monthly compute bill with the price of equivalent hardware. That comparison almost always leaves out half the costs on each side. The table below summarizes the factors to include.

Factor	In the cloud	On your own infrastructure
Compute and storage	Pay per use; discounts for usage commitments	Hardware amortization, sized for the peak rather than the average
Data transfer	Egress to the internet and between regions is charged; ingress is generally free	Connectivity and transit contracts; one-time cost of the migration
Licenses	Included in some managed services	Own licenses and support; per-core or per-host licensing rules
Staff	Platform and FinOps team	Hardware, network and storage operations, on-call, hiring and retention
Datacenter	Included in the price	Space, power, cooling and physical security, or a colocation contract
Refresh cycle	Handled by the provider	Replacing servers, storage and network every few years
Managed capabilities	Backup, monitoring and high availability available as a service	Replacing them with your own tools and processes

An illustrative example. Suppose a workload costs 20,000 units a month in cloud compute and equivalent hardware, amortized, costs 8,000 a month. Repatriation looks obvious. But add 4,000 for space and power, 6,000 for additional staff and 2,000 for licenses and support, and the monthly difference disappears, before counting the one-time migration cost. With other assumptions the result could be the opposite: the point is that only a complete comparison, over three to five years and including the refresh cycle, is good enough to decide.

Before comparing, exhaust optimization in the cloud first: remove unused resources, adjust sizes and use usage commitments for the stable baseline. A workload that is poorly sized in the cloud will also be poorly sized when it is repatriated. And staff cost should be measured as rigorously as automation savings, as we explain in measuring the value of automation.

Latency, sovereignty and regulation

It is not all about cost. Some workloads come back, or should never have left, for technical or regulatory reasons.

• Latency. Systems that exchange large volumes of data with applications that remain in your own datacenter, or that need very low response times to local equipment, may work better close to them. The reverse also holds: splitting an application across two environments can create cross traffic that hurts both latency and cost.
• Sovereignty and data location. If regulation or the supervisor requires certain data to remain in the country and no cloud region meets that requirement, the decision is made. Before assuming so, validate with Compliance exactly what the rule requires.
• Concentration and exit. In financial services, supervisors expect the institution to be able to exit a critical provider. That requirement does not force repatriation, but it does require the exit to be viable, as we discuss in cloud governance in financial services.

In the European Union, Regulation (EU) 2023/2854, known as the Data Act, changes the cost of leaving. It entered into force on January 11, 2024 and will apply generally from September 12, 2025. Its chapter on switching between data processing services will require providers to make it easier for customers to move to another provider or to their own infrastructure, and it phases out switching charges, which include the data egress charges tied to switching. From January 11, 2024 until January 12, 2027, providers may only impose reduced charges that do not exceed the costs directly linked to the switching process; from January 12, 2027 they may not impose them at all.

Two important nuances. First, the regulation addresses the switching process, not the egress traffic of day-to-day operations, which is still charged according to each provider's price list. Second, some providers have already announced, on their own, egress fee waivers for customers moving their data out; AWS, for example, published one in March 2024, with conditions and a prior request. Check your provider's current terms and validate with Legal how the regulation applies to your contracts.

Execution risk

A repatriation is a migration, with all its risks, in a direction the team no longer practices. The points most often underestimated are:

• Lost capabilities. Monitoring, backup, cross-zone high availability and identity management come built into the cloud. Outside it, each one is a project. If observability changes platform, the selection deserves its own analysis, as we explain in how to choose an APM platform.
• Hardware lead times. Buying, receiving, installing and certifying equipment takes months. During that time you pay for the cloud and invest in the new infrastructure at once.
• Talent. Operating hardware, storage and physical networks requires profiles that many organizations reduced when they migrated.
• Operating procedures. Runbooks and automation written for the cloud do not work as is. Rewrite them as code from the start, following the logic of moving from runbook to playbook.

How to decide, workload by workload

1. Inventory and measure. For each workload, gather at least twelve months of consumption, its demand pattern and the list of managed services it uses.
2. Place it on the matrix. Rule out early those in the stay or optimize quadrants, unless there is a regulatory requirement.
3. Optimize first. Adjust sizes and commitments in the cloud and measure again. The comparison should be against the best version of the cloud, not the current one.
4. Calculate total cost over three to five years with every factor in the table, including the migration and the refresh cycle.
5. Assess execution risk and the reverse exit plan: if the decision turns out to be wrong, how much does it cost to go back?
6. Decide and review. Document the assumptions and review them at least once a year, because prices, regulation and architecture change.

The most common outcome of this analysis is neither "everything to the cloud" nor "everything back", but a mixed portfolio, with each workload where its economics and requirements place it best. For decisions with a material impact on cost or compliance, involve Finance, Risk and Compliance before committing investment.