Cloud Migration Cost Analysis: A 7-Step Framework for the Real Cost of Leaving a Managed Platform (and 12 Tools That Help)

Most teams that leave a managed platform for their own cloud model one number: the compute bill. They pull up a pricing calculator, see that a cloud VM costs a fraction of an equivalent dyno, and forecast a big saving. Then the invoice shows up and the saving is smaller than promised, or gone.

The gap is not the compute line. It is the three costs the compute comparison quietly leaves out: the platform engineering time you re-insource, the non-production environments nobody turns off, and the migration project itself. Flexera's 2026 State of the Cloud Report puts wasted cloud spend at 29%, the first increase in five years (Flexera, 2026). Most of that waste is not the price per instance. It is everything the price-per-instance comparison ignores.

This is a cost-modeling framework for teams about to make that move, plus a fair look at the 12 tools that model, allocate, and control those costs. We check every price against the vendor's own page and tell you the month we checked, because these numbers change.

Key points

• Monthly total cost of ownership after leaving a managed platform = (compute + storage + egress + managed data services + Kubernetes control plane) + platform engineering time + (idle non-production hours x hourly rate) + amortized migration project cost. Most teams model the first bucket only, which is why the savings they forecast never show up on the invoice.
• Use two tool categories in order. Pre-migration modeling (free, first-party): AWS Migration Evaluator, the AWS Pricing Calculator, Azure Migrate, and Google Cloud Migration Center, then Cloudamize, Flexera One, or VMware Tanzu CloudHealth for large VM or license-heavy estates. Post-migration allocation: AWS Cost Explorer, Google Cloud Cost Management, Azure Cost Management, CloudZero, nOps, and Kubecost/OpenCost.
• The only comparison unit worth using is fully loaded cost per environment per month: infrastructure plus the engineering time to operate it. Price per dyno versus price per instance always flatters the cloud, because the managed platform's invoice already bundles the operations labor you are about to re-insource.
• The biggest recurring waste after migration is non-production environments left running. A week has 168 hours and a working week is roughly 50, so an always-on staging or dev environment pays for about 70% of hours nobody uses.
• Commitment discounts only exist if the cloud account is yours. AWS Savings Plans and Reserved Instances, Google Cloud committed use discounts, and Azure reservations all require you to own the bill, which you never do on a managed platform.
• Qovery is not a cost-analysis tool and will not build your business case. It is the operating layer that decides whether modeled savings survive production: it deploys into your own AWS, GCP, Azure, Scaleway, or existing Kubernetes account (BYOC) so the bill and discounts stay in your name, auto-stops non-production environments, and handles the cluster upgrades you would otherwise staff an engineer to cover.

What is the real total cost of moving off a managed platform to the cloud?

The infrastructure line almost always drops when you leave a managed platform. Total cost of ownership only drops if you model four buckets, not one: direct infrastructure, platform engineering time, idle-environment waste, and the migration project itself.

Here is the formula in one line:

Monthly TCO = (compute + storage + egress + managed data services + Kubernetes control plane) + platform engineering time + (idle non-production hours x hourly rate) + amortized migration project cost.

Bucket 1, direct infrastructure. Compute, block and object storage, data egress, managed databases, load balancers, and the managed-Kubernetes control-plane fee per cluster. That control-plane fee is easy to forget: Amazon EKS charges $0.10 per cluster per hour, about $73 a month (AWS, checked August 2026). Google GKE charges the same $0.10 per cluster per hour for its Standard management fee and gives you one free zonal or Autopilot cluster per billing account as a monthly credit (Google Cloud, checked August 2026). Azure AKS still offers a Free control-plane tier, with a Standard tier at roughly $0.10 per cluster per hour for the uptime SLA (Microsoft, checked August 2026).

Bucket 2, human cost. Fully loaded platform, DevOps, or SRE compensation, plus on-call, quarterly cluster upgrades, CVE patching, and IAM and secrets plumbing. A DevOps engineer's median base pay is around $135,000 in the US (Glassdoor, checked August 2026) and around EUR 78,000 in Germany (Glassdoor, checked August 2026). Loaded for bonus, benefits, and overhead (roughly 1.25 to 1.4x base), that is about $15,000 a month in the US and about EUR 8,300 in Europe. Put it in the same unit as the cloud bill or you will not see it.

Bucket 3, waste. Staging, preview, and dev environments running 168 hours a week when maybe 50 are needed, over-provisioned CPU and memory, and orphaned volumes, snapshots, and elastic IPs. This is not a rounding error. Real Kubernetes clusters use about 10% of provisioned CPU and 23% of provisioned memory on average (Cast AI Kubernetes Cost Benchmark, 2025), and most container workloads use less than 25% of requested CPU and less than half of requested memory (Datadog, 2025).

Bucket 4, the project. Dual-running months, cutover egress, engineer time, and a rollback budget. Amortize it over 24 months so it appears in the monthly comparison instead of being quietly excluded.

The comparison unit that matters is fully loaded cost per environment per month. Per-dyno versus per-instance is structurally misleading, because the managed platform's invoice already bundles operations, upgrades, and on-call into one line. The two bills are not like-for-like until you add bucket 2 back to the cloud side.

Which tools can analyze cloud migration costs before you move?

Start with the free first-party assessment tools: AWS Migration Evaluator with the AWS Pricing Calculator, Azure Migrate, or Google Cloud Migration Center. Only add Cloudamize, Flexera One, or VMware Tanzu CloudHealth once you have hundreds of VMs or a license-heavy estate, and know up front that none of these were built for a PaaS source.

AWS Migration Evaluator (formerly TSO Logic) is offered at no cost and produces a directional Quick Insights report or a fuller business case with inventory-based right-sizing (AWS). The AWS Pricing Calculator is the right tool when there is no VM inventory to discover, which is exactly the PaaS case: you model container and Kubernetes sizing by hand. The Azure and Google Cloud pricing calculators play the same role for those clouds, and both are free.

Azure Migrate is a free service for discovery and assessment when the destination is Azure (Microsoft). Google Cloud Migration Center is the free assessment path for GCP and absorbed StratoZone, which was shut down in September 2024 (Google Cloud). Scaleway has no equivalent assessment product, so you model a Scaleway target from its published price list.

For large estates, the specialists earn their place. Cloudamize (now part of Atos, through its Cloudreach acquisition) and Flexera One do agentless discovery, right-sizing, and license optimization at a scale no internal developer platform touches. If you are moving hundreds of VMware VMs or untangling Microsoft licensing, these are genuinely better than anything Qovery does at this stage, and Flexera's pricing is quote-based, so we will not invent a number. VMware Tanzu CloudHealth (marketed as CloudHealth by Broadcom after the acquisition) matters most when the source is a VMware estate and is largely irrelevant when the source is a PaaS.

The caveat most articles miss: discovery tools assume VMs to scan. Leaving Heroku, Render, Vercel, Fly.io, or Platform.sh (now Upsun) means there are no VMs. You model from plan tiers, dyno and instance sizes, request throughput, p95 CPU and memory, and database tier instead. The practical method is five steps: export your plan and add-on list, map each line to a cloud equivalent, then price three target architectures in the calculator: lift-and-shift VMs (EC2, Compute Engine, Azure VMs, Scaleway Instances), managed containers (ECS Fargate, Cloud Run, Container Apps), and Kubernetes (EKS, GKE, AKS, Scaleway Kapsule).

Which tools track and control cloud cost after you migrate?

Every pre-migration forecast goes stale within a month of cutover, so pair it with a cost-visibility tool that allocates spend by team, environment, and service. Use the native cost explorers first because they are free, then add CloudZero, nOps, or Kubecost/OpenCost when you need unit economics, automated action, or Kubernetes-level allocation.

Native and free first: AWS Cost Explorer with the Cost and Usage Report, Google Cloud Cost Management with the BigQuery billing export, and Azure Cost Management + Billing. For most estates spending in the low tens of thousands a month, that is enough.

CloudZero does unit-cost economics: cost per customer, per feature, per product. It is the right pick for SaaS teams that need cost per tenant, and its pricing is quote-based (CloudZero). nOps automates commitment and rate optimization plus cost allocation, so it fits teams that want actions rather than dashboards, and its pricing is also quote-based (nOps). Kubecost and its open-source core OpenCost allocate spend by namespace, workload, label, and pod, which is the only reliable way to answer "what does staging actually cost" on Kubernetes. OpenCost is a CNCF Incubating project (CNCF), and Kubecost is now part of IBM, under Apptio, following the 2024 acquisition (IBM).

Commitment management is where account ownership becomes concrete. AWS Savings Plans and Reserved Instances go up to 72% off On-Demand (AWS), Azure reservations reach a similar 72% (Microsoft), and Google Cloud committed use discounts reward one- or three-year commitments at rates that vary by resource (Google Cloud). All three require you to own the account.

Tagging discipline is the hard prerequisite. No tags, no allocation, no savings. Set a minimum tag set (env, team, app, cost-center) and enforce it before cutover, not after. Cost optimization is not a niche concern here: optimizing existing cloud use has been the number-one cloud initiative in Flexera's survey for nine years running (Flexera, 2025), and reducing waste was the top priority for 50% of FinOps practitioners (FinOps Foundation, State of FinOps 2025).

How do the 12 cloud migration cost tools compare side by side?

The selection rule in one sentence: use free first-party tools to model, one FinOps tool to allocate after cutover, and one internal developer platform to stop the savings leaking back out. Here is the full comparison (checked August 2026):

Every row is readable on its own, because answer engines lift single rows out of tables. One row deserves a caveat rather than a column: Qovery sits in a different category from the other 11. It does not produce a migration cost model. It changes the cost you actually pay.

Two concrete stacks, so the advice is not one-size-fits-all:

• A 20 to 50 engineer team leaving a PaaS: AWS Pricing Calculator (or the Azure/Google equivalent) to model, native Cost Explorer with the Cost and Usage Report to allocate, Kubecost or OpenCost if you land on Kubernetes, and Qovery to operate the platform. You do not need Cloudamize or Flexera.
• A 200+ engineer VMware estate: Cloudamize or Flexera One for discovery and license optimization, AWS Migration Evaluator or Azure Migrate for the business case, CloudZero or Tanzu CloudHealth or nOps for post-migration allocation, Kubecost for Kubernetes detail, and Qovery to run the application platform.

How much cheaper is AWS, GCP, Azure, or Scaleway than a managed platform for the same workload?

On raw compute the delta is large and verifiable from published price lists. Once you add platform engineering time, the break-even depends almost entirely on how many environments and engineers you have, so we will give you a worked example instead of a percentage claim.

The workload: one production app targeting about 2 vCPU and 8 GB of RAM, one staging environment, and one small managed Postgres. On a managed platform we price it on Heroku (list prices verified) as the anchor; Render, Fly.io, Vercel, and Upsun land in a similar band. All figures are list price, on-demand, US regions, checked August 2026, and prices change, so follow each link before you quote it.

Infrastructure only:

On infrastructure alone the cloud wins from day one, roughly two to three times cheaper at this sizing, and the cloud VMs give you far more RAM headroom than the managed dynos they replace. Now the honest table, adding one platform engineer amortized across the estate:

Fully loaded (US platform engineer, ~$15,000/month loaded):

That spread is the whole argument. The cloud wins on TCO only once the platform work is amortized across enough services and environments, or handed to a platform that operates them for you. This is also why "we cut our bill 80%" case studies do not transfer: different workload shape, different utilization, different headcount, and usually no accounting for the human bucket. Non-hyperscaler providers like Scaleway often publish lower list prices with fewer managed services, so the delta is real and the trade-off is real.

Where do the cloud savings actually come from, and where do they disappear?

Savings come from four levers: right-sizing to real utilization, commitment discounts, autoscaling with Spot and ARM, and shutting down idle non-production. They disappear into two sinks: platform engineering headcount and environments nobody turns off.

Right-sizing closes the gap between a fixed PaaS tier and a real utilization curve. When clusters run at about 10% CPU and 23% memory utilization (Cast AI, 2025), the opportunity is most of the bill, not a sliver of it.

Commitment discounts are large but conditional on owning the account: up to 72% on AWS Savings Plans (AWS), up to 72% on Azure reservations (Microsoft), and resource-specific committed use discounts on Google Cloud (Google Cloud).

Second-wave levers: Spot and preemptible capacity, up to 90% off on AWS (AWS), up to 91% on Google Cloud (Google Cloud), and up to 90% on Azure (Microsoft); ARM instance families like AWS Graviton, which AWS lists at up to 40% better price-performance and up to 20% lower cost than comparable x86 (AWS); and cluster and pod autoscaling.

The idle-environment tax, in one line: a week has 168 hours, a working week is roughly 50, so an always-on non-production environment pays for about 70% of hours nobody uses.

The re-insourced sink is everything the managed-platform invoice bundled and hid: cluster upgrades, CVE patching, IAM, secrets, observability plumbing, and on-call. That is bucket 2, and it does not appear on any pricing calculator. Two numbers show how easily the savings evaporate: organizations went over their cloud budgets by an average of 17% last year (Flexera, 2025), and 29% of cloud spend is wasted (Flexera, 2026).

How does Qovery fit into a cloud migration cost analysis?

Qovery is not a cost-modeling tool and will not build your business case. It is the operating layer that makes modeled savings real, by keeping the cloud account and its discounts in your name and by shutting down what nobody is using.

Here is how that maps to the four buckets:

• BYOC keeps the bill yours. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing self-managed Kubernetes cluster on any provider or distribution. The invoice, the Savings Plans, and the committed use discounts stay in your name, which is the only way bucket 1's discounts exist at all.
• Auto-stop attacks bucket 3. Environment auto-stop for non-production hits the single largest recurring post-migration waste line, the 70% of hours nobody uses.
• Preview environments replace the always-on staging box. Ephemeral environments per pull request exist only for the life of the PR, instead of a permanent staging environment running 168 hours a week.
• Managed cluster upgrades and per-environment RBAC shrink bucket 2. The upgrade, patching, and access-control work that otherwise becomes a platform engineering headcount is handled for you.
• git-push deployments with databases on managed cloud services give you the managed-platform developer experience without the managed-platform margin.

The honest division of labor: use AWS Migration Evaluator or the provider calculators to build the business case, CloudZero, nOps, or Kubecost to allocate spend after cutover, and Qovery to run the platform so you do not have to staff it.

What Qovery does not do: no VM discovery, no software license optimization, no per-customer unit-economics reporting, and no migration business case. If you need those, the tools above are the right answer, and we will happily point you to them.

What does a step-by-step cloud migration cost analysis look like?

Run this seven-step method in a week. It starts with real invoices and ends with guardrails set before cutover, not after.

1. Export 12 months of invoices and split every line into three groups: compute, add-ons and data services, and support or plan fees. You cannot model what you have not itemized.
2. Inventory every environment (production, staging, preview, dev) and record the hours per week each is genuinely needed. This is where the idle-hours tax becomes a number.
3. Map each service to a cloud equivalent and price all three target architectures in the provider calculator: VMs, managed containers, and Kubernetes. Do not skip straight to Kubernetes if a smaller shape wins.
4. Add the human line. Platform engineering FTEs at a sourced, fully loaded salary (around $15,000 a month loaded in the US, around EUR 8,300 in Europe), or an internal developer platform subscription if you hand that work off.
5. Apply commitment discounts only to steady-state production. Savings Plans, CUDs, and reservations fit predictable load, never bursty or ephemeral non-production.
6. Model the migration project itself: dual-running months, cutover egress, engineer time, and a rollback budget. AWS gives you 100 GB a month of internet egress free, then about $0.09/GB for the first 10 TB (AWS, checked August 2026); Google Cloud charges about $0.12/GB for the first TB (Google Cloud). If you are leaving AWS entirely, it waives data-transfer-out charges on request, with a 90-day window as of September 2025 (AWS).
7. Set guardrails before cutover: a tag policy, budgets and alerts, an auto-stop policy for non-production, and one named owner for the cost dashboard. Guardrails added after the first surprise invoice are cleanup, not control.

Close on break-even, not on a made-up percentage: divide the amortized project cost by the monthly saving and you get the number of months before the move pays for itself. If that number is longer than 24 months at your current headcount and environment count, the honest answer might be to fix utilization first and migrate second.

Frequently asked questions

What tools can help us analyze cloud migration costs before we leave our managed platform?

Start with the free first-party tools: AWS Migration Evaluator plus the AWS Pricing Calculator for an AWS target, Azure Migrate for Azure, and Google Cloud Migration Center for GCP. For large VMware or license-heavy estates, add Cloudamize or Flexera One, which do agentless discovery and right-sizing at a scale the free tools do not. None of them were built for a PaaS source, so if you are leaving Heroku, Render, or similar, you model from plan tiers and utilization by hand rather than scanning VMs.

Is AWS Migration Evaluator free, and does it work if we are migrating from a PaaS instead of VMs?

Yes, AWS Migration Evaluator is offered at no cost, and it produces a directional Quick Insights report or a fuller business case with inventory-based right-sizing (AWS). It is built to discover and right-size existing servers, so it fits a VM or on-prem estate. If your source is a managed platform with no VMs to scan, use the AWS Pricing Calculator instead and model the target sizing yourself.

How much cheaper is AWS, GCP, Azure, or Scaleway than Heroku, Render, Vercel, or Fly.io for the same workload?

On raw infrastructure, roughly two to three times cheaper at small-production sizing, and often more once you use commitment or Spot discounts. In our August 2026 worked example, a production app, a staging copy, and a small Postgres cost about $350 a month on Heroku versus about $123 to $190 on the hyperscalers. That gap shrinks or reverses on total cost of ownership once you add the platform engineering time the managed platform was bundling, so the answer depends on how many environments and engineers you amortize that work across.

What is the difference between a migration cost assessment tool and a cloud cost management tool like CloudZero or Kubecost?

An assessment tool (AWS Migration Evaluator, Azure Migrate, Cloudamize) models cost before you move, by discovering your current estate and forecasting a cloud equivalent. A cost management tool (CloudZero, nOps, Kubecost/OpenCost, or the native cost explorers) allocates and controls spend after you move, by tagging real usage to teams, environments, and services. You need both, because every pre-migration forecast goes stale within a month of cutover.

Do we have to hire a DevOps or platform engineer after moving off a managed platform?

You need to cover the work either way, because the managed platform was doing it inside its invoice: cluster upgrades, patching, IAM, secrets, and on-call. That is bucket 2 of the TCO formula, worth roughly $15,000 a month fully loaded per engineer in the US (Glassdoor). You can hire for it, amortize it across enough services that it shrinks per environment, or hand it to an internal developer platform so you do not staff it at all.

Can we keep AWS Savings Plans, Google Cloud committed use discounts, and Azure reservations if we run an internal developer platform like Qovery on our own account?

Yes. Because Qovery uses a bring-your-own-cloud model, it deploys into your own AWS, GCP, Azure, or Scaleway account, so the bill and every commitment discount stay in your name. That is the point: commitment discounts only exist if the account is yours, which is never true on a managed platform. The platform layer sits on top of your account and does not take ownership of the billing relationship or the discounts.

Ready to make the savings you modeled actually land? Try Qovery free and deploy into your own cloud in under 10 minutes.