Which Workloads Should Never Leave The Cloud

(Even When Repatriation Looks Tempting)

After publishing my piece on cloud repatriation, my inbox filled up fast. Not with disagreement—but with a different question:

“Okay, fine. Some workloads should come home. But which ones absolutely should not?”

That’s the right question. Repatriation is not a crusade. It’s a correction. And like all corrections, it can overshoot if you apply it blindly. I’ve been doing infrastructure architecture long enough to watch three full cycles:

• On-prem everything
• Cloud everything
• Hybrid reality

Here’s the hard-earned truth: Some workloads belong in the public cloud forever, no matter how good your colo deal is or how cheap hardware gets. This article is about identifying those workloads before you make an expensive mistake.

If you haven’t read it yet, this article is the counterweight to my earlier piece on when repatriation does make sense.

Key Takeaways (Read This Before You Touch a Migration Plan)

• Elasticity-dependent workloads should never be repatriated.
• Undifferentiated heavy lifting is exactly what cloud was built for.
• Global edge delivery on-prem is a fantasy for most enterprises.
• Cloud-native managed services break economically when self-hosted.
• If losing the cloud service means rebuilding a product, stop.

The Prime Directive: Never Repatriate What You Can’t Economically Rebuild

Here’s my first decision rule. I apply it ruthlessly:

If you can’t recreate the capability without hiring a new team, don’t repatriate it.

Cloud isn’t just infrastructure anymore. It’s embedded product velocity. If you rip out a managed service and replace it with “we’ll run it ourselves,” you’re not repatriating—you’re starting a new internal product company. Most teams aren’t staffed for that. They just don’t know it yet.

Category #1: Truly Elastic, Spiky Workloads

These are the workloads cloud was born for.

Characteristics

• 10x–100x demand swings
• Unpredictable traffic
• Short-lived compute bursts
• Auto-scaling is doing real work

Examples

• Event-driven pipelines
• Data ingestion jobs
• CI/CD build systems
• Seasonal or viral consumer apps

Decision Matrix

Architect’s verdict:
If your peak-to-average ratio is greater than 4:1, on-prem economics collapse. Repatriating these workloads doesn’t save money. It just moves the bill from AWS to payroll.

Category #2: Managed Databases You Don’t Want to Babysit

When Managed DBs Stay Put

Self-hosting databases is not free.
You pay in:

• Senior DBAs
• Patch windows
• Incident risk
• Burnout

If the database is not your competitive advantage, don’t adopt it as a hobby. Databases demand operational maturity whether you like it or not.

Category #3: Global Edge & Latency-Sensitive Services

This is where repatriation fantasies go to die.

Examples

• Global APIs
• SaaS frontends
• Authentication endpoints
• Media delivery

Rebuilding this on-prem means:

• Multiple regions
• Global load balancing
• DDoS mitigation
• 24×7 NOC maturity

That’s not “moving workloads home.” That’s becoming a cloud provider.

Cost Reality

If your users are global, your infrastructure probably should be too.

Category #4: Cloud-Native Control Planes (Don’t Rebuild the Brain)

This is the mistake I see most often in repatriation plans. Teams move workload…but forget the control plane is the product.

Examples You Should Not Self-Host

• IAM platforms
• Event buses
• Serverless frameworks
• AI/ML training pipelines
• Managed Kubernetes control planes

Yes, you can self-host alternatives.

But ask yourself honestly:

• Do you want to operate etcd at scale?
• Do you want to secure identity at global scale?
• Do you want to own the pager when auth breaks?

I don’t.

Category #5: Tooling That Isn’t Core to Your Business

Tooling becomes dangerous when it competes with your core mission. This is where ego sneaks in.

Just because you can run something on-prem doesn’t mean you should.

Leave These in the Cloud

• Monitoring platforms
• Log analytics
• Security scanning
• CI/CD SaaS tools
• Ticketing systems

Why?

Because rebuilding SaaS internally creates:

• Permanent OpEx drag
• Tooling debt
• Skill dilution

Infrastructure should support the business—not become it.

Cost Reality Check: CapEx Doesn’t Always Win

Let’s be honest about the numbers.

When Cloud Wins Economically

CapEx shines with predictability. Cloud shines with uncertainty.

Good architects don’t pick sides. They pick economic alignment.

The One Question That Prevents Bad Repatriation

Before approving any repatriation plan, I ask this:

“If this breaks at 2 a.m., are we glad we own it?”

If the answer is no, leave it in the cloud.

Ownership isn’t free. It’s responsibility, risk, and reputation.

How This Fits Into a Hybrid Strategy

The best environments I design today look like this:

• On-Prem / Colo: Steady-state compute, core databases, predictable platforms
• Public Cloud: Edge, burst, control planes, experimentation

I’ve run my own PostgreSQL clusters. I’ve tuned them. I’ve lost sleep over them. That’s exactly why I keep some databases in the cloud.

If you’re coming from VMware and evaluating exits or hybrid patterns, read:

• Hypervisor Alternatives Guide
• NSX-T to Nutanix Flow Migration Guide

And before touching anything, map dependencies check out the VMware 2 Nutnanix Mapper Tool

Final Architect’s Note:

Repatriation isn’t about undoing the cloud era. It’s about using it correctly.

The future isn’t cloud-first or on-prem-first. It’s decision-first.

Additional Resources:

• AWS Well-Architected Framework
• Azure Architecture Center
• Google Cloud Reliability Engineering
• CNCF Cloud Native Landscape