Which Workloads Move Easily Between Cloud Providers

When teams think about leaving a cloud provider, they often picture a giant migration: every application, every database, every dependency, all at once. That’s rarely how it goes, and it’s rarely how it should go. Some workloads can move between providers in days because they’re built on standard pieces that run the same way anywhere. Others are tangled up with one provider’s proprietary services and would take months to untangle. Knowing which is which is the first step in any move.

Here’s a version of a situation we’ve seen. A team runs hundreds of virtual machines, all built from standard images and managed by provisioning automation the team wrote themselves. The automation works fine. The problem is the provider underneath it: unreliable, and a poor match for how the team’s tooling expects infrastructure to behave. Because the VMs are standard and the automation is theirs, moving to a different provider isn’t a rewrite. It’s pointing the same automation at a new API.

That’s what a portable workload looks like. The rest of this article covers how to spot one in your own environment.

What Makes a Workload Portable

A workload is portable when the things it depends on exist, in a compatible form, on the provider you might move to. In practice, that comes down to a few traits.

It Runs on Standard Compute

VMs built from standard Linux images, or containers built from standard base images, run the same way on any provider that offers VMs or Kubernetes. Nothing about the workload is tied to one provider’s hardware or hypervisor.

It Uses Open or Widely Supported Interfaces

Workloads that store data in open-source databases like PostgreSQL or MySQL, use object storage through the S3 API, or run on Kubernetes rely on interfaces that many providers support. Moving them means connecting to the same kind of service in a new place.

It’s Defined in Code You Own

If your infrastructure is described in Terraform, Ansible, or your own provisioning scripts, you can recreate it somewhere else by changing the target. If it was built by hand in a provider’s console, someone has to rebuild it by hand.

Its State Is Contained

Stateless services, or services whose state lives in one well-defined place like a database or a bucket, are easier to move than services with state scattered across disks, caches, and managed services.

From Easiest to Hardest: How Common Workloads Sort Out

Usually Easy to Move

• Stateless web and API tiers in containers. Build the same images, deploy them to a new cluster, and shift traffic.
• VM fleets built by automation. If your own tooling builds and configures the VMs, point it at a new provider’s API.
• CI/CD runners and build agents. They’re stateless by design and often start fresh for every job.
• Batch and queue workers. They pull work, process it, and write results somewhere else. Move them, then point them at their inputs.
• Development and test environments. They’re rebuilt often anyway, and they’re a low-risk place to learn a new platform.

Moderate Effort

• Databases on open-source engines. PostgreSQL and MySQL run anywhere, but moving the data takes planning: replication, a sync window, and a cutover.
• Object storage behind the S3 API. The interface carries over. The data has to be copied, and large datasets take time.
• Kubernetes workloads with persistent volumes. The workloads move easily. The volumes need a data migration plan.
• Services tied to fixed IP addresses or DNS. They move fine, as long as you plan the address and DNS changes ahead of time.

Hard to Move

• Serverless functions wired together with managed event services. The code may be portable, but the triggers, permissions, and glue usually aren’t.
• Applications built on proprietary databases. Data in a provider-specific database often needs a new data model, not just a copy.
• Workloads deeply tied to managed AI or analytics services. Replacing them means choosing and integrating an alternative.
• Anything with heavy provider-specific identity and permissions logic. Access rules written for one provider’s identity system have to be rebuilt.

None of this means the hard workloads can never move. It means they cost more to move, and that cost belongs in the decision.

The Hidden Dependencies That Slow a Move Down

Even portable workloads can stall on details nobody wrote down. Before you plan a move, look for:

• Hardcoded endpoints. Service URLs, storage endpoints, and region names baked into code or configuration
• Provider-specific SDK calls. One call to a proprietary service in an otherwise portable app ties the app to that provider
• Data gravity. Large datasets that other systems read constantly. Moving the compute without the data can create expensive cross-provider traffic
• Secrets and credentials. Keys and tokens stored in a provider’s secrets manager
• Monitoring and logging. Dashboards and alerts built on a provider’s native monitoring tools
• Network assumptions. Security rules, private addressing, and VPN connections that need to be recreated

A short inventory of these for each workload usually takes a day and saves weeks.

How to Score Your Own Workloads

A quick way to rank your workloads by portability is to answer five questions for each one, giving one point for every “yes”:

1. Does it run on VMs or containers built from standard images?
2. Does it store data only in open-source databases or S3-compatible object storage?
3. Is its infrastructure defined in code your team owns?
4. Does it avoid calling proprietary managed services directly?
5. Is its data small enough, or isolated enough, to move in a planned window?

Workloads scoring four or five are your first candidates. Workloads scoring two or three need some preparation, usually replacing one proprietary dependency or planning a data migration. Workloads scoring zero or one are better left in place for now, or treated as longer-term projects.

Run the scoring with the engineers who own each workload, not just the infrastructure team. The owners know which “standard” service quietly depends on a provider-specific feature. Keep the scores in a shared sheet, and revisit them as workloads change. A workload that scores low today can become portable after a refactor.

Why Portable Workloads Are the Right Place to Start

If you’re changing providers, start with the workloads that move easily:

• They deliver savings sooner. A workload that moves in a week starts saving money in a week.
• They build confidence. Your team learns the new platform on low-risk workloads before tackling critical ones.
• They keep options open. Workloads that stay portable can move again later, wherever cost and performance fit best.

A first workload that runs well also makes the next move easier to justify. It proves the platform with your own workload, and bigger moves can follow from there.

Where OpenMetal Fits

OpenMetal is built on standard, widely used interfaces, which is what makes it a natural destination for portable workloads:

• OpenStack APIs for VMs, networks, and storage, so existing OpenStack tooling, Terraform providers, and automation work with it
• Kubernetes running on dedicated hardware
• Ceph object storage reachable through S3-compatible and Swift APIs
• Bare metal provisioned through the OpenMetal Central API for workloads that need full servers

Moving a portable workload to OpenMetal still means moving it to a new vendor, and you should plan for that like any provider change. But because the interfaces are standard, the skills and code your team already has carry over.

To see how fixed monthly pricing changes the math once a workload moves, our guide to calculating cost per VM and cost per customer on fixed-cost infrastructure walks through it. If part of your workload needs dedicated servers and part runs well in VMs, running bare metal and a private cloud on one private network shows how the two connect.

How a Move Works With OpenMetal

For a portable workload, a move to OpenMetal usually follows the same shape:

• We plan ahead. We scope the environment with you, plan capacity for the workloads you’re moving, and source and stage the hardware against your go-live date.
• You decide. You choose which workloads move first, the hardware configuration and location, and how you’ll cut over.
• We hand over. You get a running environment, admin access, and a private Slack channel with our engineers. For migrations, ramp pricing and running old and new environments in parallel during cutover are available.

Not sure which of your workloads are portable? Our article on which workloads should stay in public cloud covers the other side of the decision.

Who This Is For

This is most useful if you:

• Are unhappy with your current provider and want to know what could move quickly
• Run VMs or containers built from standard images and managed by your own automation
• Want to lower cloud costs without a large, risky migration
• Are planning a phased move and need to know where to start

It’s less useful if you:

• Run mainly serverless or proprietary managed services
• Have already decided to keep everything with your current provider
• Are planning a full data center move with fixed hardware and licensing constraints

The Short Version

The workloads that move easily are the ones built on standard pieces: standard images, containers, open-source databases, S3-compatible storage, and infrastructure defined in code you own. Start there, and the rest of the move gets easier.

If you want to see how your portable workloads would run on dedicated infrastructure, apply for a proof of concept or talk with our team.

Frequently Asked Questions

What makes a workload portable between cloud providers?

A portable workload runs on standard compute like VMs or containers, uses widely supported interfaces such as open-source databases and the S3 API, is defined in code you own, and keeps its state in a well-defined place.

Which workloads are easiest to move?

Stateless web and API tiers in containers, VM fleets built by your own automation, CI/CD runners, batch workers, and development and test environments.

Which workloads are hardest to move?

Serverless applications wired together with managed services, applications built on proprietary databases, workloads tied to managed AI or analytics services, and anything built around one provider’s identity and permissions system.

Why start a migration with portable workloads?

They move quickly, start saving money sooner, let your team learn the new platform on low-risk workloads, and stay portable for future moves.

Can I use my existing automation with OpenMetal?

Usually, yes. OpenMetal private clouds expose standard OpenStack APIs, and bare metal is provisioned through the OpenMetal Central API, so tools like Terraform and Ansible and your own scripts can target it.

Will my workloads stay portable on OpenMetal?

Moving to any provider means planning for that provider. Because OpenMetal uses standard interfaces like OpenStack, Kubernetes, and S3-compatible storage, workloads built on them stay portable.