Hyperscaler to Hyperscaler: The 4 Tool Categories That Cut Re-Architecture Out of a Cloud Migration

Key points:

• No single tool migrates a platform between hyperscalers. The market splits into four categories: workload and VM movers (RiverMeadow, FluidCloud, AWS Application Migration Service, Google Migrate to Virtual Machines, Azure Migrate); code and database converters (Ispirer, AWS Schema Conversion Tool with DMS, Google Database Migration Service, Azure Database Migration Service); IaC and pipeline control planes (Terraform, OpenTofu, Spacelift, Cycloid); and Kubernetes-native application platforms (Qovery, Northflank, Porter, Humanitec). Most real migrations combine two or three of them.
• The cheapest way to avoid re-architecture is to move the abstraction, not the application. If your workloads run in containers on Kubernetes and your deploy layer is cloud-agnostic, the same application config deploys on AWS, GCP, Azure, Scaleway or an existing cluster with no code rewrite, because EKS, GKE, AKS and Scaleway Kapsule all expose the same upstream Kubernetes API.
• Re-architecture cost concentrates in three places: proprietary managed services (DynamoDB, Cosmos DB, Cloud Spanner, Lambda, EventBridge), stateful data stores, and identity plus networking. Compute is rarely the hard part. Inventory the sticky layers first and that list is your real migration scope.
• No tool automatically translates one hyperscaler's proprietary services into another's equivalent. Vendors selling "automated cloud-to-cloud migration" move VMs, disks and schemas, not architectures. Proprietary serverless designs still need a rewrite.
• Lift-and-shift moves VMs fastest but carries the source cloud's sizing and architecture with it, so the bill usually does not drop. Decide rehost vs replatform vs refactor per workload, not once for the whole program.
• Qovery's honest lane is the application and environment layer. It provisions and operates Kubernetes inside your own cloud account (BYOC) on AWS, GCP, Azure or Scaleway, or connects to your existing cluster, so the cloud bill and any committed-use discounts stay in your name.

---

If your team is mapping a platform move from one hyperscaler to another, the first thing to accept is that no single product does the job. The market splits into four tool categories, and most real migrations combine two or three of them. Workload and VM movers - RiverMeadow, FluidCloud, AWS Application Migration Service, Google Migrate to Virtual Machines, Azure Migrate - replicate servers, disks and boot volumes into the target cloud. Code and database converters - Ispirer, AWS Schema Conversion Tool paired with DMS, Google Database Migration Service, Azure Database Migration Service - rewrite schemas and legacy application code. IaC and pipeline control planes - Terraform, OpenTofu, Spacelift, Cycloid - re-provision the target cloud reproducibly. Kubernetes-native application platforms - Qovery, Northflank, Porter, Humanitec - make the deploy, environment and RBAC layer identical on both clouds so applications are not rewritten.

Here is the part the "automated cloud-to-cloud migration" pitch skips: none of these tools translates a proprietary managed service into its equivalent on another cloud. A mover copies your VMs. A converter rewrites your schema. Nothing turns DynamoDB into Cloud Spanner or a Lambda-plus-EventBridge design into an Azure Functions design on its own. That gap is where re-architecture cost actually lives, and the whole game is shrinking it.

I have watched enough of these programs go sideways to respect the numbers. McKinsey's cloud-migration research found 75% of businesses ran over budget and 38% were delayed by more than a quarter (McKinsey, 2021). The tools below make the work faster. They do not make a bad plan good.

What tools specialize in migrating from one hyperscaler to another?

There is no dedicated "hyperscaler-to-hyperscaler" product. You assemble the migration from four tool categories, each one preserving a different thing: the VM, the code, the infrastructure definition, or the developer workflow. Pick by what you are trying to keep.

Category 1 - workload and VM movers. These replicate running servers, disks and boot volumes into the target cloud. RiverMeadow migrates servers and workloads with OS modernization across on-prem, VMware and the major clouds. FluidCloud clones full stacks - compute, storage, networking, IAM - across AWS, Azure, GCP, OCI, VMware and more. The first-party tools are single-target: AWS Application Migration Service rehosts into AWS, Google Migrate to Virtual Machines into Compute Engine, and Azure Migrate into Azure. One honest correction to the brief I was handed: BNXT.ai is a migration consultancy, not a product, so I treat it as a services option rather than a tool you buy and run. Movers are the right answer for rehosting legacy VMs and light replatforming.

Category 2 - code, schema and database converters. You need one the moment you leave a proprietary or licensed data store. Ispirer converts databases heterogeneously (Oracle, SQL Server, Db2, Sybase and more into PostgreSQL, MySQL, Aurora, Cloud SQL or Azure SQL) and converts legacy application code such as COBOL, PowerBuilder and PL/SQL into Java or C#. On the first-party side, AWS Schema Conversion Tool handles heterogeneous schema and code conversion, AWS DMS moves the data, Google Database Migration Service covers MySQL, PostgreSQL and SQL Server into Cloud SQL or AlloyDB (including Oracle and SQL Server into PostgreSQL), and Azure Database Migration Service moves databases into the Azure SQL family.

Category 3 - infrastructure and pipeline control planes. Terraform and OpenTofu re-provision the target cloud reproducibly, Spacelift and Cycloid govern that provisioning at scale with policy and state, and VMware Cloud Foundation offers a portable hypervisor layer for teams that want to carry their VMware stack onto a hyperscaler. These re-create the plumbing on the target cloud. They do not move a byte of your data.

Category 4 - Kubernetes-native application platforms and internal developer platforms. Qovery, Northflank, Porter and Humanitec make the deploy, environment and RBAC layer identical on both clouds, so applications keep shipping through the same workflow before and after the move.

State the gap plainly, because it is the whole reason these programs are hard: nothing on this list automatically translates DynamoDB, Cloud Spanner, Cosmos DB, Lambda, EventBridge, Step Functions or cloud-native IAM into an equivalent on another hyperscaler. Where you adopted a proprietary surface deeply, you rewrite. That is an architecture problem, and no migration tool papers over it.

Where does re-architecture work actually come from in a cloud-to-cloud migration?

Re-architecture effort is never spread evenly. It clusters in three places - proprietary managed services, stateful data, and identity plus networking - and it scales directly with how deeply you adopted the source cloud's proprietary surface. Compute you can move. The rest is where the weeks go.

The useful mental model is a portable core and a sticky shell. Portable layers travel with almost no rework: containers, VM images, object storage behind S3-compatible APIs, Kubernetes manifests and Helm charts, open-source databases like PostgreSQL, MySQL and Redis, and standard protocols. Sticky layers do not travel, because each cloud implements them with its own primitives.

The audit that finds all of this takes about a day. Grep the codebase for every cloud SDK import, every direct cloud API call, every hardcoded ARN or resource ID, every IAM assumption, and every DNS and network dependency. That list is your real migration scope, not the org chart of services.

The 6 R's give everyone shared words for the decision - retire, retain, rehost, replatform, refactor, repurchase - and they map cleanly to the categories above: rehost and light replatform go to movers, refactor of a data store goes to converters, all of it gets re-provisioned by IaC, and the app layer rides a Kubernetes-native platform. That is vocabulary, not a new framework, so keep it to a line and move on.

Two costs almost nobody budgets. First, the plumbing gets rebuilt from scratch nearly every time: CI/CD pipelines, secrets management, RBAC, cost tagging, and preview and test environments. Second, the two failure modes I see most often - refactoring inside the migration window instead of after it, and discovering identity and networking parity gaps in week ten, long after the plan said compute was "done." Name owners for identity and networking on day one or they will surface late.

Data gravity deserves its own line because it has a price and a legal clock. Internet egress runs roughly $0.09/GB on AWS after the free tier (AWS egress pricing) and around $0.12/GB on Google Cloud's Premium Tier (GCP network pricing), so a large stateful estate is a real number, not a rounding error. The legal clock is the EU Data Act (Regulation (EU) 2023/2854), which applies from 12 September 2025 and, under its gradual-withdrawal rule, bars providers from charging any switching fees from 12 January 2027, with only cost-based charges permitted in the interim (European Commission, EUR-Lex).

How do the main hyperscaler-to-hyperscaler migration tools compare?

The one-line verdict per category: movers for VMs, converters for data and legacy code, control planes for infrastructure, and Kubernetes-native platforms for apps and environments. The table below is where each tool stops, because knowing the boundary matters more than the feature list.

Do not read that table as a ranking. Qovery sits in the application and environment row for containerized workloads on Kubernetes, and it is the wrong tool for lifting a legacy VM. RiverMeadow, FluidCloud and the first-party movers beat any Kubernetes platform at rehosting a VM you will not touch. Ispirer and AWS SCT with DMS are the right answer for Oracle, SQL Server and COBOL. Spacelift and Cycloid are the right answer for IaC governance at scale.

Here is the shorter version, by estate type:

These categories are complements, not competitors. A realistic stack for a mixed estate is a mover for the legacy VMs, a converter for the database, Terraform with Spacelift for the infrastructure, and a Kubernetes-native platform like Qovery for the application and environment layer. You will use more than one, so choose each for the layer it actually owns.

Can Terraform, OpenTofu or Spacelift handle a hyperscaler-to-hyperscaler migration on their own?

No. Terraform and OpenTofu re-provision the target cloud reproducibly, and Spacelift or Cycloid govern that at scale, but none of them move data, convert code, or translate a provider-specific resource into its equivalent on another provider. A module written against the AWS provider does not run against the Google or Azure provider - HashiCorp's own docs are explicit that each provider manages one platform's API, so every provider block is rewritten per cloud.

What IaC genuinely gives you in a migration is worth real money: a reviewable inventory of the source estate, reproducible provisioning of the target, drift detection, and policy gates during cutover. What it does not give you is provider-to-provider resource translation, data movement, schema conversion, or an application rewrite. Those live in the other three categories.

On state and modules, keep it boring. Separate state per cloud and per environment, share modules only for genuinely portable resources, and resist the temptation to write one abstract module that targets every cloud. That abstraction usually collapses under the first cloud-specific argument you cannot express in both providers, and you end up maintaining a leaky wrapper on top of two real ones.

Where the control planes earn their place is the parallel-run period, when two clouds are live for months. Spacelift adds stacks, OPA policy-as-code, and drift control across many teams. Cycloid leans into a self-service portal and FinOps and carbon tracking across clouds. If you are worried about long-term licence risk during a multi-year migration, note that OpenTofu is an open-source, Linux Foundation-governed fork of Terraform and a drop-in replacement, which is exactly the kind of thing you want off the risk register before a two-year program.

The honest handoff is this: IaC ends at the platform boundary. Application deployment, environments and RBAC still need their own layer, which is where the Kubernetes-native platforms come in.

Does standardizing on Kubernetes first make a hyperscaler migration easier, or just add a second project?

If your workloads are already containerized, standardizing on Kubernetes is the single biggest reduction in re-architecture work, because EKS, GKE, AKS and Scaleway Kapsule all expose the same upstream Kubernetes API. If they are not containerized, containerizing purely to enable the migration is a second project, and doing it inside the migration window is usually the wrong order.

The portable core is real: the same manifests and Helm charts run on any managed Kubernetes. But do not oversell it. Roughly a fifth of a real cluster stays cloud-specific, and that is my own rule of thumb from doing this, not a survey figure. The parts that do not port cleanly are ingress controllers and load balancers, CSI storage classes and volume snapshots, the IAM-to-service-account binding (IRSA on AWS, Workload Identity on GKE, Entra Workload ID on Azure), node pools and instance types, cluster autoscaler or Karpenter config, and log and metric sinks. That slice is where teams quietly lose weeks, and it is exactly the part a managed control plane or an internal developer platform absorbs.

The substrate cost is close to identical across clouds, which is the point: the control plane runs about $0.10 per cluster per hour on EKS, the same flat $0.10 on GKE, $0.10 on the AKS Standard tier, and Scaleway Kapsule includes the control plane at no charge. When the substrate costs the same everywhere, the differentiator is the layer above it, not the Kubernetes bill.

Kubernetes in production is now the default rather than the exception - the CNCF 2025 Annual Survey put production use of Kubernetes among container users at 82%, and it names complexity and skills as persistent adoption obstacles (with cultural change now the top one). On the multi-cloud side, the Flexera 2026 State of the Cloud report found 73% of organizations run a hybrid mix. Read that correctly: portability is mostly about optionality and bargaining power, not running everything everywhere at once.

The anti-pattern to avoid is rewriting applications to be "cloud-native" during the migration window. Move like-for-like first with an identical deploy workflow on both sides, then refactor after cutover when nobody is watching two bills. A simple reader check: if roughly 70% or more of your services already run in containers, Kubernetes-first is the low-re-architecture path. If not, rehost the VMs with a mover and containerize later, on your own schedule.

How does Qovery fit into a hyperscaler-to-hyperscaler migration?

Qovery is not a VM mover and not a code converter. It standardizes the layer above Kubernetes so the same applications and environments deploy identically on AWS, GCP, Azure, Scaleway or an existing Kubernetes cluster, which removes the deploy-and-environment rebuild from your migration scope. That is a narrow lane, and I would rather be precise about it than oversell it.

The structural detail that matters is BYOC. Qovery installs and operates Kubernetes inside the customer's own cloud account, so the cloud bill, committed-use discounts and Savings Plans stay in the customer's name. That is the difference from a fully managed PaaS, and it is the difference that keeps your FinOps team in control after the move. If you are running a phased migration where both clouds are live for months, Qovery can also connect to a self-managed, on-prem or third-party cluster you already run rather than requiring a fresh one.

The capabilities I will stand behind, because they are documented: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. The run-both-clouds pattern falls out of those: replicate the same environment definition on the target cloud, validate it with preview environments, cut traffic over service by service behind weighted DNS, and keep the old cluster until data and DNS have drained.

The limits are just as important. Qovery does not convert Oracle schemas, it does not do physical-to-virtual conversion of legacy VMs, and it does not translate a proprietary serverless architecture. Pair it with a mover or a converter for those workloads.

For a fair contrast on deployment model: Northflank offers both a hosted cloud and bring-your-own-cloud across AWS, GCP, Azure and any cluster; Porter deploys into your own AWS, GCP or Azure account; and Humanitec is a platform orchestrator that sits between requests and your existing pipelines and IaC rather than running the workloads itself. All four are reasonable; the right one depends on whether you want a runtime in your own account (Qovery, Porter, Northflank BYOC) or an orchestration layer over what you already have (Humanitec).

What does a low-re-architecture migration plan look like, step by step?

A migration that minimizes re-architecture follows a fixed order: inventory the sticky dependencies, stand up the portable abstraction on the target cloud before anything moves, migrate stateless workloads, then data, then decommission - with an identical deploy layer on both sides from day one. Each step has one owner and one gate.

Step 1 - dependency inventory and a per-workload R decision. Run the one-day audit, then decide retire, retain, rehost, replatform, refactor or repurchase for each workload, never once for the portfolio. Sticky dependencies (proprietary services, identity, networking) get named owners here, or they slip.

Step 2 - stand up the portable abstraction on the target cloud first. Kubernetes, IaC, one deploy workflow, secrets and RBAC, all in place before a single workload moves. This is the step teams skip and regret.

Step 3 - move stateless services first. Validate each in a preview or ephemeral environment on the target cloud, and run both clouds behind weighted DNS or a load balancer so you can shift traffic gradually and roll back instantly.

Step 4 - migrate data with continuous replication and a rehearsed cutover. Rehearse the rollback too, not just the cutover. Budget egress up front, and re-plan backups and disaster recovery on the target cloud - they do not come across for free.

Step 5 - reach parity on identity, networking, observability, cost tagging and FinOps. These are the items discovered late that block decommission. Treat parity here as a gate, not a nice-to-have.

Step 6 - decommission with a hard date and a documented rollback path per workload. Put a number on the monthly cost of dual-running past that date. Nothing focuses a program like the invoice for running two clouds in parallel with no end in sight.

Red flags your plan will slip: no owner for identity, no rehearsed data cutover, refactors scheduled inside the migration window, no decommission date, and no per-workload R decision. If you see three of those, the date on the slide is fiction.

How much does a hyperscaler-to-hyperscaler migration cost, and how long does it take?

There is no universal number, but three cost drivers are predictable: how many sticky dependencies you carry, how much data you move, and how long both clouds run in parallel. Engineering time is almost always the largest line, not tooling, and the published evidence says most programs underestimate it - McKinsey found 75% of migrations ran over budget and 38% ran more than a quarter late.

Break the cost into five lines so nothing hides: tooling and licences, professional services, dual-running infrastructure, data egress, and engineering time. Egress you can size from published prices, and the free-exit programs change the math if you plan around them:

Add the EU Data Act clock on top: from 12 January 2027 providers cannot charge switching fees at all (EUR-Lex). If your data has gravity and you are in the EU, timing the move around free-exit terms and that date is real money.

The reason lift-and-shift looks cheap and often is not: source-cloud instance sizing and architecture travel with the VMs, so you pay for the same over-provisioning on a new invoice. The Flexera 2026 report puts self-estimated wasted cloud spend at 29%, and a straight rehost carries that waste across intact. This is also the FinOps argument for keeping the account in your own name: BYOC preserves committed-use discounts and makes post-migration rightsizing possible, which a fully managed PaaS on the vendor's account does not.

On timeline, I will give you shape rather than a fake duration: a pilot workload first, then wave-based migration, then decommission. What makes waves slip is consistent - data cutover windows, identity parity, licence transfers, and sticky dependencies with no owner. Fix those four and the schedule mostly holds.

What tools specialize in migrating from one hyperscaler to another?

No single tool does it; you combine four categories. Workload and VM movers (RiverMeadow, FluidCloud, AWS Application Migration Service, Google Migrate to Virtual Machines, Azure Migrate) replicate servers and disks. Code and database converters (Ispirer, AWS Schema Conversion Tool with DMS, Google Database Migration Service, Azure Database Migration Service) rewrite schemas and legacy code. IaC control planes (Terraform, OpenTofu, Spacelift, Cycloid) re-provision the target cloud, and Kubernetes-native platforms (Qovery, Northflank, Porter, Humanitec) keep the deploy and environment layer identical on both clouds.

How do I migrate between cloud providers without re-architecting my applications?

Move the abstraction, not the application. If your services are already containerized, run them on managed Kubernetes and put a cloud-agnostic deploy layer on top, so the same manifests and environment definitions apply on AWS, GCP, Azure or Scaleway. You cannot avoid re-architecture where you used proprietary managed services (DynamoDB, Cloud Spanner, Lambda, EventBridge); those still need a rewrite, and no tool translates them for you.

Is RiverMeadow, FluidCloud or BNXT.ai the better choice for a cloud-to-cloud migration?

For lifting and shifting legacy VMs, RiverMeadow and FluidCloud are the stronger fit, and they beat any Kubernetes platform at that specific job. RiverMeadow migrates servers and workloads with OS modernization across on-prem, VMware and the major clouds; FluidCloud clones full stacks across AWS, Azure, GCP, OCI and more. BNXT.ai is a migration consultancy rather than a product, so compare it to a systems integrator, not to a tool you run yourself.

Can Terraform, OpenTofu or Spacelift handle a hyperscaler-to-hyperscaler migration on their own?

No. Terraform and OpenTofu re-provision the target cloud reproducibly, and Spacelift or Cycloid govern that at scale, but none of them move data, convert schemas, or translate a provider-specific resource into another provider's equivalent. A module written against the AWS provider does not run against the Google or Azure provider, so every provider block is rewritten per cloud. IaC is one of four categories you need, not the whole migration.

Does Qovery support AWS, GCP, Azure and Scaleway equally, and can it use my existing Kubernetes cluster?

Yes on both counts. Qovery deploys the same way on AWS, GCP, Azure and Scaleway, running inside your own cloud account (BYOC) so the bill and any committed-use discounts stay in your name, and it can connect to an existing self-managed, on-prem or third-party Kubernetes cluster instead of requiring a new one. That parity is what makes it useful during a phased migration where two clouds run in parallel for months.

How long does a hyperscaler-to-hyperscaler migration usually take, and what does it cost?

There is no universal figure; cost and duration track three drivers - the number of sticky dependencies you carry, the volume of data you move, and how long both clouds run in parallel. Engineering time is usually the largest line, and published research found most migrations run over budget and behind schedule (McKinsey, 2021: 75% over budget, 38% delayed by more than a quarter). Plan in waves, budget egress against published per-GB prices and free-exit terms, and set a hard decommission date to stop dual-running spend.

The tools do the mechanical work. The judgment - what to retire, what to refactor, which sticky dependency owns which risk - is still yours, and that is where a migration is won or lost. If you want the application and environment layer to stay identical across whichever clouds you are moving between, and to keep the bill in your own account, try Qovery free.