How to Test Cloud Portability Before You Actually Need to Switch

Key points:

• Cloud portability is a measured number, not a yes/no property. It is the time in engineering weeks plus the dollars it takes to run one real workload on a second target. Score each workload 0-3 across five layers (compute, data, networking, identity and secrets, CI/CD and IaC) and treat the lowest layer score, not the average, as your switching cost.
• Test it with a drill, not a design document. Pick your heaviest representative service, deploy it to a second target (AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster), replay real traffic for one full billing cycle, and publish three artifacts: hours to first green deploy, the measured monthly bill, and the breakage list with an owner per line.
• The expensive lock-in is almost never compute. Containers move in days. Proprietary datastore APIs (DynamoDB, Firestore, Cosmos DB), data gravity plus egress, and the undocumented IAM and networking glue move in quarters.
• Model switching cost in four layers: list price from provider calculators, planned-architecture cost from Infracost on the Terraform plan, post-move measured allocation from OpenCost or Kubecost plus native cost tools, and engineering weeks including dual-running. Teams that only model layer one miss NAT gateway hours and per-GB processing, cross-AZ transfer, load balancer LCUs, observability ingest, and idle non-production.
• Run the drill on a schedule, like a disaster recovery exercise - once or twice a year on one revenue-carrying service - so the exit path exists before contract renewal. A tested exit with a measured bill attached changes your negotiating position even if you never migrate.
• Qovery keeps portability testable by default. It deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so git-push deployments, preview environments per pull request, auto-stop, managed cluster upgrades, and per-environment RBAC follow the workload when the target changes - while the cloud bill and committed-use discounts stay in your name.

---

Cloud portability is a number you measure, not a property you assume. Most architecture diagrams claim it ("we're cloud agnostic") and almost none of them have ever been run against a second provider. The honest version of portability is a stopwatch and an invoice: how many engineering weeks, and how many dollars, to stand one real workload up somewhere else and keep it serving traffic.

This is a guide to getting that number before a vendor, a regulator, or an acquisition gets it for you. We will give you a 0-3 scorecard, a two-week drill you can start Monday, a four-layer cost model, and an honest tour of where lock-in actually hurts. Prices below are at list price, as of 2026, and every figure links to its primary source.

What does "cloud portability" actually mean, and how do you measure it?

Cloud portability is the measured time and cost to run a given workload on a second provider or cluster, expressed as engineering weeks plus a dollar delta - not an architectural ideal. You measure it by scoring each workload 0-3 across five layers (compute, data, networking, identity and secrets, CI/CD and IaC), where 3 means you redeploy the same artifact unchanged and 0 means you rewrite. Your lowest layer score sets your switching cost, not your average.

Copy this rubric into a spreadsheet and score one service at a time:

• 3 - redeploy the same artifact unchanged.
• 2 - config changes and re-tuning only.
• 1 - significant redesign of a component.
• 0 - rewrite required.

Any layer scoring 0 or 1 is where the migration timeline actually lives. Here is what portable versus locked looks like in each layer, and how to test it inside the drill.

One crisp distinction: portability is not multi-cloud. Portability buys you the option to move; multi-cloud means running everywhere at once and doubling your operational surface. Most organizations already touch more than one cloud without choosing to - Flexera's 2025 State of the Cloud Report found respondents run an average of 2.4 public clouds and 70% use a hybrid mix. That is prevalence, not portability.

Say the trade-off out loud: full abstraction costs you performance, cost efficiency, and developer speed. The goal is a bounded, known switching cost, not zero lock-in.

Keep the destination set open. AWS, GCP, Azure, Scaleway, and a bring-your-own existing Kubernetes cluster are all realistic sources and targets. Kubernetes is the most common portability substrate because the contract is the container image plus manifests, and the CNCF Certified Kubernetes conformance program now covers more than 100 certified distributions and platforms. What conformance does not cover is the part that bites: managed services, IAM, load balancer behaviour, storage classes, and ingress controller specifics all sit outside the conformance test suite. So "is Kubernetes really portable" has a precise answer - the container contract is portable, the managed glue around it is not.

A worked example makes the scoring concrete. A service scores compute 3, data 1, networking 2, identity 1, CI/CD 3. The average is 2, which looks comfortable. The truth is the two 1s: data and identity set the entire timeline, and the compute score is irrelevant to it. Score at the service level, not the estate level, and re-score any time a team adopts a new managed service.

Why should you test cloud portability before you need to switch?

Because every forced migration runs on a deadline you did not choose, and an untested escape path is an assumption, not a plan. The triggers are predictable, and each one arrives with its own clock:

• Discount or contract expiry - weeks of notice before a committed-use term renews at a worse rate.
• Sovereignty and data residency rules - a regulatory deadline you cannot negotiate.
• GPU or region capacity shortages - immediate, with no warning at all.
• Acquisition integration mandates - a quarter-end to consolidate onto the parent company's cloud.
• Vendor product or pricing changes - whatever notice the vendor decides to give you.

The canonical example is Heroku ending its free product plans. The company announced the change in August 2022 and switched the free tiers off on November 28, 2022, which created unplanned migration work for thousands of teams who had treated "it just works" as permanent. None of them chose that timeline.

Cost pressure is the most common trigger of all. In Flexera's 2025 report, 84% of organizations named managing cloud spend their top challenge, self-reported waste sat at 27% of spend, and budgets were already running over by roughly 17%. When the finance team asks where the money goes, "we're locked in" is not an answer anyone wants to give.

The regulatory direction of travel makes the exit cheaper, not more expensive, which is exactly why testing it is worth more now. The EU Data Act (Regulation (EU) 2023/2854) phases out switching and egress charges: its switching provisions apply from September 12, 2025, and switching charges must be fully withdrawn from January 12, 2027.

The leverage argument is the one to internalize. A tested exit path with a measured bill attached is the strongest artifact you can bring to a renewal conversation, even if you never migrate. Every portability test should produce three deliverables: a scorecard, a measured bill for one full billing cycle, and a runbook listing known breakages with an owner on each line. The failure mode to avoid is the opposite of all three - the architecture diagram that says "cloud agnostic" and has never been run anywhere twice.

How do you run a cloud portability drill in two weeks?

Run six steps in two weeks: pick your heaviest representative service, inventory every dependency by name and version, codify the target in Terraform or OpenTofu plus Helm, deploy it to a second target with cost allocation tags from the first resource, replay real traffic across one full billing cycle, then publish the engineering hours and the breakage list. Two weeks of elapsed effort surfaces every real blocker, even though the billing measurement runs longer.

1. Choose the workload that represents your cost and complexity profile - heaviest data volume or highest traffic, never the easiest service. A stateless hello-world proves nothing and produces a falsely high score.
2. Inventory dependencies explicitly and by version - managed database engine and version, object storage API, queues and event buses, secrets store, identity provider, DNS, observability sinks, cron and batch jobs, and any provider-specific SDK calls buried in application code.
3. Codify the target in Terraform or OpenTofu and Helm so the drill produces reusable artifacts, and price the plan with Infracost inside the pull request before anything is built. Infracost estimates monthly cost from a Terraform plan, but note its documented limits: usage-based resources need a usage file, and some resources are unsupported.
4. Deploy, apply cost allocation tags from the first resource, and point native cost tooling at it - AWS Cost Explorer, Google Cloud cost table reports, or Azure Cost Analysis, plus OpenCost or Kubecost if the target is Kubernetes. The AWS Cost Explorer console is free; its API costs $0.01 per request, so script against it sparingly.
5. Run mirrored or replayed production traffic with k6 or GoReplay and measure p95 latency, error rate, and cost per request against the incumbent. "It boots" is not a result.
6. Publish the breakage list and the engineering hours. Those two artifacts are the deliverable; the running service is a by-product.

Separate fixed costs from per-workload costs so that extrapolating to the rest of the estate stays honest. The fixed line includes NAT gateways, load balancers, log-ingest baseline, and managed Kubernetes control plane hours: roughly $0.10 per cluster-hour on EKS (about $73/month), $0.10 per cluster-hour on GKE with one zonal or Autopilot cluster covered by a monthly credit, and $0.10 per cluster-hour on the AKS Standard tier while the AKS free tier charges nothing for cluster management.

Hard exit criteria, as a checklist you either pass or fail:

• You can rebuild the environment from code in under one day.
• You know the measured monthly delta within plus or minus 20 percent.
• Every breakage has a named owner and an estimate.
• The Terraform and Helm artifacts are merged to main, not stranded in a branch.

Which tools help you test and price cloud portability, and what does each one miss?

No single tool measures portability. Use provider calculators for list-price infrastructure, Infracost for the architecture you plan to write, OpenCost or Kubecost for post-move allocation, Terraform or OpenTofu plus Crossplane for reproducibility, k6 or GoReplay for behaviour under real traffic, and the drill itself for everything a calculator cannot see: actual utilization, egress patterns, and engineering weeks.

A few honest caveats that matter more than the grid:

• Provider calculators quote list price only. They are blind to real utilization, egress patterns, commitments already in place, and people cost. Apply committed-use discounts and realistic utilization or the estimate will be wrong in both directions - usually optimistic on compute and badly low on data transfer and observability ingest.
• OpenCost validates a drill; it does not predict one. It needs a running cluster. OpenCost is a CNCF project that advanced to the Incubating maturity level in October 2024. Kubecost builds on it with a free self-hosted tier and paid enterprise tiers that reconcile against your actual billing data.
• IaC is portable in structure, not in provider resources. An aws_* resource block does not become a google_* block for free, and modules usually need rewriting per provider. OpenTofu keeps the language open, but it does not translate your cloud resources for you.
• AWS Migration Evaluator and Application Discovery Service are built for VM estates, not container-native workloads. Their stated scope is server inventory, utilization, and right-sizing for a datacenter migration business case. Pointing them at a Kubernetes service is a weak fit - say so and move on.

Infracost and OpenCost/Kubecost solve problems a deployment platform does not. Keep them in the kit regardless of what you deploy with.

Where is cloud lock-in actually expensive - compute, data, or the glue in between?

Compute is the cheapest layer to move and the most over-discussed: containers move in days. The expensive lock-in sits in proprietary managed services, data gravity plus egress, and the identity and networking glue nobody wrote down - layers that take quarters, not days.

Compute moves easily. The real cost is re-tuning instance families, autoscaling thresholds, and node sizing - days of work, not quarters.

Data is where the bill shows up, in two forms. The first is egress to move the data out. At list price, as of 2026, AWS charges $0.09/GB for the first tier of data transfer out to the internet after a 100 GB monthly free allowance; Google Cloud premium-tier internet egress starts around $0.12/GB; Azure bandwidth starts near $0.087/GB after its own 100 GB free allowance; and Scaleway bundles outbound bandwidth with its instances rather than metering it per GB.

Here is one worked example so you have a number instead of a rumour. Moving 50 TB out at list price, as of 2026, lands at roughly $4,300 on AWS, roughly $4,300 on Google Cloud premium tier, roughly $4,200 on Azure, and effectively $0 of incremental outbound on Scaleway because it does not meter instance egress per GB.

The counterweight is real but narrower than the headlines. All three hyperscalers introduced free data transfer out for customers leaving - Google in January 2024, AWS in March 2024, and Azure in March 2024 - alongside the EU Data Act provisions. Read the conditions before you count on them: these programs run through an approval process, require a defined exit window (typically 60 days), and Google and Azure require you to terminate the account entirely. "Free egress when leaving" means leaving completely, not sampling.

The second data cost is the engine itself. Proprietary managed services - DynamoDB, Firestore, Cosmos DB, provider-specific serverless runtimes and event buses - have no equivalent on another provider, so both the cost model and the behaviour have to be rebuilt. DynamoDB, for instance, bills per read and write request unit and per GB-month of storage, a model that simply does not exist elsewhere. Open engines are the opposite: a managed PostgreSQL on Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL Flexible Server, or Scaleway Managed Database lands in a broadly comparable monthly range at a similar vCPU/RAM/storage configuration, though each bundles storage, IOPS, and backups differently, so compare the full line item rather than the headline instance price.

Identity, secrets, and networking are the glue that quietly makes a workload immobile, because that is where the undocumented configuration lives: IAM roles and policies, service accounts, PrivateLink and peering designs, DNS. One fix - export every policy and peering definition into IaC during the drill, so the glue becomes a file instead of tribal knowledge.

Observability and CI/CD are usually the smallest cost and the fastest layer to make portable. Do this one first, because it is cheap and it raises your lowest-layer score quickly.

The decision rule: accept lock-in deliberately where a managed service buys real leverage, and write the estimated switching cost next to it in the architecture decision record so the trade is explicit rather than accidental.

How much does switching cloud providers actually cost, and how do you model it honestly?

Model the cost to switch cloud providers in four layers: list-price infrastructure from the provider calculator, planned-architecture cost from Infracost on the Terraform plan, post-move measured allocation from native cost tools plus OpenCost or Kubecost, and engineering weeks including dual-running. Layer four decides whether the move pays back, and it is the layer every calculator ignores.

• Layer 1 - price the target at list with the provider calculator, then apply commitments using published ranges: AWS Savings Plans advertise up to 72% off on-demand, Google Cloud committed-use discounts reach up to roughly 57% (and higher on some commitments), and Azure reservations up to around 72%. Cite the documented range, do not guess it.
• Layer 2 - price the planned architecture from the Terraform plan with Infracost before building, so the design decision and the cost decision land in the same pull request.
• Layer 3 - measure after the drill with native cost tools plus OpenCost or Kubecost allocation at workload granularity, across one full billing cycle so monthly fixed charges appear.
• Layer 4 - engineering weeks, dual-running both platforms through cutover, data migration and egress fees, retraining, and the opportunity cost of the roadmap you paused. Convert weeks to dollars with a loaded engineer cost so the number is comparable to the infrastructure delta.

The lines calculators routinely miss, each with a rate where one exists:

• NAT Gateway - an hourly charge plus per-GB data processing, roughly $0.045/hour and $0.045 per GB in us-east-1.
• Cross-AZ data transfer - around $0.01 per GB in each direction on AWS.
• Application Load Balancer - an hourly charge plus LCU charges, about $0.0225/hour plus $0.008 per LCU-hour per the ELB pricing page.
• Snapshot and backup storage - billed per GB-month, easy to forget until the bill arrives.
• Observability ingest - log and metric ingest scales with traffic and is frequently the second-biggest surprise after egress.
• Idle non-production - staging and preview environments running nights and weekends for no one.

The payback rule, with numbers: proceed when the measured monthly delta covers platform plus people cost inside a defined window - 6 to 12 months is a reasonable default. And say it plainly: staying put is frequently the correct answer. The drill still paid for itself as leverage and as documentation, whether or not you move.

How do you keep workloads portable without building a platform team?

Make four decisions, not a platform team: standardize on a container plus Kubernetes contract, make IaC the only path to production, prefer open data engines where the trade-off is acceptable, and put a deployment layer between your developers and the provider so the target can change without the developer workflow changing.

The four durable practices, stated as rules:

1. Containerize everything - the OCI image is the one artifact that moves intact.
2. Keep Terraform or OpenTofu as the only path to production - no console-clicked infrastructure, ever.
3. Choose PostgreSQL, MySQL, and S3-compatible interfaces where the trade-off is acceptable.
4. Keep secrets and identity behind a provider-neutral interface such as OIDC.

Then run the drill on a schedule. Treat it exactly like a DR exercise - once or twice a year, on one real revenue-carrying service, with a published scorecard anyone in engineering can read. This is how you avoid cloud vendor lock-in without a standing team: you prove the exit works, on a cadence, before you need it.

This is where Qovery fits. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so the cloud account, the bill, the committed-use discounts, and the cost data all stay in your name while the developer workflow stays identical across targets. When the target changes, the workflow does not. The capabilities that follow the workload are concrete: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades, and per-environment RBAC, with databases backed by managed cloud services. Managed cluster upgrades matter precisely because Kubernetes ships three minor releases a year and supports each for about 14 months - that is a maintenance treadmill you otherwise staff yourself.

Two of those capabilities pay back the switching-cost model directly. Auto-stop and preview environments attack the idle non-production line we flagged earlier - the staging and preview environments burning money nights and weekends. That is the same money, found twice.

Be fair about the boundaries. Qovery is a deployment and operations layer, not a cost-analysis or migration-assessment tool, so pair it with Infracost, OpenCost or Kubecost, or native cost tooling for the financial half of the drill. A single small app with no scaling or compliance pressure is often better off on Render, Fly.io, or Heroku, and Vercel's traffic-shaped pricing fits frontend workloads that an instance-shaped platform does not. What we see across customer migrations is that the teams who stay portable are the ones who kept the account, the IaC, and the container contract in their own hands - the platform choice follows from that, not the other way around.

How do you test cloud portability without running a full migration?

Run a two-week drill on one representative service: codify it in Terraform or OpenTofu and Helm, deploy it to a second target, replay real production traffic for one full billing cycle, and publish three artifacts - hours to first green deploy, the measured monthly bill, and a breakage list with an owner per line. You get the real switching number without moving production.

What is the difference between cloud portability and multi-cloud?

Portability is the option to move a workload to another provider at a known, bounded cost; multi-cloud is running across several providers at the same time. Portability is a property you test once or twice a year; multi-cloud is an operating model that doubles your operational surface. You can be portable on one cloud and never go multi-cloud.

Does Kubernetes actually make workloads portable between AWS, GCP, Azure, and Scaleway?

Partly. Kubernetes makes the container contract portable - the CNCF Certified Kubernetes program covers more than 100 conformant platforms - but conformance does not cover managed services, IAM, storage classes, load balancer behaviour, or ingress specifics. Your pods move in days; the glue around them is where the quarters go.

How much does data egress cost when you move between cloud providers?

At list price, as of 2026, internet egress starts around $0.09/GB on AWS, about $0.12/GB on Google Cloud premium tier, and about $0.087/GB on Azure, so moving 50 TB runs roughly $4,000 to $4,300. All three waive it for customers fully leaving, under an approval process and a defined exit window.

Which tools estimate cloud migration cost before you move?

Provider pricing calculators give list price; Infracost prices a Terraform plan inside the pull request before you build; OpenCost and Kubecost measure real per-workload cost after deployment. No single tool covers engineering weeks or egress patterns - the drill does that, by actually running the workload for a billing cycle.

How often should you run a cloud portability drill?

Once or twice a year, on one real revenue-carrying service, treated like a disaster recovery exercise. That cadence keeps the exit path current - the Terraform and Helm artifacts rebuildable, the breakage list fresh, the measured bill recent - so the exit exists before a contract renewal, capacity shortage, or acquisition forces the question.

When is accepting cloud vendor lock-in the right decision?

When the managed service buys real leverage - a proprietary datastore or serverless runtime that genuinely outperforms the portable alternative - and you have written the estimated switching cost next to it in the architecture decision record. Lock-in is a trade, not a sin. The mistake is accepting it by accident and never pricing the exit.

Portability you have not tested is a hope, not a plan. A tested exit, with a measured bill attached, is leverage whether or not you ever use it.