There's been a lot of talk lately about cloud repatriation, including a recent piece by Will Kelly that resonated with a lot of us who remember the data center days.

Will raised some hard truths: most organizations don't have the muscle memory or staffing to even attempt going back on-prem. And as someone who lived through that era and now works with CIOs navigating the complexity of hybrid cloud, I'd say he's absolutely right.

But there's more to the story. Because the question isn't just can we go back. It's should we — and if not, what should we do instead?

The Cloud Gave Us a Lot - But at a Cost

The cloud, for all its challenges, gave us a lot.

It gave developers access to resources they could only dream about in the data center days: scaling infrastructure on demand, testing new services with a click, modernizing apps without months in procurement. You don't get Netflix without the flexibility cloud enables.

But that kind of freedom isn't free.

Cloud costs have ballooned. And for many companies, the ROI story just doesn't add up. Not because cloud doesn't offer value, but because that value is buried under sprawl, mismanagement, and workloads that were never a good fit in the first place.

Some organizations have started to rethink their strategy — and for a lucky few, that includes moving certain workloads back on-prem.

And I do mean lucky, because most companies can't even consider it.

But Most of Us Can't Go Back

There's no such thing as "moving back on-prem" unless you never left completely.

The only companies remotely positioned to evaluate repatriation today are the ones that still own and operate their own data centers or maintain co-located infrastructure. These are usually large, stable enterprises in industries like banking, insurance, or government — organizations that never fully bought into the "cloud-only" hype and kept legacy infrastructure around for regulatory, technical, or financial reasons.

For them, bringing a few workloads back on-prem isn't some multi-year transformation. It's a cost-savings play. They already have the physical space, the equipment, the staff (at least some of them), and the financial model to support CapEx. Repatriation is still an option.

For everyone else, it's not.

It's Not About Tools. It's About What's Missing.

Repatriation isn't hard because it's technical. It's hard because the industry forgot how to do it.

Over the last decade, companies didn't just migrate to the cloud — they erased the institutional knowledge required to run anything else. They downsized infrastructure teams, rewrote CapEx budgeting processes, and outsourced resiliency to the vendor. Now they're left holding the bill with no fallback plan.

I've worked with CIOs walking into environments where even a basic question like, "Could we run this on-prem?" can't be answered. Not because it's a bad idea, but because nobody remembers what it takes. There's no financial model. No ops staff. No crash cart in the closet. Just cloud-native apps built on managed services they can't unplug from.

It's like trying to rip out your foundation after the house is already built. Possible, maybe — but few are prepared for it.

Cloud Was Easy to Enter. Harder to Leave.

Getting into the cloud was easy. Some vendors would literally ship a semi-truck full of storage to your door, load it up, and drive it straight into their data center — for free.

Getting that data back? That'll cost you — byte by byte.

Even if you're willing to absorb those costs, repatriation isn't just about moving data. You have to rebuild the entire environment: floorspace, cooling, power, networking, monitoring, backups, security, and physical maintenance. I've met DevOps engineers who've never seen the inside of a server rack. That's not a criticism. It's simply the reality of how infrastructure knowledge has shifted. We trained a generation to build on APIs, not to cable switches or swap failing drives.

There's no undo button for that.

Repatriation ≠ Strategy. It's a Use Case

Cloud repatriation isn't a trend. It's a correction — a targeted one.

I've seen a handful of organizations move specific applications back on-prem because it made sense:

• A heavy internal comms app that benefited from low-latency, local connectivity.
• Stable workloads with predictable usage patterns and long shelf lives.
• Data sovereignty concerns that made U.S.-based clouds a political risk.
• Sunk costs in on-prem infrastructure they wanted to maximize.

That's not a strategy. That's triage.

For most orgs, repatriation is a fantasy. One that only looks attractive because the alternative feels so out of control.

What You Should Be Focusing On Instead

So what's the move?

If you're serious about controlling cloud costs and regaining operational leverage, don't romanticize the past. Focus on building real maturity where you:

• Get visibility across your full estate, not just one vendor's dashboard.
• Build cost-awareness into provisioning, not as an afterthought.
• Invest in automation and policy enforcement so your cloud doesn't run wild.
• Reduce your dependency on proprietary services unless they deliver outsized value.
• Start treating portability as a long-term hedge — not a migration plan

You don't need to go backward to take back control. You just need to start acting like control is your responsibility again.

The Nostalgia Is Real. But It Won't Save You

I'll admit — there's a part of me that misses the old data center days. The fans. The crash carts. Troubleshooting at 2am and knowing exactly what you owned. There was a craft to it. A sense of accountability you don't always feel when everything is abstracted away.

But I also know those days are gone for most companies. Pretending you can bring them back with a CapEx line item and a couple new hires isn't realistic.

It's a spreadsheet fantasy.

If you want to rein in costs, do it with eyes open. If you want control, build it deliberately. Like Kelly said, spare your teams the posturing.

Cloud repatriation isn't your answer. Running the cloud like it's yours — that's the one that actually works.