The pitch a decade ago was simple: move to the cloud, stop buying servers, let elasticity handle the rest. That pitch still holds for a large share of workloads. But a growing number of infrastructure teams are running the numbers on specific applications and concluding that the public cloud is now the more expensive option — not universally, but for certain shapes of workload that were never a great fit to begin with.
This isn’t a wholesale retreat from the cloud. Most organizations doing repatriation are moving a handful of steady-state, high-throughput services back to owned or leased hardware while keeping everything else — bursty workloads, dev/test environments, anything with unpredictable demand — right where it is. The decision is workload-by-workload, and getting it wrong in either direction is expensive.
The Workloads That Tend to Move
A pattern shows up across the organizations making this move: the applications coming back on-prem or into colocation facilities are almost always the ones with flat, predictable, always-on resource consumption. Think large-scale data processing pipelines that run continuously, storage-heavy media workloads, or internal platforms that serve a stable, known population of users with little seasonal variation.
These are precisely the workloads that get the least benefit from cloud elasticity, because they never scale down. A server that runs at 70-80% utilization around the clock is paying for on-demand flexibility it never uses. Over a three-to-five-year horizon, the economics of owning that capacity outright — or committing to a colocation contract with predictable pricing — can look considerably better than paying a cloud provider’s on-demand or even reserved-instance rates for the same steady load.
By contrast, workloads with genuine variability — retail traffic that spikes around seasonal events, new products still finding their usage patterns, anything where demand could double or vanish with little notice — remain much harder to justify moving off cloud infrastructure. The whole value proposition of the cloud is built for exactly that uncertainty.
Egress Fees Are Doing a Lot of the Persuading
Ask an infrastructure lead why repatriation moved from theoretical to funded project, and data transfer costs come up constantly. Storage and compute pricing have become more competitive over time, and multi-cloud comparisons are easier to run than they used to be. Egress fees — what it costs to move data out of a cloud provider’s network — have stayed comparatively sticky, and they compound in ways that are easy to underestimate during initial architecture decisions.
An application that ingests large volumes of data, processes it, and serves results to users or downstream systems outside the cloud provider’s network can accumulate egress charges that dwarf the original compute and storage line items. Teams that modeled cloud costs primarily around compute and storage at launch sometimes discover, years later, that data movement is the largest and fastest-growing part of the bill. That discovery is often the moment repatriation analysis gets seriously funded.
The Costs Nobody Puts on the Slide
Where repatriation efforts run into trouble is in the parts of the total cost of ownership that don’t show up on a cloud invoice comparison. Owning or leasing hardware means owning the operational burden that the cloud provider was quietly absorbing: patching, capacity planning, hardware refresh cycles, physical security, power and cooling, and the staffing to handle all of it around the clock.
Organizations that repatriated workloads without accounting for this tend to end up worse off than before, not because the underlying compute math was wrong, but because they underpriced the operational overhead. A realistic total cost of ownership model has to include the incremental headcount or contractor time needed to run infrastructure that a cloud provider previously managed as part of the service. It also needs to account for the opportunity cost of that staff time — engineers running racks are not building product.
There’s also a resilience question that’s easy to gloss over. Cloud providers offer built-in redundancy across availability zones and regions that would be expensive and complex to replicate on owned infrastructure. Any repatriation plan for a workload with meaningful uptime requirements needs a real answer for disaster recovery, not an assumption that the old on-prem setup from before the original cloud migration will still be adequate.
Colocation as the Middle Path
Most of the repatriation happening right now isn’t a return to owned data centers in the traditional sense — it’s a shift toward colocation facilities, where an organization owns or leases the hardware but rents rack space, power, and network connectivity from a third-party facility operator. This splits the difference: it captures much of the cost advantage of owning compute for steady-state workloads while avoiding the capital and operational burden of running a physical facility.
Colocation also tends to shorten the runway for repatriation projects considerably. Building or leasing a full data center is a multi-year undertaking; moving hardware into an existing colocation facility with established power and connectivity can be a matter of months. For organizations testing whether repatriation math actually holds up in practice, colocation offers a lower-risk way to find out before committing further.
What a Reasonable Evaluation Looks Like
The organizations getting this right tend to run the same basic exercise before moving anything. First, they isolate workloads by utilization pattern rather than by application category — the question isn’t “is this a database” but “does this consistently use the same amount of resources every day.” Second, they build a genuine total cost of ownership model that includes staffing, facilities, hardware refresh cycles, and disaster recovery, not just a hardware price compared against a cloud invoice. Third, they price out egress and data transfer costs separately, since those are often the line item that tips the calculation.
Finally, they treat repatriation as reversible where possible — using colocation or hybrid arrangements rather than burning the bridge back to cloud infrastructure entirely. Cloud pricing, egress fee structures, and hardware costs all shift over time, and a workload that makes sense to repatriate today may not in three years, particularly as providers respond to competitive pressure on the fees driving these decisions in the first place.
None of this amounts to a verdict on cloud computing generally. It’s a reminder that the initial migration decision and the ongoing hosting decision are not the same question, and that revisiting the second one periodically — with real numbers, not a general sense that the cloud bill feels high — is a normal part of running infrastructure at scale rather than a sign that the original move was a mistake.
