Six signs your cloud migration is going to run over budget

Almost every cloud migration is pitched on a cost-savings story: move off aging on-prem hardware, pay only for what you use, let the provider handle scaling. Then six months in, the monthly bill is double the estimate and nobody can point to the exact moment it went wrong. It rarely goes wrong all at once. It goes wrong in six specific, predictable ways — and every one of them is visible before a single workload moves, if you know where to look.

1. The estimate was built on list prices, not real usage patterns

A cloud provider’s pricing calculator will happily give you a number. That number assumes steady, predictable usage — which almost nothing in a real business actually has. Batch jobs that spike CPU for two hours a night, a reporting dashboard that gets hammered every Monday morning, a customer-facing API with traffic that’s ten times higher in December than in February: none of this shows up in a calculator built around monthly averages.

The fix isn’t a better calculator. It’s pulling actual utilization data from the systems you’re migrating — real CPU, memory, storage I/O, and network transfer over at least a full business cycle — before anyone commits to a number leadership will hold you to.

2. Nobody priced the data egress

Compute and storage get all the attention in a migration estimate because they’re the line items every pricing page leads with. Data transfer out of the cloud — egress — is the one that quietly wrecks budgets, because it’s usage-based, it’s easy to underestimate, and it scales with exactly the kind of growth a migration is meant to enable. A reporting pipeline that pulls large datasets to an on-prem BI tool, a multi-region architecture that replicates data between regions, a partner integration that exports data nightly: each of these can add up to a meaningful fraction of the total bill, and almost none of them show up in an initial sizing exercise.

Before migrating, map every place data will need to leave the cloud environment — not just where it enters — and get real per-gigabyte pricing for each destination.

3. “Lift and shift” was scoped as a one-time cost, not an ongoing one

Lift-and-shift is often the right first move: get workloads off failing hardware, buy time to redesign properly. The mistake is treating it as a destination rather than a waypoint. A virtual machine that’s an exact copy of an on-prem server, running in the cloud with the same fixed sizing, captures none of the cost advantages of cloud infrastructure — elastic scaling, spot capacity, serverless compute for spiky workloads — while paying cloud prices for the privilege.

If lift-and-shift is the plan, the budget needs a second phase built in: a defined window, typically three to nine months, to right-size and re-architect what was moved. Without that second phase funded and scheduled from the start, “temporary” lift-and-shift becomes the permanent, most expensive way to run every workload.

4. Nobody owns cost after go-live

On-prem infrastructure has a natural cost ceiling: the hardware you bought is the hardware you have. Cloud infrastructure has no such ceiling — a misconfigured auto-scaling group, an orphaned test environment left running, a database tier nobody downsized after a project ended, all silently accumulate cost with no natural signal that anything is wrong. The bill just goes up, a little every month, until someone finally asks why.

This is a governance gap, not a technical one. Someone — a person, not a vague “the team” — needs to own a monthly cost review, with alerts configured for anomalies and a clear process for decommissioning what’s no longer needed. Migrations that build this in from day one see costs plateau after the initial move. Migrations that don’t see them climb quietly for years.

5. The migration plan didn’t account for running two environments at once

For any migration beyond a single small application, there’s a period — often longer than anyone wants to admit — where the old environment and the new one both need to run. Data has to sync, cutover has to be tested, rollback has to stay possible if something breaks. That’s double infrastructure cost for the overlap period, and it’s routinely left out of the budget entirely because the spreadsheet only has one column for “infrastructure cost.”

Build the overlap period into the budget explicitly, with a hard, calendared end date for decommissioning the old environment — and hold that date. Overlap periods that don’t have a forcing function to end them have a tendency to become permanent.

6. Reserved capacity and commitment discounts weren’t part of the plan

On-demand pricing is the most expensive way to run anything in the cloud, and it’s also the default — which means the first few months after a migration, before anyone has stable usage data to commit against, are often run entirely at on-demand rates. That’s reasonable for the initial period. It becomes expensive when nobody circles back once usage stabilizes to lock in reserved instances, savings plans, or committed-use discounts, which can meaningfully reduce the bill for predictable, steady-state workloads.

The practical fix: schedule a cost-optimization review 60–90 days after go-live specifically to identify workloads with stable, predictable usage and move them onto commitment-based pricing. This single step is often the highest-leverage cost action available post-migration, and it’s the one most commonly skipped because nobody put it on a calendar.

What actually prevents this

None of these six problems are technical mysteries — they’re scoping and governance gaps, which means they’re preventable with the right process, not a bigger contingency budget. A migration plan that includes real usage-based sizing, an explicit egress cost map, a funded second phase for right-sizing, a named cost owner, a calendared cutover end date, and a scheduled post-migration optimization review addresses all six before they become a line item nobody can explain.

If your migration plan doesn’t have answers to these six questions yet, that’s the conversation worth having before the first workload moves — not after the first invoice arrives.