Cloud Repatriation Is Not a Retreat: Workload Placement as a Delivery Discipline
Cloud repatriation is rising, but the headlines miss the point. The unit of decision was never the estate, it was the workload. Here is how delivery leaders should run placement as a continuous portfolio discipline, plus the unit economics, data gravity, and exit costs that decide where each workload actually belongs.
Somewhere in your organization there is a slide from three or four years ago with a green checkmark next to "Cloud Migration: Complete." That slide was wrong the day it was made. Not because the migration failed, but because migration was never the right unit of work. A migration has a destination and a finish line. The decision you were actually making, over and over, was where each individual workload should run given its cost, its data, and its risk. That decision never finishes. It is a standing portfolio question, and the organizations treating it that way are quietly pulling ahead of the ones still hunting for a finish line.
This matters right now because the market has turned the question into a headline. Cloud repatriation, the practice of moving workloads back from public cloud to private cloud, colocation, or on-prem, has gone from a contrarian blog post to a board agenda item in about eighteen months. And like most things that become a headline, it is being badly misread in both directions. The maximalists are declaring the public cloud a mistake. The defenders are calling repatriation a fad. Both are wrong, and the data says so plainly.
The Exodus That Isn't
Start with the numbers, because they puncture both narratives at once.
The Barclays CIO Survey at the end of 2024 found that 86 percent of CIOs planned to move at least some workloads from public cloud back to private or on-prem environments, the highest reading that survey has ever recorded. Flexera's 2025 State of the Cloud report found that 21 percent of workloads and data had already been repatriated, and that 84 percent of organizations name managing cloud cost as their single biggest cloud challenge. Read only those figures and you would conclude the cloud era is ending.
It is not. In the same window, Gartner put worldwide public cloud end-user spending at roughly 723 billion dollars for 2025, up 21 percent year over year, and forecast it to climb toward 850 billion in 2026. IDC's data explains how both things are true at once: only about 8 percent of organizations are moving their entire estate off the cloud. Repatriation is real, it is growing, and it is almost entirely selective. Teams are pulling specific workloads home while pushing others deeper into public cloud, frequently in the same quarter.
That last point is the whole game. The story is not cloud versus on-prem. The story is that placement has become a per-workload decision, and most organizations have no discipline for making it. They migrated as a program, with a project plan and a go-live date, and then they stopped thinking. The bill kept arriving.
Why "Migration" Was the Wrong Mental Model
The all-in cloud era trained a generation of leaders to think in one-way doors. You picked a provider, you committed, and reversing course was treated as an admission of failure. That framing was useful to the people selling reserved-instance commitments and three-year savings plans. It was never useful to you.
A workload is not loyal to a venue. A batch analytics job that runs hard for six hours a night has completely different economics from a customer-facing API that needs to absorb unpredictable spikes, and both differ from a petabyte-scale data lake that almost never moves. Treating all three as members of one "cloud estate" with a single placement is how you end up overpaying for two of them. The estate was a financing and governance convenience. It was never the right unit of technical or economic decision making.
The shift I am asking you to make is small to describe and hard to operationalize. Stop asking "are we a cloud company or an on-prem company." Start asking, for each meaningful workload, "given what this thing actually does, where should it run this year, and what would have to change for that answer to change." That is a portfolio question, and portfolios get rebalanced. They do not get finished.
The Unit Economics Nobody Modeled
Here is the part the original business cases skipped. Public cloud pricing is, in effect, a pay-per-use model with an elasticity premium baked in. You pay more per unit of compute and storage in exchange for the ability to scale to zero and back without owning the hardware. For spiky, unpredictable, or low-average-utilization workloads, that premium is a bargain. For steady, high-utilization workloads that run flat-out month after month, you are paying a premium for elasticity you are not using.
There is a crossover point on every workload's cost curve. Below it, cloud is cheaper because you only pay for what you burst to. Above it, owned or reserved capacity wins because the fixed cost amortizes across high steady usage. Most organizations never plot the curve, so they never notice which side of the crossover each workload sits on.
The clearest public example is 37signals. After its annual cloud bill ran past 3.2 million dollars, the company moved its core workloads onto owned hardware and cut that bill to about 1.3 million, a swing of nearly two million dollars a year. It then spent roughly 1.5 million dollars on 18 petabytes of storage hardware that costs under 200 thousand dollars a year to operate. Its founder now projects more than ten million dollars in total savings over five years. You should not copy that decision, because your workloads are not their workloads. You should copy the rigor: they knew exactly where their workloads sat on the cost curve, and they acted on it.
This is also where the AI bill enters the picture. Inference and training are compute-heavy and data-hungry, and they have data gravity that makes naive public-cloud placement expensive fast. I made the broader case for treating model spend as an engineering concern in FinOps for AI, and workload placement is the structural half of that same problem. You cannot govern a cost you have not located.
Data Gravity and the Exit-Cost Trap
If unit economics decided everything, placement would be a spreadsheet. It is not, because two forces resist movement: data gravity and exit cost.
Data gravity is the tendency of large datasets to pull compute toward them. The more data a workload depends on, and the more other systems depend on that data, the more expensive and risky it is to move. A stateless service is a feather. A 30-terabyte transactional database with forty downstream consumers is a boulder. Placement decisions that ignore gravity produce migration plans that look clean on a slide and detonate in production, because nobody mapped what actually depends on what. This is exactly the dependency-first analysis I argued for in dependency density; you cannot safely move what you have not mapped.
Exit cost is the other anchor, and for years the providers engineered it deliberately. Egress fees, the charges for moving your own data out, were the moat. That moat has cracked. Under pressure from the European Data Act, Google waived data-transfer-out fees for departing customers in early 2024, AWS and then Microsoft followed within weeks, and the Data Act will bar providers from charging egress or switching fees at all from January 2027. The caveats matter, most of the waivers require you to fully leave a service, but the direction is unambiguous: the financial penalty for moving a workload is falling, which means the cost of being wrong about placement is falling too. Reversibility is getting cheaper. Your strategy should price that in.
A Placement Framework, Not a Migration Plan
You do not need a thirty-page strategy. You need a repeatable way to answer one question per workload: where should this run, given its demand shape and its data gravity. Two axes get you most of the way.
Spiky demand, low data gravity is the public cloud's home turf. Bursty, stateless, unpredictable workloads earn the elasticity premium every month. Leave them there and stop apologizing for the bill; you are buying something real.
Steady demand, low data gravity is the prime repatriation and cost-optimization candidate. Predictable, portable workloads running flat-out are usually sitting on the wrong side of the cost crossover. Reserved capacity, a private platform, or owned hardware will almost always beat on-demand pricing here.
Steady demand, high data gravity points toward on-prem or colocation. When the data is heavy, predictable, and rarely moves, owning the infrastructure underneath it tends to win on both cost and control.
Spiky demand, high data gravity is the genuinely hard quadrant, and it is where sovereign and hybrid architectures earn their keep. The honest answer is often to split the workload: keep the gravity-bound data on owned or sovereign infrastructure and burst the elastic compute to public cloud. It is more complex, and sometimes complexity is the correct price for a workload that is both bursty and data-bound.
The point of the matrix is not precision. It is to force a per-workload conversation that the "are we a cloud company" framing actively suppresses.
Running Placement as a Delivery Discipline
A framework you apply once is just a slide. The leaders getting value from this are running placement as an operating discipline with a cadence, an owner, and a design constraint. Three practices separate them from everyone else.
Put placement on a cadence
Inventory your significant workloads and review their placement on a schedule, quarterly for the expensive ones. Each review answers three questions: where does this sit on its cost curve now, has its demand shape or data gravity changed, and what would have to be true to move it. Most workloads will not move in any given quarter. The discipline is in looking, not in churning. A placement decision you have not revisited in two years is not a decision, it is an assumption collecting interest.
Make reversibility a design constraint
The cheapest workload to place correctly is one that was built to move. With egress fees falling, the remaining lock-in is architectural: proprietary managed services, undocumented data dependencies, and infrastructure defined by clicking in a console instead of in code. Treat portability as a first-class non-functional requirement for anything material. You are not committing to move every workload. You are buying the option to move it cheaply when the economics shift, and the economics will shift.
Give placement a real owner
Placement falls in the seam between FinOps, platform engineering, and architecture, which is precisely why it gets neglected. Someone has to own the portfolio. In the organizations that do this well, the platform team runs placement as part of running the platform as a product, offering golden paths that make the right placement the easy one. I unpacked that operating model in platform as a product, and the through-line is the same: adoption of good defaults beats mandates every time. Pair it with the broader operating-model shift in transforming operating models, because a placement discipline that no team is accountable for will quietly revert to "leave it where it is."
What This Means for Your Next Architecture Review
If you take one thing from this, take the reframing. The question was never whether your company belongs in the cloud. The question is where each workload belongs this year, and whether you have built the discipline to keep asking. Repatriation is not a retreat and the cloud is not a trap. They are two directions on the same portfolio dial, and the dial was always meant to turn both ways.
The organizations that win the next few years will not be the ones that picked the right venue in 2021. They will be the ones who stopped treating placement as a one-time migration and started treating it as a standing decision, instrumented with real unit economics, honest data-gravity maps, and a cadence for revisiting both. The bill rewards that discipline every single month. So does the architecture. The green checkmark on the old slide was never the finish line. There is no finish line. There is only the next placement decision, and how well you are equipped to make it.
References
- Puppet. Cloud Repatriation in 2025: Statistics, Who's Leaving and Why Now. puppet.com
- InfoWorld. Cloud trends 2025: Repatriation and sustainability make their marks. infoworld.com
- The Stack. Gartner forecast dampens cloud repatriation outlook. thestack.technology
- David Heinemeier Hansson. Our cloud-exit savings will now top ten million over five years. world.hey.com
- The Register. 37signals on-prem migration to save millions, abandon AWS. theregister.com
- TechCrunch. After AWS and Google, Microsoft says it's removing Azure egress data transfer fees. techcrunch.com