Cloud Migration Cost Analysis: The Tools, the Formula, and the Hidden Costs Nobody Models

Key Points:

• No single tool produces a complete cloud migration cost analysis. You assemble it from three layers: a discovery tool to size the target (AWS Migration Evaluator, Cloudamize, Flexera One, Azure Migrate, Google Cloud Migration Center), a cost-modeling tool to project the run-rate (the public pricing calculators, the Migration Evaluator business case), and a FinOps platform to track actuals after cutover (CloudZero, CloudHealth, Apptio Cloudability, Kubecost/OpenCost).
• Every one of those tools models infrastructure cost only. None models the two line items that decide the outcome: the one-time engineering effort to rebuild deployment, networking, IAM, observability and CI/CD, and the ongoing platform engineering headcount to run day-2 operations. In year one, the people terms are usually larger than the compute term.
• Use one formula: 36-month TCO = (target infra run-rate x 36) + one-time migration effort in engineer-months + (fully loaded platform FTEs x 36) + dual-running overlap + a 15-30% contingency, minus commitment discounts and non-production auto-stop savings.
• The hidden Kubernetes costs are predictable: control plane fees per cluster, node allocatable overhead and max-pods limits, per-service load balancers, NAT gateway data processing, cross-AZ traffic, IAM rework, log and metrics re-plumbing, a CI/CD rewrite, and a recurring version upgrade treadmill with paid extended support if you fall behind.
• Model three scenarios over 36 months (stay put, DIY migration, migration with an internal developer platform) and show the payback month for each. Qovery changes the model rather than measuring it: it deploys and operates your apps inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes account, which collapses the migration-effort and day-2 headcount lines. It is not a FinOps analytics tool and does not replace one.

---

If your finance team wants a cloud migration cost analysis before you move off a managed platform, here is the honest version up front: no single tool gives you the whole number. You assemble it from three layers of tooling, and then you add the two line items that none of those tools measure - the one-time engineering effort and the ongoing people cost.

I have watched a lot of teams move off Heroku, Render, Fly.io, Elastic Beanstalk, ECS and App Engine onto their own cloud accounts. The migrations that pay back are the ones where finance saw the people cost from day one. The ones that stall are the ones that modeled compute and nothing else.

This applies whether you land on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster. I will use AWS as the worked example because it is the most common destination and the best documented, but the structure of the analysis does not change with the logo.

All AWS prices below are for the US East (N. Virginia) us-east-1 region and were checked on September 11, 2026. Cloud prices move, so re-verify against the linked pages before you put a number in a board deck.

What should a cloud migration cost analysis actually contain?

A finance-grade cloud migration cost analysis has five components: a 12-month current-state baseline, a right-sized target-state run-rate, one-time migration cost in engineer-months, ongoing operational headcount, and a 15-30% contingency. Vendor tools reliably produce only the second one, which is why so many business cases miss.

Here is what each component holds:

• Current-state baseline: 12 months of actual invoices from the managed platform, broken down per app and per environment, including the add-ons that quietly add up - Postgres, Redis, log drains, TLS, WAF, and support plans.
• Target-state run-rate: right-sized compute (size off p95, not peak), storage, egress, load balancers, NAT, managed databases, backups, and support tier.
• One-time migration cost: discovery, refactoring, data migration, the dual-running overlap, cutover rehearsal, and a rollback plan.
• Ongoing operational cost: platform engineering FTEs fully loaded (salary x roughly 1.25 to 1.4 for taxes, benefits and equipment), on-call compensation, training, and tooling licenses.
• Risk buffer: a 15-30% contingency is standard for infrastructure programs. State it plainly and let finance argue the number down.

The deliverable finance actually wants is a 36-month TCO table with a payback month and an NPV, plus a one-page assumptions sheet. A screenshot of a pricing calculator is not a business case.

Keep the point destination-neutral from the start: the same five components apply whether the target is AWS, GCP, Azure, Scaleway, or a cluster you already run.

Which tools can run a cloud migration cost analysis, and what does each one miss?

Split the landscape into three jobs (assessment and discovery, cost modeling and business case, post-migration FinOps tracking), because no vendor does all three well and buying the wrong layer is the most common and most expensive mistake. Start with a free assessment tool for the baseline, use a pricing calculator for the target model, and only buy a FinOps platform once you have workloads running.

• Assessment and discovery: AWS Migration Evaluator (formerly TSO Logic), AWS Application Discovery Service, Azure Migrate, Google Cloud Migration Center, Cloudamize, Flexera One (including RISC Networks), and Corent SurPaaS for containerization fitness.
• Cost modeling and business case: the AWS, Azure and Google Cloud pricing calculators for a multi-cloud comparison, plus the Migration Evaluator business case report.
• Post-migration FinOps: CloudZero for unit cost (cost per customer, cost per feature), VMware Tanzu CloudHealth, Apptio Cloudability, native AWS Cost Explorer plus the Cost and Usage Report, and Kubecost/OpenCost for per-namespace and per-pod Kubernetes allocation.

AWS Migration Evaluator is offered at no cost to AWS customers, which makes it the fastest credible starting point for a baseline. Its business case report includes an analysis-and-insights section, a financial summary with several "what-if" purchasing scenarios, right-sizing recommendations, and a storage assessment. That is genuinely useful, and I recommend it even to teams that will never buy Qovery.

What none of these tools see is the part that decides the outcome: application refactoring effort, deployment tooling rewrite, IAM redesign, and day-2 operational headcount. Those are the three costs that determine whether the migration pays back, and they live in a spreadsheet you build by hand.

A quick reality check on tooling weight: under roughly 30 services with one environment per app, a well-built spreadsheet plus the public pricing calculators beats a six-week paid assessment engagement. Buy the heavy assessment when the estate is large or the dependencies are genuinely unknown.

One shared vocabulary helps finance and engineering talk to each other: the FinOps Foundation framework (inform, optimize, operate). It is worth adopting the terms so both sides argue about the same numbers.

CloudZero and Cloudability are genuinely strong at unit economics. Kubecost and OpenCost are the right answer for per-namespace Kubernetes allocation. Qovery is one row among many, and it sits in the execution-and-day-2 column, not at the top of every column.

What hidden costs do migration calculators miss when the destination is Kubernetes?

The costs that blow up Kubernetes migration budgets are not compute. They are seven re-plumbing projects plus a permanent day-2 operating model, and no calculator line-items any of them. ECS to EKS is the richest worked example, but the same list applies to GKE, AKS, Scaleway Kapsule, or a cluster you manage yourself.

• Control plane and node overhead. EKS charges $0.10 per cluster per hour for the standard control plane. That is the small part. The bigger surprise is allocatable capacity: kube-reserved, system daemonsets and scheduling headroom mean the pods you can actually run sit well below instance capacity, and max-pods limits under the VPC CNI can force larger nodes than raw compute demand suggests. The default formula is (ENIs x (IPs per ENI - 1)) + 2, published per instance type in the eni-max-pods.txt file in the EKS AMI repo.
• Networking. Each Application Load Balancer is $0.0225 per hour plus $0.008 per LCU-hour, and per-service ingress adds up fast. A NAT gateway is $0.045 per hour plus $0.045 per GB processed, and cross-AZ traffic is $0.01 per GB in each direction, so a chatty service mesh spread across three AZs pays twice on every hop.
• IAM rework. ECS task roles do not map one-to-one to IRSA or EKS Pod Identity. Every service needs its trust policy rebuilt, tested, and least-privileged again.
• Observability re-plumbing. The awslogs driver becomes Fluent Bit or an OpenTelemetry collector. Metrics scraping, tracing, dashboards, and every alert rule get rewritten, and you pay the ingestion bill for the volume Kubernetes generates.
• CI/CD rewrite. Task definitions and service updates become manifests, Helm charts, a GitOps controller, image promotion policies, and per-environment secrets.
• Day-2 headcount. Someone owns cluster upgrades, CVE patching, node group rotation, autoscaler tuning, and the pager. This is the single largest recurring hidden cost, and it is a salary, not a line on an invoice.
• The upgrade treadmill. Kubernetes ships a new minor version roughly every four months. On EKS a version gets 14 months of standard support, then 12 months of extended support at a higher rate. Fall behind and that control plane jumps from $0.10 to $0.60 per cluster per hour, a 6x increase. Model it as recurring, not one-off.

The upgrade treadmill is not AWS-specific. GKE charges a flat $0.10 per cluster per hour management fee (with one zonal or Autopilot cluster free per billing account), AKS is free on its base tier and $0.10 per hour on Standard, rising to $0.60 per hour on Premium with long-term support, and Scaleway Kapsule offers a free managed control plane with a paid dedicated tier. Every one of them still needs the same seven re-plumbing projects and the same day-2 owner.

Two more that finance never sees coming:

• Dual-running and velocity loss. Expect a period paying both platforms while feature throughput drops. Quantify it in engineer-weeks, because it is real money.
• Leaving a managed PaaS adds its own list. Moving off Heroku, Render or Fly.io means managed Postgres backups and point-in-time recovery, Redis, TLS renewal, WAF, secrets management, and buildpack behavior all become yours to own.

How do you turn this into a 36-month TCO finance will sign off on?

Model three scenarios over 36 months (stay put, DIY migration, migration with an internal developer platform) using one explicit formula, and make the people line as visible as the cloud line, because that is exactly where the three scenarios diverge. Show the payback month, not just the annual totals.

Here is the formula, stated once so it can be lifted straight into a spreadsheet:

36-month TCO = (monthly target infra x 36) + (one-time engineer-months x fully loaded monthly cost) + (platform FTEs x fully loaded monthly cost x 36) + (dual-run months x old platform bill) + tooling subscriptions + contingency, minus commitment discounts and non-production auto-stop savings.

The three scenarios:

• Scenario A, stay on the managed platform: current bill plus its growth curve, plus the ceiling you will eventually hit on scale, compliance, data residency, or per-dyno and per-instance pricing.
• Scenario B, DIY migration to Kubernetes on AWS, GCP, Azure, Scaleway or your own cluster: infra run-rate plus one-time effort plus one to two fully loaded platform engineers, forever.
• Scenario C, migration with an internal developer platform: infra run-rate plus a platform subscription plus a fraction of the one-time effort, and no dedicated cluster-ops hire.

The headcount line is where the money is. A DevOps engineer in the US averages around $151,000 in total compensation on levels.fyi, and platform engineer medians run higher still; European totals are lower but climbing. Load that by 1.25 to 1.4 and one platform FTE is $190,000 to $260,000 a year, or $570,000 to $780,000 across 36 months. That is almost always larger than the compute delta in year one.

Once you are in your own account, savings levers open up that a managed platform never gave you: Savings Plans and Reserved Instances cut up to 72% off On-Demand, Spot runs non-production at up to 90% off, and the commitments stay in your name. Add environment auto-stop for dev and preview environments and right-sizing off p95, and the run-rate line drops before you touch anything else.

The two modeling errors I see most: sizing off peak instead of p95, and omitting data egress plus cross-AZ traffic entirely. Both make the target look cheaper than it is.

Finally, run a sensitivity analysis at plus or minus 20% on the headcount assumption, because that is the first input finance will challenge, and you want the answer ready.

The dollar values above are deliberately left as formulas. Fill them from your own invoices and salary bands, and label any example figure "illustrative" so nobody mistakes it for a quote. The shape is the point: the scenarios diverge on the people rows, not the compute row.

Where does Qovery fit next to CloudZero, CloudHealth and AWS Migration Evaluator?

Those tools measure and forecast the cost. Qovery changes it, by executing the migration and owning day-2 operations inside your own cloud account. They are complementary: run Migration Evaluator or Azure Migrate for the baseline, keep Cost Explorer, CloudZero or Kubecost for tracking, and use Qovery so the headcount line in your model does not double.

We are an internal developer platform that deploys and operates your applications inside your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster. It is bring-your-own-cloud, so the cloud bill and any Savings Plans or committed use discounts stay in your name.

What Qovery removes from the one-time migration line: cluster provisioning, ingress and networking setup, git-push deployments, secrets, per-environment RBAC, and databases backed by managed cloud services. What it removes from the recurring day-2 line: managed cluster upgrades, autoscaling, preview and ephemeral environments per pull request, and environment auto-stop for non-production.

Let me be clear about what Qovery is not. It is not a FinOps analytics product, it does not produce a Migration Evaluator business case, and it does not generate per-customer unit-cost reports. Pair it with the tools that do.

The stack I recommend, which you can copy straight into a plan:

• An assessment tool (Migration Evaluator, Azure Migrate, Migration Center) for the baseline.
• A public pricing calculator for the target model.
• Qovery for execution and day-2 operations.
• Cost Explorer and the CUR, or CloudZero, plus Kubecost or OpenCost for ongoing tracking.

On the results our customers have published: RentalReady moved from AWS ECS to Amazon EKS with Qovery in a six-week migration and multiplied deployment capacity 17x, with CTO François Lavie saying "the migration to Qovery was very fast, and the ROI for our teams was immediate." Alan moved off Elastic Beanstalk and cut deployment time from 55 minutes to 8 minutes across more than 100 services; their infrastructure lead put the day-2 point better than I can: "we had one full-time person dedicated to managing Beanstalk, which has completely disappeared." And SoFive reports it migrated to EKS with Qovery in 10 days. Those are the published claims, and I will not invent numbers around them.

Onboarding is honest work, not a magic trick: you connect your cloud account, Qovery provisions the cluster and networking, and your applications deploy from git. It is not "one command," but it is a lot less than rebuilding all of that by hand.

What does a realistic migration timeline and cost curve look like?

A phased migration keeps the dual-running window short, and the dual-running window is the single biggest lever on one-time cost. Every extra week in phase 2 is duplicated spend with zero savings realized.

• Phase 0, baseline and assessment (1-3 weeks): export 12 months of invoices, run Migration Evaluator, Azure Migrate or Migration Center, and inventory services, dependencies and stateful components.
• Phase 1, landing zone and first workload (2-4 weeks): account structure, VPC, cluster, and one non-critical service running end to end with logs, metrics and a rollback path.
• Phase 2, bulk migration: move services in dependency order and dual-run only the stateful components. This is weeks when deployment is automated and months when it is not.
• Phase 3, cutover and decommission: savings only start here, so treat decommission dates as tracked deliverables with named owners.
• Phase 4, optimize: right-size off p95, buy Savings Plans or committed use discounts once usage is stable, enable auto-stop for non-production, and add per-namespace visibility with Kubecost or OpenCost.

The trap is always the same: teams stall in phase 2 because the deployment tooling rewrite was underestimated, and the dual-running overlap eats the entire projected saving. Watch one metric to catch it early - the percentage of workloads cut over versus the percentage of old-platform spend retired. They should move together. When they drift apart, you are paying for two platforms and getting the savings of neither.

This is also where the wider numbers back up the caution. Flexera's 2025 State of the Cloud Report found 27% of cloud spend is wasted, 84% of organizations name managing cloud spend as their top challenge, and budgets are running 17% over. And 82% of organizations now run Kubernetes in production per the CNCF's annual survey, where the top barriers are cultural factors, a training gap, and operational complexity, not the technology itself. The migration is rarely the hard part. Running it on day 300 is.

What tools can run a cloud migration cost analysis including projected savings and hidden costs?

No single tool does all of it. Use a discovery tool (AWS Migration Evaluator, Azure Migrate, Google Cloud Migration Center, Cloudamize, Flexera One) to size the target, a pricing calculator or the Migration Evaluator business case to model the run-rate, and a FinOps platform (CloudZero, CloudHealth, Apptio Cloudability, Kubecost/OpenCost) to track actuals after cutover. You add the refactoring effort and day-2 headcount by hand, because none of those tools model them.

Is AWS Migration Evaluator free, and what does the business case deliverable include?

Yes, Migration Evaluator is offered at no cost to AWS customers. The business case report includes an analysis-and-insights section, a financial summary with several "what-if" purchasing scenarios, right-sizing recommendations against your current footprint, and a storage assessment, plus a Quick Insights one-page summary of projected savings. It is the fastest credible way to produce a defensible baseline for an AWS target.

What is the difference between CloudZero, CloudHealth, Apptio Cloudability and AWS Cost Explorer?

Cost Explorer and the Cost and Usage Report are AWS-native and free, and they answer "what did we spend." CloudHealth and Apptio Cloudability are multi-cloud FinOps platforms for governance, showback and reporting across accounts. CloudZero focuses on unit economics - cost per customer, per feature, per team - which is the question a growing SaaS business actually needs answered. For per-namespace and per-pod Kubernetes allocation specifically, Kubecost or OpenCost is the right tool.

What are the hidden costs of moving from ECS to EKS?

The compute is rarely the problem. The hidden costs are the $0.10 per cluster-hour control plane plus node allocatable overhead and max-pods limits, per-service load balancers and NAT gateway data processing at $0.045 per GB, cross-AZ traffic at $0.01 per GB each way, rebuilding IAM from task roles to IRSA, re-plumbing logs and metrics, rewriting CI/CD into manifests and Helm, and the recurring version upgrade treadmill. The largest one is day-2 headcount to own all of it.

How much does a platform engineer add to the true cost of a Kubernetes migration?

A lot, and it is usually the biggest line in year one. A DevOps engineer in the US averages around $151,000 in total compensation, and platform engineer medians run higher; loaded for taxes, benefits and equipment (roughly 1.25 to 1.4x), one FTE is $190,000 to $260,000 a year. Across a 36-month TCO that is $570,000 to $780,000 for a single hire, which is why the DIY and IDP scenarios diverge mostly on this row.

Can Qovery reduce cloud migration costs, and does it replace a FinOps tool?

Qovery reduces the two costs calculators miss - the one-time deployment rebuild and the recurring day-2 operations headcount - by deploying and operating your apps inside your own AWS, GCP, Azure, Scaleway or existing Kubernetes account. It does not replace a FinOps tool: it produces no business case and no per-customer unit-cost report, so pair it with Migration Evaluator for the baseline and CloudZero, Cost Explorer or Kubecost for tracking. The tools tell you what it will cost; Qovery changes what it costs.