Why your cloud migration calculator is lying to you (and how to read it anyway)

Every hyperscaler ships a "TCO calculator". Punch in your VM count, click Calculate, and a green banner promises 40% savings versus your current cloud. Sales teams print these PDFs. CFOs sign migration plans on the back of them.

Most of those numbers are wrong. Not maliciously — just incomplete. After modelling thousands of workloads across AWS, GCP, Azure and OCI, we have learned that a migration estimate is only as good as the assumptions it refuses to hide. Here is the short version of the framework we now bake into Lumicost's Migration Analyzer.

What the vendor calculator gets wrong

1. It ignores the commitments you already paid for

If you bought a 3-year Reserved Instance, a Savings Plan or a Committed Use Discount, your "current" on-demand price is not what you actually pay. A calculator that compares your effective rate to the destination's on-demand rate will overstate savings. A calculator that ignores the remaining amortization of those commitments will tell you to walk away from money you have already spent.

A serious migration analysis must answer two questions side by side:

• What does this workload cost on the destination cloud at list price?
• What does it cost when you factor in your existing commitment coverage, including the months left on each commitment?

If the gap between those two numbers is bigger than the headline saving, you are not migrating — you are buying out a contract.

2. It assumes an exact shape match exists

m5.2xlarge is not the same thing as n2-standard-8. CPU generations differ. Memory ratios differ. Sustained throughput differs. When the destination cloud doesn't have a one-to-one match, the calculator picks the next size up — silently. You pay 20% more on day one and don't notice until the bill arrives.

The fix is to surface the shape match score (how close the destination shape is to the source) and to flag any case where the analyzer had to round up.

3. It treats egress as a footnote

This is where most migrations bleed. The first 90 days post-migration look great because the apps still talk to the old cloud's data, services and observability stack. Then somebody flips a switch, traffic flows the other way, and your egress bill explodes.

A workload that looks 35% cheaper on compute can become more expensive overall the moment you account for egress. Lumicost has a specific risk flag for this — EGRESS_FLIPS_SAVINGS — because it happens often enough to deserve its own name.

4. It hides the freshness of its pricing data

Cloud pricing changes. Spot pools shift. New instance families launch. Calculators that quote a flat number rarely tell you when their pricing snapshot was last refreshed. If the data is more than 30 days old, the analysis is a guess dressed up as a quote.

How we score a migration at Lumicost

We never give a single number. We give a confidence tier and a list of risk flags. Three tiers:

• HIGH — shape match ≥ 0.85, recent pricing data, no commitment conflicts, modest egress.
• MEDIUM — shape match between 0.6 and 0.85, or one risk flag is active.
• LOW — shape match below 0.6, or stale pricing, or egress flips the savings, or specialised hardware.

Eleven flags can fire on any given workload. Among the most common:

• CROSS_REGION_LATENCY — destination region is far from your data, expect P95 hits
• NO_EXACT_SHAPE_MATCH — closest shape is bigger; check the rounding cost
• EGRESS_HEAVY — workload moves more than 1 TB / month off the cloud
• EGRESS_FLIPS_SAVINGS — egress alone wipes out the compute saving
• COMMITMENT_AMORTIZATION_UNKNOWN — we don't have your commitments loaded yet
• COMMITMENT_EXPIRES_SOON — the source-cloud commitment expires within 90 days, recompute then
• PRICE_DATA_STALE — pricing snapshot is older than 30 days
• SPECIALISED_HARDWARE — GPU, FPGA, custom silicon, or licence-bound — the destination has fewer options
• STORAGE_TIER_UNPRICED — destination tier exists but we couldn't price it
• LARGE_MIGRATION_TRANSFER — moving the dataset itself will cost more than a year of compute savings
• EGRESS_VOLUME_ASSUMED — we estimated egress; load real flow logs for a tighter number

A workload with a HIGH tier and zero flags is a candidate. A workload with a LOW tier and three flags is a meeting, not a migration.

A short reading guide for the next calculator you see

When somebody hands you a migration estimate — vendor, consultant or open-source — ask the same five questions:

1. Were my existing commitments factored in, with their remaining months?
2. Was the destination shape an exact match, or was it rounded up?
3. What is the egress assumption, and is it from real flow logs or a guess?
4. How fresh is the pricing data?
5. What is the confidence tier, and which risk flags fired?

If the answer to any of those is "we don't model that", you have a marketing PDF, not a migration plan.

---

Where Lumicost fits

Lumicost's Migration Analyzer is opinionated about exactly this: confidence tier instead of a single number, eleven explicit risk flags, your existing RIs / SPs / CUDs factored into the math, four clouds priced (AWS, GCP, Azure, OCI), and a permanent honesty banner on the page so nobody mistakes the analysis for a final answer.

Treat the number as a starting point. Then go negotiate.