How to Move Off a Single Cloud Provider Without Re-Architecting Your Apps

TL;DR

You move workloads off a single hyperscaler without re-architecting by running the container images you already have on more than one provider, keeping the native services worth keeping, and adding providers one location at a time.

Control Plane does this with a Global Virtual Cloud (GVC): one deployment target that combines AWS, GCP, Azure, neoclouds, your existing Kubernetes clusters, and bare metal. Each provider you add is another failure domain, so your apps and agents stay up when others are down.
Lock-in lives in three layers: compute and orchestration, proprietary managed services, and identity and networking. A GVC handles the first and third. You decide the second service by service.
During the October 20, 2025 AWS us-east-1 outage, 20% of Control Plane customers had us-east-1 in their Global Virtual Clouds. Their workloads were active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane internal incident telemetry.

What causes cloud vendor lock-in?

The cost of leaving a provider concentrates in three layers, and each needs a different fix.

1. The compute and orchestration layer

Your containers are probably portable. The way they get scheduled, scaled, and deployed often is not. Deployment manifests, autoscaling rules, load balancer settings, and CI/CD pipelines are written against one provider’s primitives. AWS’s Unpicking Vendor Lock-in whitepaper (now marked as historical reference) recommends Docker containers, loosely coupled services, and a facade in front of each provider-specific service so it can be swapped out.

2. The proprietary managed services you depend on

Databases, queues, object storage, and event buses are the services your code talks to directly. Some are worth the dependency. Moving off RDS for PostgreSQL is usually a data migration, not a code rewrite, because the application speaks standard PostgreSQL. A data model built around one provider’s proprietary database API, or an event pipeline wired through one provider’s function triggers, usually requires rewriting code. Decide one service at a time whether to keep, wrap, or replace it (Step 3).

3. Identity and networking that only work inside one cloud

This is the layer teams discover last. IAM roles, trust policies, VPC layouts, and private DNS are all described in one provider’s terms, so they get rebuilt by hand for every new cloud.

Identity is also a dependency during outages. During the October 2025 us-east-1 disruption, AWS Security Token Service (STS) returned API errors and elevated latency in that region in two waves between 11:51 PM PDT on October 19 and 9:59 AM PDT on October 20, and IAM users signing in to the AWS Management Console saw increased authentication failures (AWS post-event summary). Identity that depends on one region is a single point of failure that is easy to overlook.

Why does staying on one provider cap your uptime?

A single provider gives you multiple availability zones and regions, which protects against many failures. It does not protect you from a failure in a shared service your workload depends on. Your availability is capped by the provider’s, because every failure domain you can reach sits inside that provider.

The October 2025 us-east-1 event shows how this plays out. AWS describes a latent race condition in the DynamoDB DNS management system that left the regional endpoint with an empty DNS record. The event ran from 11:48 PM PDT on October 19 to 2:20 PM PDT on October 20, with DynamoDB errors, EC2 instance launch failures, and Network Load Balancer connection errors. Instances launched before the event stayed healthy, but new launches in us-east-1 failed from 2:25 AM to 10:36 AM PDT, so teams that needed to scale or replace capacity in that region during that period could not (AWS post-event summary).

This is not just an AWS problem. On June 12, 2025, an invalid quota policy replicated globally and took down Google Cloud’s API management layer for about 3 hours (Google Cloud incident report). On October 29, 2025, incompatible customer configuration metadata crashed Azure Front Door at edge sites worldwide for about 8.5 hours (Azure post-incident review). Both failures were global, so workloads that depended on the affected service saw errors in every region of that provider. Our one-year look at every major cloud outage covers the full record.

Adding a second provider as a location raises that ceiling, because one provider’s failure no longer takes down every location your workload runs in. During the October 20, 2025 AWS outage, 20% of Control Plane customers had us-east-1 in their Global Virtual Clouds. Their workloads were active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane internal incident telemetry (Beyond Backups).

Options for leaving a single cloud provider, compared

Question	Rewrite per cloud	DIY Kubernetes and Terraform per cloud	One platform across clouds (Control Plane)
What changes in your apps	Code changes for each provider’s services and APIs	Images stay the same; manifests and Helm values adapted per cluster	Existing container images run unchanged
What you build and operate	A separate implementation per cloud	A cluster, network design, and identity mapping per cloud	The platform handles networking, identity, and routing
Identity and managed services	Rewritten per provider	Mapped per cloud, often with stored credentials	Short-lived access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code
Adding a second provider	A new implementation	A new cluster and module set	Add a location to the GVC
Failover	Designed per application	Cross-cluster routing and health checks you build and run	Active-active, with global routing to the nearest healthy location
Team required	Application engineers for every cloud	A platform team with expertise in each cloud	No platform team to build; day-two operations come built in
Cost profile	Engineering time per rewrite, plus each cloud	Platform staffing and cluster overhead per cloud	Active-active without paying for idle standby capacity; customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure

The third path adds a second provider without a rewrite or a new platform team, with failover across providers built in. Terraform and Pulumi fit the second and third paths alike: Control Plane has Terraform and Pulumi providers, so infrastructure you already define in code stays that way.

How to move off a single cloud provider without a rewrite: 6 steps

Step 1: Inventory your dependencies

Start by building the list of what ties you to your current provider. Search the codebase for cloud SDK imports, direct provider API calls, hardcoded ARNs and resource IDs, IAM role assumptions, and DNS or network dependencies. Sort each item into one of the three layers above. That list is your migration scope. For many containerized applications it is shorter than expected, because provider-specific calls tend to sit in a few places.

Step 2: Containerize what is not containerized yet

Anything running on virtual machines or provider-specific compute needs a container image before it can move. Start with stateless services, since they are the easiest to move and the first to prove the approach. Workloads that already run as containers need no changes at this step.

Step 3: Decide which managed services to keep

Keep. The service is worth its dependency and you can reach it from anywhere. A managed relational database or object store usually belongs here. On Control Plane, Cloud Wormhole reaches databases in existing VPCs and data centers without moving them first, so data can stay where it is while compute spreads across providers.
Wrap. The service has a proprietary API that leaks into your business logic. Put a thin interface in front of it so the provider-specific code lives in one place.
Replace. The service forces a data model or workflow you cannot reach outside one cloud, and you have a reason to move off it. Schedule these separately, after the first workloads are portable, so they do not block the rest.

Each remaining native service should be a dependency you chose on purpose.

Step 4: Add a second provider as a location

Pick a low-risk, stateless service and deploy it to a second provider. With a platform that treats each provider as a location, this is a configuration change, not a new environment build. Because the platform handles identity and networking across locations, you are not rebuilding IAM and VPC layouts for the new provider. Your own servers and existing clusters count too, which our guide to hybrid cloud platforms covers in more depth.

Step 5: Move traffic gradually

Move one service at a time and keep the original deployment running while you watch error rates and latency in the new location. Stateless compute fails over at the platform level. Stateful services depend on where data lives and how it replicates, so place compute and data together, and set RPO and RTO targets for each datastore before you move it.

Step 6: Test failover before you need it

Run a failure drill in a non-production environment. Take one location out of service and confirm that requests reach a healthy location and that your health checks, alerts, and runbooks behave as expected. An untested failover path often fails when it is needed. Repeat the drill after significant changes, and add new providers and services as they come online.

How Control Plane runs the same workloads across clouds

Control Plane lets you run unbreakable apps and agents: no single zone, region, or provider failure takes them down, backed by a 99.999% availability SLA for workloads running at least two replicas in at least two locations. It combines any cloud, neocloud, and bare metal into one Global Virtual Cloud: a single deployment target spanning AWS, GCP, Azure, your existing Kubernetes clusters, and your own servers. You add failure domains from what you already run instead of rebuilding for a new cloud.

Unchanged containers. Existing linux/amd64 container images run as they are, with no new packaging format.
Active-active by default. A workload deployed to the GVC runs in every location, and a global endpoint sends each request to the nearest healthy location. Routing, health checks, and identity are managed by the platform across locations, so when one provider fails, traffic routes to healthy locations on the others automatically, with no runbook.
Identity without long-lived cloud keys. Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. Teams keep using services like RDS, S3, BigQuery, or Cosmos DB from any location.
Private networks without a migration. Cloud Wormhole connects workloads to TCP and UDP endpoints in VPCs and data centers, so databases can stay where they are.
Incremental adoption. Existing Kubernetes clusters join as locations through BYOK, and your own servers join through Managed Kubernetes. You add providers one at a time.
Agents and inference. Agents run as regular production workloads, active-active across locations, so they keep serving when one location fails. GPU Ocean lets you pull GPU capacity from any provider, today through Managed Kubernetes, so inference can run on more than one GPU source, and Sandboxes give AI coding agents isolated environments to build in, with cloud access brokered through Universal Cloud Identity instead of stored keys.
Day two built in. Autoscaling, Capacity AI right-sizing, logs, metrics, and traces, mutual TLS, secrets, and an audit trail come with the platform.
99.999% availability SLA for workloads running at least two replicas in at least two locations. See how many nines you actually need.
Lower compute cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Many Control Plane customers run on one cloud. They get active-active across regions, right-sizing, built-in observability, and security without building a platform team, and adding a second provider later is a configuration change.

Frequently asked questions

How do I move workloads off a single hyperscaler without re-architecting?

Keep your application as it is and change where it can run. Containerize the workloads that are not containerized yet, then deploy the same container images to a second provider as an additional location. Decide service by service which native managed services to keep, and move traffic gradually.

How do I avoid getting locked into a single cloud provider?

Look at the three layers separately. Containerize for the compute layer, make a deliberate keep, wrap, or replace decision for each managed service, and use an identity and networking layer that works across providers. Then add a second provider as a location so that portability is exercised rather than theoretical.

What is the best way to stay cloud-agnostic?

Being fully cloud-agnostic, with no native services at all, is expensive and rarely worth it. A more practical target is portable workloads plus deliberate service choices: your containers run on any provider you add, and you use native services where they earn their place.

What is a portable way to run containers across any cloud?

Standard container images are the portable unit. The harder part is running them the same way on every provider, with one identity model, one network model, and one deployment target. A Global Virtual Cloud provides that, with locations on AWS, GCP, Azure, neoclouds, your own Kubernetes clusters, and your own servers.

What tools help with cloud portability and avoiding vendor lock-in?

Three kinds of tools matter. Containers package the application. Infrastructure as code tools such as Terraform and Pulumi make infrastructure reproducible. A platform layer runs the same workloads across providers as one virtual cloud and handles identity, networking, and routing. Control Plane is that platform layer, built so apps and agents stay up when a provider goes down. Our multi-cloud management platforms comparison covers the wider field.

Do I have to give up RDS, S3, BigQuery, or Cosmos DB?

No. Workloads authenticate to native services with short-lived credentials through Universal Cloud Identity, from any location, and Cloud Wormhole reaches resources inside a private VPC. Where the data lives is a per-service decision.

Does Control Plane replace Terraform or Pulumi?

No. Control Plane is complementary to both and has providers for both.

What does the 99.999% availability SLA cover?

Workloads running at least two replicas in at least two locations. Single-location or single-replica workloads are not covered.

Is Control Plane worth it if we only use one cloud?

Yes. Active-active across regions on one cloud keeps a zone or region failure from taking your workloads down, and day-two operations come built in. Capacity AI right-sizes CPU and memory from actual usage, so you do not pay for idle standby capacity, and customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. Adding a second provider later is a configuration change.

Next step: Talk to the Control Plane team about your current provider and your first candidate workload, or sign up free and deploy one workload to two clouds.