The Steady Workloads Are Coming Home 

Cloud Repatriation: Why CFOs Are Bringing Workloads Back On-Prem 

In Brief 

• Cloud repatriation is moving workloads back from public cloud to on-premise or colocation. 

• It's widespread but selective. Most CIOs are repatriating some workloads; very few are exiting cloud entirely. 

• The driver is cost and predictability at sustained scale, plus control and data residency. 

• The end state is hybrid by design. Place each workload where it fits, rather than cloud-first by default. 

For a decade, "put it in the cloud" was the answer to every infrastructure question. Nobody asked it anymore; it was just the default. 

That default is now being corrected, and the person holding the pen is often the CFO rather than the CIO. In the most recent Barclays CIO survey, 86% of CIOs said they planned to move at least some public cloud workloads back to private cloud or on-premise, the highest figure the survey has recorded. 

This is not a stampede for the exit. Only around 8% of organisations are moving entirely off the cloud. What is happening is more interesting and more useful to understand: enterprises are deciding, workload by workload, that the cloud was never the right home for all of it. The steady, heavy, predictable workloads are coming home. And the reason is money. 

What Is Cloud Repatriation? 

Cloud repatriation is the movement of workloads and data from public cloud back to on-premise or colocation infrastructure. It is the reverse of the migration wave of the past decade. 

It is rarely all-or-nothing. Enterprises repatriate specific things, production data, backups, steady compute, while leaving plenty in the cloud. The shift is less about technology than about discipline: from cloud-first as a doctrine to workload placement as a decision. 

Why the Cloud Bill Stopped Making Sense 

Here is the moment that starts most repatriation projects. A CFO opens the monthly cloud invoice, and it is bigger than last month, again, for reasons nobody can fully explain. 

That is the real problem. Not that the cloud is expensive, but that it is unpredictable. The pay-as-you-go model that makes the cloud brilliant for variable demand makes it punishing for workloads that run flat out, all day, every day, because the meter never stops and the bill never falls. Add the egress charges, the instances left running over a weekend, the over-provisioning "just to be safe", and a large slice of the spend, by some estimates around a fifth, goes on resources nobody is really using. 

For a steady workload, this is the worst of both worlds: you rent forever, and you cannot forecast the rent. 

Owning the same workload flips both. The cost is higher up front, then it falls, and, just as importantly, you can predict it. For a finance team, predictability is not a nice-to-have. It is often the whole point. 

Why Else Are Enterprises Moving Workloads Back? 

Cost leads, but it is not alone. Three other reasons come up again and again. 

Performance and latency, for workloads that simply run better close to the data. Control over an environment you own and can tune rather than one you rent and must accept. And data residency, which for regulated Indian workloads increasingly points home, because keeping data in-country and provably under your governance is easier on infrastructure you own than on a shared, distant service. 

None of these, on its own, forces a move. Together, and stacked on top of an unpredictable bill, they tip the balance for a growing set of workloads. 

Which Workloads Come Home, and Which Stay? 

The pattern is consistent, and it is not ideological. Repatriate what runs constantly; keep in the cloud what flexes. 

A useful test: if you can predict a workload's usage a year out, you can probably own it more cheaply. If you cannot, the cloud's flexibility is worth paying for. 

Is This the End of Cloud? 

No. And anyone selling it that way is overreaching in the opposite direction. 

The data settles the point. The overwhelming majority of enterprises repatriating workloads are moving some, not all, and the cloud remains the right home for variable, experimental and globally-distributed work. What is ending is not the cloud. It is the habit of reaching for it without asking whether the workload belongs there. 

The destination is hybrid by design: the steady, sensitive base on owned or colocated infrastructure, the flexible layer in the cloud, each placed on purpose. 

The Catch: You Take Back the Operations 

Repatriation has a cost the spreadsheets often miss. When a workload comes home, so does the responsibility for running the infrastructure under it, the patching, the monitoring, the hardware, the recovery. 

For an organisation that shed those skills during the cloud years, that is a real consideration, not a footnote. It is also solvable. Colocation removes the facility burden while keeping ownership. Consumption-based and managed models keep the economics of owning without all of the operational weight. And a managed-services partner can run the repatriated estate so the saving is not eaten by new headcount. 

The point is simply to count this cost honestly. Repatriation that saves on cloud fees but doubles the operations burden has not necessarily saved anything. 

What It Actually Costs and Saves 

It depends on the workload, and it has to be modelled rather than assumed. 

Repatriation saves money when a workload's steady cloud cost over three years, plus the wasted idle spend, exceeds the cost of owning or colocating the equivalent, including the one-time move back and the operations. That is frequently true for genuinely steady workloads and frequently false for variable ones. There is no universal answer, only your numbers. 

So the honest recommendation is unglamorous: build a three-year, workload-level total-cost model before moving anything. The enterprises that repatriate well are the ones that did the arithmetic. The ones that regret it are usually the ones that moved on a slogan, in either direction. 

How to Repatriate Without Regretting It 

Start with the invoice, not the architecture. Find the workloads whose cloud cost is high, steady and predictable, and treat those as your candidates. 

Model each one properly, over three years, against owning or colocating it. Move the ones where the maths is clear, in stages, and leave the variable and experimental workloads exactly where they are. Plan for the operations before, not after, the workload lands. And treat the end state as a deliberate hybrid, not a round-trip back to 2010. 

Done this way, repatriation is not a reversal of strategy. It is the completion of one, the point at which the cloud stops being a reflex and becomes a choice. 

Right-Placing, Not Retreating 

Repatriation is easy to get wrong by treating it as a cause rather than a calculation. The value is in the disciplined analysis of which workloads genuinely cost less at home, the honest accounting for operations, and the staged move that does not disrupt the business. 

Proactive Data Systems helps Indian enterprises assess workload placement and build the on-premise, colocation and hybrid infrastructure to support it, and can operate the repatriated estate so the saving stays a saving. We are a Cisco Preferred Cloud and AI Partner, Dell Platinum Partner and NetApp Preferred Partner, with 35 years in enterprise IT, more than 1,500 organisations served, and a 24/7 service desk in India. To find which of your workloads belong back on-prem, you can ask Proactive for a workload placement and TCO assessment.

Disclaimer: This article is general information to support a strategic discussion, not financial, tax or investment advice, and Proactive is not a financial adviser. Cloud and on-premise costs vary by workload, utilisation and configuration, and change over time. Model the total cost on your own workloads, including operations, before repatriating, and confirm any accounting or tax treatment with your advisers.