For most of the last decade, suggesting that a company might move workloads out of the public cloud marked you as either a hardware vendor or someone who had not been paying attention. The direction of travel was settled, and the only interesting question was pace.
The direction is still mostly one way. What has changed is that the exceptions have become numerous enough, and expensive enough, to have a name and a budget attached.
The workloads that stopped being variable
The economic case for public cloud was never that it was cheap. It was that it converted capital expenditure into operating expenditure and let capacity track demand, which is enormously valuable when demand is unknown. A company that cannot predict whether it needs ten servers or a thousand should absolutely rent.
The trouble is that workloads age. A service that was unpredictable during its growth phase becomes, five years later, a steady thing with a known baseline running twenty-four hours a day. At that point the company is paying an elasticity premium on capacity it uses continuously.
Finance departments arrived at this before engineering did, which is why the conversation has the tone it does. The trigger is usually a cloud bill crossing a threshold where it becomes a board-visible number, followed by an analysis showing that a meaningful share of it funds steady-state compute and storage that has not varied materially in years.
Data gravity has sharpened the calculus. Egress pricing means that the cost of moving data out of a provider scales with the amount of it, and companies that accumulated years of it discover the exit is priced accordingly. That has produced a rational but uncomfortable conclusion in some organizations: the time to reconsider architecture is early, while the data is small enough that the decision is still reversible.
The AI infrastructure buildout has cut both ways. Training remains firmly rented, because almost nobody's demand for it is steady. Inference is a different profile entirely, and as it moves into production at constant volume it starts to resemble exactly the kind of predictable workload that repatriation targets. Several organizations running smaller models at high throughput have found the on-premises comparison unexpectedly favorable.
What almost nobody is doing is leaving. The pattern is hybrid by default: burst capacity, global distribution and managed services stay rented, while the steady base moves to owned or colocated hardware. That is a more complex operating model than either pure position, and it requires exactly the infrastructure engineering talent that a decade of cloud adoption trained companies out of maintaining.
Regulated industries have been quietly ahead of this. Data residency and audit requirements pushed banks, insurers and health systems toward hybrid architectures years before cost made the question fashionable, and those organisations retained the operational skills that everyone else is now trying to rehire.
Which is the real constraint, and it is the same one that makes legacy rewrites so difficult. The financial case for repatriation is often clear. The staffing case frequently is not, and a company that cannot hire people who know how to run hardware will keep renting it regardless of what the spreadsheet says.
Earlier Cranberry Journal coverage examined the maturing of the layer beneath this in The API Economy Enters Its Utility Phase.



