Which Workloads Should Stay in Public Cloud?

Most conversations about leaving public cloud start with the bill. The better starting point is the workload. Some workloads cost far more on public cloud than they would on dedicated infrastructure. Others are a genuinely good fit for public cloud and would cost more, or take more effort, to run anywhere else. Moving the first group and leaving the second alone usually produces better results than moving everything or nothing.

Here’s a pattern that goes wrong: A team sees a large monthly cloud bill, decides to “get off the cloud,” and starts moving workloads in whatever order seems easiest. Six months later, the steady, predictable services have moved and are saving money. But the team has also rebuilt an event-driven pipeline that only ran a few hours a week, and now it sits on dedicated hardware that’s idle most of the time. The overall savings are smaller than expected, and part of the reason is that some of what moved should have stayed.

We sell private infrastructure, so it may seem odd for us to write about what shouldn’t move to it. But a placement that holds up over time is worth more to a customer than a migration that looks good on paper, and it’s the approach OpenMetal Labs takes: recommend private infrastructure where it fits, and leave a workload where it is when it doesn’t.

Workloads That Usually Fit Public Cloud Better

Short, Spiky, or Unpredictable Workloads

Public cloud bills for what you use, often in small time increments. Dedicated infrastructure is priced as a fixed monthly cost per server. That difference decides a lot.

A workload that runs at full tilt for a few hours a week, handles occasional traffic bursts many times its normal level, or exists only for a short campaign usually costs less on usage-based pricing. You’d pay for dedicated hardware all month to cover a peak that happens rarely.

Watch for: batch jobs that run briefly on a schedule, event-driven functions, seasonal spikes, and load tests.

Workloads Built Deeply Around Proprietary Managed Services

Some applications are built directly on services that only exist on one public cloud: a proprietary database, a serverless function platform, a managed queue, a machine learning service, and the glue between them. Moving the compute is easy. Replacing those services means rewriting parts of the application.

If the rewrite would take more engineering time than the move would save, the workload should stay. That’s not a permanent verdict. It’s a sign that the workload isn’t portable yet.

Watch for: heavy use of provider-specific APIs, serverless functions wired together with managed event services, and data stored in formats or services with no direct open equivalent.

Workloads That Need Points of Presence Everywhere

Public cloud providers operate many regions and edge locations around the world. If an application needs low latency for users in many countries at once, or needs to run close to users in regions a private provider doesn’t serve, public cloud or a CDN is often the practical answer.

OpenMetal operates data centers in Ashburn, Los Angeles, Amsterdam, and Singapore. That covers a lot of ground, but it isn’t dozens of regions. Be honest about where your users are.

Watch for: latency requirements tied to specific countries, applications that run active in many regions at once, and content delivery to a global audience.

Small Workloads

Dedicated infrastructure has a minimum useful size. An OpenMetal Hosted Private Cloud starts with a three-server Cloud Core. If your whole workload fits on a handful of small VMs, the fixed cost of dedicated hardware may be more than the public cloud bill you’re trying to cut.

Watch for: a total footprint of a few small instances, with no plan to grow.

Workloads Tied to Data That Isn’t Moving

Data has gravity. If a workload reads heavily from a large dataset that will stay in public cloud, moving the workload alone means paying data transfer charges on every read. Our article on what hybrid cloud networking actually costs explains why the direction of that traffic matters.

Watch for: compute that reads a large data lake or object store many times a day, where the data itself has no plan to move.

Workloads Already Locked Into Long Commitments

If a workload runs on capacity covered by a multi-year commitment discount, the savings from moving it are smaller until that commitment ends, and you’d be paying for the commitment either way. That doesn’t mean it should stay forever. It means timing matters. Line up moves with commitment end dates so you aren’t paying twice.

Watch for: reserved capacity or savings commitments with a year or more remaining.

Short-Lived Projects and Experiments

A prototype that might be abandoned in a month, or a proof of concept with an unknown future, is a poor candidate for a fixed monthly commitment. Let it prove itself first. If it becomes a steady production service, revisit the decision.

Workloads That Usually Move Well

The opposite patterns tend to move well, and these are where most of the savings come from:

• Steady, always-on workloads. Services that run around the clock at a predictable level use dedicated capacity efficiently.
• Portable workloads. VMs, containers, Kubernetes services, and standard databases that don’t depend on proprietary services move with little rework.
• Bandwidth-heavy workloads. Services that send a lot of data out to users or other systems often see large savings from moving away from per-GB egress pricing.
• Large, steady storage. Data that grows predictably and gets read regularly is a good fit for Ceph-backed storage on dedicated hardware.
• Workloads that are growing. If you add capacity every time you sign a customer, predictable per-server pricing makes growth easier to plan.
• Performance-sensitive workloads. Databases and analytics that suffer from noisy neighbors benefit from dedicated hardware.

How to Judge the Workloads in Between

Many workloads don’t fit cleanly into either list. Before you answer the questions below, get a clear view of where your money actually goes. Economize breaks down spend across AWS, Google Cloud, and Azure, along with usage-based AI platforms like OpenAI and Anthropic, and flags optimizations you can make right away. It’s a good first step whether a workload ends up moving or staying.

With that view in hand, these questions usually sort out the borderline cases.

How Steady Is the Usage?

Look at a few months of utilization. If the workload runs at a consistent level most of the time, it’s a candidate for dedicated hardware. If usage swings widely, calculate what it would cost to provision dedicated capacity for the peak and compare that with what you pay now.

How Much of the Application Is Portable?

List every service the workload depends on. Mark which have open equivalents that run on private infrastructure (standard databases, Kubernetes, object storage with an S3-compatible API) and which are proprietary. The higher the share of proprietary services, the more rework the move takes.

Where Does Its Data Live, and Where Does It Go?

Map the main data flows in and out of the workload. If moving it would create heavy traffic back to public cloud, either move the data too or leave the workload where it is.

What Would the Move Cost in Engineering Time?

Savings that take a year of engineering effort to capture aren’t the same as savings that take a week. Estimate the work honestly and compare it against the monthly savings to get a payback period.

What’s the Cost at Your Real Utilization?

Compare public cloud costs against dedicated infrastructure at the fill rate you’d actually run, not at full capacity. Our guide to calculating cost per VM and cost per customer on fixed-cost infrastructure walks through that math.

Hybrid Is Often the Right End State

Answer those questions across your whole portfolio and you’ll probably land somewhere in between: steady, portable, bandwidth-heavy workloads on private infrastructure, and spiky, proprietary, or globally distributed workloads in public cloud.

That’s a legitimate outcome, not a half-finished migration. It puts each workload on infrastructure that matches how it actually behaves. The work then shifts to keeping the two sides connected efficiently and revisiting placement as workloads change. A spiky workload can become steady as a product matures. A proprietary dependency can be replaced over time. Placement decisions should be reviewed, not made once and forgotten.

The workloads that stay in public cloud still deserve attention. Rightsizing, removing idle resources, and matching commitments to real usage all reduce what you pay for the public side of a hybrid setup, and Economize is built to find those opportunities across your cloud and AI bills.

A Quick Placement Checklist

For each workload, score these questions. The more “yes” answers, the stronger the case for moving it to private infrastructure.

• Does it run at a steady level most of the month?
• Does it rely mainly on portable components such as VMs, containers, and standard databases?
• Is it large enough to use a meaningful share of dedicated hardware?
• Does its data either move with it or stay small?
• Do its users sit near an available private data center location?
• Is it expected to run for at least the next year?
• Does it send a lot of data out, making egress a large part of its cost?

Who This Is For

This framework fits teams that:

• Have a mixed portfolio and need to decide what moves and what stays
• Want to justify a migration with workload-level evidence, not just a total bill
• Are planning a phased move and need to know where to start
• Expect to run hybrid for the foreseeable future

It’s less useful if you:

• Are moving a single, clearly portable workload with obvious savings
• Have already decided to leave public cloud entirely for non-cost reasons
• Run only a handful of small instances

The Short Version

The best migration plans move the workloads that fit private infrastructure and leave the rest alone. Steady, portable, and bandwidth-heavy workloads usually move well. Spiky, proprietary, and globally distributed ones usually stay.

To see where your public cloud and AI spend goes today, start with Economize. For a workload-by-workload view of what should move and what should stay, OpenMetal Labs analyzes your actual public cloud spend to show where private infrastructure fits and where it doesn’t, plus builds custom solutions when standard offerings don’t quire fit. You can also talk with our team or size a private cloud with our pricing calculator.

Frequently Asked Questions

Should every workload move off public cloud?

No. Short, spiky, or unpredictable workloads, applications built deeply on proprietary managed services, workloads that need many global locations, and very small footprints often fit public cloud better.

Which workloads benefit most from moving to private infrastructure?

Steady, always-on, portable workloads, especially ones that send a lot of data out or need consistent performance. Fixed monthly pricing rewards workloads that use their capacity consistently.

Is a hybrid setup a failure to fully migrate?

No. Running steady workloads on private infrastructure and variable or proprietary workloads in public cloud puts each on the platform that matches how it behaves. Treating hybrid as a long-term setup is a legitimate choice.

How do I decide where a borderline workload should run?

Look at how steady its usage is, how much of it depends on proprietary services, where its data lives, how much engineering time a move would take, and what it would cost at your real utilization on dedicated hardware.

Can a workload move later if it stays in public cloud now?

Yes. Workloads change. A spiky service can become steady, and proprietary dependencies can be replaced over time. Review placement decisions periodically rather than treating them as permanent.

How can OpenMetal Labs help with workload placement?

OpenMetal Labs analyzes your actual public cloud spend to identify which workloads would cost less on private infrastructure and which should stay where they are. If your workloads or use case are more complex and require a custom solution, our team are experts in that as well.