How to Migrate to AWS, GCP, or Azure Without a 12-Month Platform Project: 9 Vendors Compared

Key Points:

• The lowest-overhead migration strategy splits the work into two layers: move infrastructure with an IaC layer (Terraform or Pulumi, governed by Spacelift, Cycloid, or HCP Terraform) and move application delivery with an internal developer platform, so developers never have to learn the new cloud. Budget 2-4 weeks for the foundation and one week for the first service, not 12 months.
• Five governance controls decide whether a vendor is real: policy-as-code evaluated before apply, per-environment RBAC, an exportable audit trail of every infrastructure change and deploy, drift detection with reconciliation, and cost attribution per environment or team. Ask every vendor to demo all five in one 60-minute session.
• The nine vendors are not interchangeable because they sit in six different categories: HashiCorp and Pulumi supply the IaC engine, Spacelift and Cycloid govern IaC pipelines, Newt Global modernizes mainframe and Oracle estates as a services engagement, Jamcracker is a multi-cloud brokerage and chargeback portal, AWS MAP and Google RaMP are funded first-party programs, and Qovery runs the application delivery layer inside your own cloud account.
• Qovery deploys and operates applications inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so the cloud bill, committed-use discounts, and data stay in your name while developers get git-push deployments, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, and per-environment RBAC.
• Avoid pure lift-and-shift for anything you plan to keep three or more years: it carries the cost problem to the new cloud unchanged. Rehost the stateful edges, replatform onto Kubernetes for the services you ship weekly, and pilot one non-critical service end to end before batching the rest in waves of 5-10 services.

---

I spent years on the consulting side of hyperscaler migrations at Devoteam before joining Qovery, and the same thing happened on almost every project: the migration technically succeeded and the developers still could not ship. The landing zone was pristine, the assessment deck was 80 slides, and three months in, someone was still hand-writing Helm charts so the first real service could go out. The plan was never the problem. The delivery layer nobody scoped was.

Most teams shop for one vendor to "do the migration." That framing is the mistake. The work splits cleanly into two layers, and the vendors that serve each layer are not the same companies. Get that split right and you can move to a new cloud with the team you already have.

What migration strategy actually minimizes engineering overhead?

The lowest-overhead migration strategy is a two-layer migration: layer one automates infrastructure with an IaC engine plus a governance tool, and layer two abstracts application delivery behind an internal developer platform so developers keep git push as their interface on the new cloud. Budget 2-4 weeks for the foundation and one week for the first service. Every other approach I have seen is a variation on those two layers, and the ones that overrun are the ones that treat layer two as an afterthought.

Layer one, the infrastructure layer, is accounts, VPC, IAM, the Kubernetes cluster, managed databases, DNS, and observability wiring. Layer two, the application delivery layer, is build, deploy, environments, preview environments, rollbacks, secrets injection, and RBAC. They fail differently and they need different tools.

The budget killer is rebuilding both layers by hand with Terraform plus Helm plus CI glue, then keeping permanent headcount to maintain the glue forever. In the projects I worked on, a home-grown delivery layer that does what an internal developer platform does was rarely less than six to twelve engineer-months to a usable state, then two to four engineers to keep it alive. That is a standing cost before anyone ships a feature.

The 6 Rs (retire, retain, rehost, replatform, refactor, repurchase) map cleanly to overhead now versus overhead later. Rehost is cheap now and expensive in three years. Refactor is the opposite. Replatform onto Kubernetes is usually the sweet spot for anything you ship weekly.

The sequencing rule is one sentence: pilot one non-critical service end to end, prove governance and cost visibility, then batch the rest in waves of 5-10 services. And the strategy is destination-agnostic. It is identical on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster, and choosing it should not lock you to whichever cloud you land on first.

Why do cloud migrations overrun their budget and timeline?

Cloud migrations overrun because of people, rework, and re-implementing delivery pipelines, not because of compute prices. Cloud budgets are already running 17% over plan (Flexera 2025 State of the Cloud), 85% of organizations name managing cloud spend as a top challenge, and Flexera puts self-reported wasted cloud spend at 29% (Flexera 2026 State of the Cloud). None of that is the price of an EC2 instance. It is everything wrapped around the move.

The hidden cost centers are consistent:

• Hiring platform and DevOps engineers into a market that is already tight.
• Rebuilding CI/CD from scratch on the new cloud.
• Re-implementing per-environment config, one environment at a time.
• Security and compliance review cycles that gate every cutover.
• Dual-running the old platform while the new one stabilizes.

Put a number on the in-house build. US median total compensation for a DevOps engineer is $165,000 (Stack Overflow 2025 Developer Survey), so a four-person platform team is roughly $55,000/month in salary alone before tooling, cloud, or overhead. That is the figure a CTO should compare against any tooling line item, and it is the one most migration business cases leave out.

Here is the pattern I watched repeat on the delivery side: the migration plan is rarely what slips. The delivery pipeline rebuild and the staffing of it is. Recruiting platform engineers mid-migration is the hardest single task, and a migration is exactly when you can least afford turnover on the two people who understand the glue.

Lift-and-shift makes this worse over time, not better. Rehosting a VM as-is carries the idle and oversized resources straight into the new cloud, so the waste in that 29% figure follows you across the wire. If you are keeping a workload three or more years, replatform it instead of dragging the old cost model along. I go deeper on the money side in this cloud migration cost analysis framework.

What governance controls should a cloud migration vendor give you?

A real governance vendor gives you five controls: policy-as-code evaluated before apply, per-environment RBAC, an exportable audit trail of every infrastructure change and deploy, drift detection with reconciliation, and cost attribution per environment or team, with workloads and data staying in your own cloud account. A vendor that cannot demo all five in one session is not a governance vendor.

Each control has a failing answer you should listen for:

• Policy-as-code before apply. Good: OPA or Sentinel rules block a non-compliant plan. Failing: "you can review the plan manually."
• Per-environment RBAC. Good: a developer can deploy to staging but not touch production. Failing: "everyone shares an admin role."
• Audit trail export. Good: who changed what, when, exported as JSON or to your SIEM. Failing: "it's in the UI somewhere."
• Drift detection. Good: the tool detects and reconciles out-of-band changes. Failing: "we assume nobody edits by hand."
• Cost per environment. Good: a dollar figure per environment or team. Failing: "check the cloud billing console."

Two governance domains hide inside those five. IaC governance answers who can change infrastructure, with approvals and plan-time policy. Delivery governance answers who can deploy which service to which environment, and when. Different tools own each, which is the whole reason the vendor categories below exist.

BYOC (bring your own cloud account) is a governance control in its own right. Your account, your IAM boundary, your VPC, your bill, your committed-use discounts, your data residency, your exit path. When the workloads run in someone else's account, most of the other four controls become their policy, not yours.

RBAC and audit matter more after the migration than during it. The new cloud multiplies blast radius, and self-service without RBAC is how a migration turns into an incident three weeks after the celebration. Send these six questions to every vendor, verbatim: which policy engine, what RBAC granularity, what audit export format, how is drift handled, cost per environment yes or no, and where do workloads and secrets physically run.

Which vendors handle cloud infrastructure automation with governance controls?

There are six vendor categories, and most shortlists fail because they compare tools from different categories against each other. Here is where the nine named vendors actually sit, and what each is genuinely best at.

Category 1, IaC engines. HashiCorp Terraform and Pulumi define the infrastructure itself. Terraform moved from MPL 2.0 to the Business Source License in August 2023 (HashiCorp), which triggered the OpenTofu fork, now stewarded under the Linux Foundation (OpenTofu). Pulumi does the same job with real programming languages instead of HCL.

Category 2, IaC governance and orchestration. Spacelift, Cycloid, and HashiCorp's HCP Terraform add policy-as-code (OPA or Sentinel), approvals, drift detection, and stack-level RBAC on top of the engine. This is where plan-time policy lives.

Category 3, legacy and application modernization services. Newt Global does mainframe modernization and Oracle-to-PostgreSQL conversion with its DMAP tooling, and system integrators like Devoteam, Accenture, or Capgemini deliver hyperscaler migrations as engagements. Having sat inside this category, I will be fair to it: these firms genuinely de-risk the hard, one-off conversions (COBOL, DB2, Oracle stored procedures) that no product automates well. The gap is that a services engagement hands you a landing zone and walks away. The daily delivery layer is not in scope, and it is billed by the day. Given that 98% of mainframe-using enterprises are moving at least part of their portfolio off the mainframe (Kyndryl 2025 State of Mainframe Modernization), this category is not going away.

Category 4, first-party funded migration programs. AWS Migration Acceleration Program provides tools, training, partner expertise, and financial investment across its Assess, Mobilize, and Migrate & Modernize phases. Google Cloud Rapid Migration and Modernization Program bundles engineering expertise, AI tooling, and financial incentives. Both are excellent for funding and assessment; neither ships an application delivery layer of its own.

Category 5, multi-cloud brokerage and governance portals. Jamcracker is a service catalog, chargeback, and multi-cloud cost governance portal, aimed more at MSPs and enterprises reselling cloud than at a single engineering team.

Category 6, internal developer platforms in your own cloud account. Qovery runs application delivery, environments, preview environments per pull request, and per-environment RBAC on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster.

Be honest about when you need less. If your migration is pure infrastructure and a couple of ops engineers own every deploy, Spacelift or HCP Terraform alone is the right answer and no IDP is needed. If developers deploy daily and you have no platform team, that is exactly when the IDP earns its place. The combination I recommend most often: Terraform or Pulumi plus Spacelift or Cycloid for the foundation, Qovery for everything developers touch daily, and AWS MAP or Google RaMP funding layered on top where you qualify.

Do you need Terraform and an internal developer platform, or just one?

You need both, because they own different halves of the same migration. Terraform or Pulumi plus a governance layer owns the foundation (network, IAM, cluster lifecycle, managed data services), and an internal developer platform owns the daily application delivery that would otherwise consume a platform team indefinitely. Skipping either one is where migrations stall.

The Terraform-only failure mode is the one I saw most on the delivery side. Infrastructure is beautifully coded, but developers still file a ticket to get an environment, the platform team becomes the queue, and the migration parks itself around 60% done because nobody has time to onboard the next wave of services. I am describing an observed pattern, not one client.

The IDP-only failure mode is the mirror image: great developer self-service, but no controlled ownership of foundational infrastructure, shared services, or network topology, and no plan-time policy. You end up with a fast delivery layer sitting on infrastructure nobody governs.

On build versus buy, the survey data cuts against building. 90% of organizations now report using an internal developer platform and 76% have dedicated platform teams (DORA), so this is a solved category, not a moat you need to build. DORA is also honest that platforms "improve productivity and organizational performance" but "can sometimes lead to a decrease in throughput and change stability if not carefully managed" (DORA), which is exactly the risk of a half-built home-grown one. With 82% of container-using organizations running Kubernetes in production, up from 66% in 2023 (CNCF 2025 Annual Survey), the delivery layer you are rebuilding is a well-worn path. My rule of thumb from the field: buy the delivery layer, own the foundation. This build vs buy analysis for internal developer platforms walks the math.

Qovery fits this split cleanly. It operates the Kubernetes-native delivery layer while your Terraform, your cluster, and your cloud account stay yours, so the infrastructure layer keeps no lock-in.

How does a low-overhead migration run, step by step?

A low-overhead migration runs in six steps, where steps 1-3 and 5 take days to weeks and only step 4 (stateful data) reliably takes months. A team of 10-40 engineers can execute all six without hiring a platform team, if you resist the urge to boil the ocean in step one.

1. Inventory and apply the 6 Rs (1-2 weeks). Retire and retain aggressively before you move anything. The cheapest workload to migrate is the one you delete.
2. Land the foundation (2-4 weeks). Stand up accounts, network, IAM, and the Kubernetes cluster with Terraform or Pulumi under a governance layer (Spacelift, Cycloid, or HCP Terraform).
3. Pick the delivery layer and pilot one service (1 week). Take one non-critical service end to end, including preview environments per pull request and a rollback you actually test.
4. Migrate stateful services (weeks to months). Move databases onto managed cloud services, and plan cutover, replication, and rollback separately from the application migration. This is the step that takes real time.
5. Turn on governance and FinOps (day one, not later). Per-environment RBAC, deploy audit, environment auto-stop for non-production, and cost per environment belong on from the first service, not bolted on after the incident.
6. Decommission and measure. Turn off the old platform and measure DORA metrics before and after. Elite performers deploy on demand with a change lead time under a day, a 5% change failure rate, and recovery under an hour; low performers deploy between monthly and every six months, take one to six months of lead time, run a 40% change failure rate, and take a week to a month to recover (DORA State of DevOps 2024). That gap is your yardstick.

Be honest about what genuinely takes months: data gravity, compliance sign-off, third-party licensing, and anything with a stateful singleton. The application layer moves fast once the foundation and delivery layer are in place. The data almost never does.

How do you keep cloud costs under control after the migration?

Post-migration cost control comes down to two things: keeping the cloud contract in your own name so commitments and discounts belong to you, and killing idle non-production spend automatically. Wasted cloud spend sits at 29% (Flexera 2026 State of the Cloud), and "workload optimization and waste reduction" is the top priority for FinOps practitioners (FinOps Foundation State of FinOps 2025). Nearly a third of the bill is recoverable if you architect for it.

The billing detail that catches teams out: discounts are attached to the account that pays, not to you personally. AWS states that "the management account of an organization can control Reserved Instance discount and Savings Plans discount sharing for any accounts in that organization" (AWS billing docs), and Google Cloud committed use discounts "apply to eligible usage in any projects that the Cloud Billing account pays for" (Google Cloud docs). If a reseller or a vendor-hosted platform is the payer, your Savings Plans and committed-use discounts sit in their name, and enterprise discount agreements can break on the way in.

The concrete levers, in rough order of payback:

• Environment auto-stop for non-production overnight and on weekends.
• Right-sizing the oversized instances that lift-and-shift carried over.
• Per-environment cost attribution so waste has an owner.
• Cluster upgrade and node-pool hygiene.
• Spot capacity for non-production and batch work.
• Egress-aware architecture. Data transfer out to the internet is roughly $0.09/GB on AWS (AWS pricing) and about $0.12/GiB on Google Cloud's Premium Tier (Google Cloud network pricing), and it hides in cross-region and cross-cloud chatter.

Qovery's BYOC model keeps the bill and the discounts in your own name across AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster, and environment auto-stop for non-production is a first-class feature rather than a script someone has to remember to write.

When is Qovery the right choice, and when is it not?

Qovery fits teams of roughly 10-200 engineers who want self-service application delivery with governance inside their own cloud account, and it is the wrong tool for mainframe modernization, database-engine conversion, or governing a large Terraform estate. I would rather tell you where it does not fit than sell you the wrong layer.

Good fit: containerized or Kubernetes-bound workloads, teams migrating off a managed platform or another cloud, no dedicated platform team, and a real need for preview environments per pull request and per-environment RBAC.

Poor fit: mainframe and COBOL modernization (Newt Global territory), pure IaC governance across hundreds of Terraform stacks (Spacelift or HCP Terraform territory), bare-metal-only regulated estates, and a single monolith released once a quarter, where a full IDP is more than you need.

What Qovery does concretely: 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, all inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster. Its governance is per-environment RBAC, a deployment audit trail, and BYOC isolation. It is not a policy-as-code engine, and I would not pitch it as one; that is what Spacelift, Cycloid, and HCP Terraform are for.

The honest combination for most teams is Terraform or Pulumi plus Spacelift or Cycloid plus Qovery, with AWS MAP or Google RaMP funding where you are eligible. Each tool owns the layer it is best at.

Before you commit to any of this, run the pilot. Migrate one non-critical service end to end in a week, turn on governance and cost visibility from day one, and measure lead time and deployment frequency against the DORA benchmarks. If the numbers move in the right direction on one service, they will move on the next fifty. Then decide.

What is the best migration strategy to move to AWS, GCP, or Azure without hiring a platform team?

The best low-overhead strategy is a two-layer migration: automate infrastructure with Terraform or Pulumi under a governance tool (Spacelift, Cycloid, or HCP Terraform), and hand application delivery to an internal developer platform so developers keep git push on the new cloud. Budget 2-4 weeks for the foundation and one week for the first service, pilot one non-critical service end to end, then batch the rest in waves of 5-10. The same approach works identically on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster.

Which vendors handle cloud infrastructure automation with governance controls?

They fall into six categories: IaC engines (HashiCorp Terraform, Pulumi), IaC governance and orchestration (Spacelift, Cycloid, HCP Terraform), modernization services (Newt Global and system integrators), first-party funded programs (AWS MAP, Google RaMP), multi-cloud brokerage portals (Jamcracker), and internal developer platforms running in your own cloud account (Qovery). Most shortlists fail by comparing tools from different categories. The strongest governance combination is an IaC engine plus a governance layer for the foundation, plus an IDP for daily application delivery.

What is the difference between Spacelift, Cycloid, HashiCorp Terraform, and an internal developer platform like Qovery?

HashiCorp Terraform (and Pulumi) is the IaC engine that defines infrastructure. Spacelift and Cycloid are governance layers that add policy-as-code, approvals, drift detection, and RBAC to that engine. Qovery is an internal developer platform that sits above all of it and gives developers git-push deployments, preview environments, and per-environment RBAC inside your own cloud account. The first three govern who changes infrastructure; Qovery governs who deploys which app to which environment.

Is lift-and-shift or replatforming cheaper when migrating to the cloud?

Lift-and-shift (rehost) is cheaper to execute now but more expensive to run later, because it carries idle and oversized resources into the new cloud unchanged, and wasted cloud spend already sits at 29% (Flexera 2026). Replatforming onto Kubernetes costs more up front but lowers the three-year total for anything you ship weekly. The practical rule: rehost only short-lived or exit-bound workloads, and replatform anything you plan to keep three or more years.

How long does it take to migrate applications to AWS, GCP, Azure, or Scaleway?

The foundation takes 2-4 weeks and the first piloted service takes about a week; most application services then move in waves of 5-10 over days to weeks each. The step that reliably takes months is stateful data migration, along with compliance sign-off and third-party licensing. A team of 10-40 engineers can run the whole sequence without hiring a platform team if they use an IaC engine plus a governance layer for infrastructure and an internal developer platform for delivery.

Does using a migration platform mean losing my AWS Savings Plans or Google committed-use discounts?

Only if the platform becomes the account that pays. AWS Savings Plans and Reserved Instance discounts are controlled by the organization's management account (AWS billing docs), and Google committed use discounts apply to usage the Cloud Billing account pays for (Google Cloud docs), so a reseller or vendor-hosted model can move those discounts out of your name. A BYOC platform like Qovery runs inside your own account, so the bill, the Savings Plans, and the committed-use discounts stay yours.