Why Cloud Migrations Overrun, and What to Fix First

The overrun is mostly newly visible cost

The situation is specific enough that most people reading this are in it. A migration was approved on a business case that showed savings. Two or three waves have landed. The monthly invoice is now at or above what the environment it replaced was supposed to cost, the old estate still runs because decommissioning slipped, and nobody can say which line items are responsible. That last part — "where is the money going?" being genuinely hard to answer — is the first finding.

This is not a rare failure. In GAO-26-107530 (June 23, 2026), the Government Accountability Office surveyed 24 federal agencies; the most commonly reported challenge, cited by 17 of them, was that control of cloud costs required changes in IT management approaches. Seven years earlier, GAO-19-58 found that 13 of 16 agencies had saved $291 million from cloud services to date, while those same agencies "identified issues in tracking and reporting cloud spending and savings data, including not having consistent processes in place to do so." Both things are in the record: the savings are real, and the measurement is weak.

The mechanism matters, because it changes what you do about it. An on-premises estate is a capital asset with a largely invisible run cost: floor space, power, cooling, network fabric, hypervisor licenses, the storage array bought three years ago, staff time — all spent, almost none of it attributed to a specific application. Cloud is metered per hour, per gigabyte, per request, per gateway. Migration converts an unattributed cost into an itemized one, and every architectural inefficiency that used to be free now arrives with a price and a line number.

So a real overrun is two things added together: genuinely new spend, and previously invisible spend that has become visible. Programs that never separate the two spend their first year arguing. And if the business case had no honest all-in baseline of the current estate, its savings number is not wrong so much as unfalsifiable — you cannot beat a baseline you never measured.

Lift and shift moves the bill, not the architecture

AWS Prescriptive Guidance names seven migration strategies, the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Most programs default to rehost — lift and shift — because it is the fastest path to a data center exit date. That is often the right call; the trap is treating it as the end state.

AWS is candid about the trade: rehost "helps you to scale your applications without implementing any cloud optimizations that could save you time or money." What gets carried across is the sizing. Your VM shapes were a purchasing decision made once, against peak load plus headroom plus a five-year hardware horizon, on capacity already bought. That headroom was free. Metered, it is billed hourly, indefinitely, until somebody deliberately removes it.

The highest-return strategy is also the most-skipped, and it is retire. AWS gives operational definitions worth borrowing: zombie applications average below 5 percent CPU and memory, idle applications average 5 to 20 percent over 90 days, and another named signal is no inbound connection for the last 90 days. A workload retired before the migration costs nothing to move and nothing to run.

One more piece of AWS's guidance gets routinely inverted: "Refactor is not recommended for large migrations… we recommend rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete." So the honest sequence is retire, rehost or relocate, optimize, then modernize what deserves it. The failure is rarely in choosing that sequence — it is in funding only the first two steps. When the schedule tightens, "optimize" is the line that gets cut, and the program lands its whole portfolio at on-premises sizing on cloud pricing. That overrun was created in the plan, not the invoice.

Egress, and the network charges nobody modelled

Compute is the number people estimate. Network is the one that surprises them: on-premises it was a fixed asset, in cloud it is a meter. Start with the free allowance, which creates a false sense of scale. AWS provides 100 GB per month of data transfer out to the internet at no charge, aggregated across services and regions — but the announcement is explicit that this does not apply to the AWS GovCloud or AWS China Regions. For a federal program landing in GovCloud, the allowance most cost models quietly assume is not yours. Beyond it, AWS's published rate out of its US commercial regions starts at $0.09 per GB and is tiered by volume; check the on-demand pricing page for your region, not a number in a slide deck.

The larger surprise is usually internal, because managed network services meter traffic that never leaves the provider. A NAT gateway is the canonical case: Amazon VPC pricing states that data processing charges apply "for each gigabyte processed through the NAT gateway regardless of the traffic's source or destination," on top of a charge for every hour the gateway is provisioned and any standard data transfer charges. Its worked example uses $0.045 per gateway-hour and $0.045 per GB processed; rates vary by region. Picture a container platform where every node pulls images, ships logs, and calls a managed database through that gateway: none of it touches the internet, all of it is metered, and teams find out in month four.

The lever is architectural, not contractual. AWS's Well-Architected guidance, COST08-BP03, covers services that reduce data transfer costs — private endpoints so provider traffic avoids the gateway, chatty components kept close together, edge caching for genuinely public traffic. These are design decisions: cheap before a wave lands, expensive to retrofit after, which is why egress belongs in the architecture review and not the FinOps backlog. On lock-in, note that AWS offers free data transfer out for customers moving off AWS, requested through Support and reviewed per account, with 90 days to complete the move.

Right-sizing needs data you are probably not collecting

Right-sizing is the standard answer to an inflated bill, and it fails often enough that teams stop believing in it. The reason is almost always the data underneath the recommendation, and two defaults matter. First, the observation window. AWS Compute Optimizer offers lookback periods of 14 days (the default), 32 days, or 93 days, with AWS noting the 93-day option requires additional payment. If your workload has a monthly close, a payroll cycle, or an annual enrollment window, a 14-day window will confidently recommend shrinking the instance that exists to carry exactly that peak — AWS says as much of the 32-day option, that it "can capture monthly workload patterns."

Second, and more damaging, memory. Per AWS's documentation on metrics analyzed, memory utilization is not collected by CloudWatch by default; to have it considered you must install the CloudWatch agent or configure external metrics ingestion from a supported observability product. Until then, recommendations are formed from CPU, disk, network, IO and throughput — the wrong axis entirely for a JVM service, an in-memory cache, or a database-adjacent application. What follows is predictable: the team accepts a downsizing recommendation, the application starts swapping or getting killed, they roll back, and right-sizing loses credibility for a year.

The fix is unglamorous and belongs before the migration: install the agent on the source estate, collect a full business cycle — usually a quarter, not a fortnight — then size the target from measured demand rather than the inherited VM shape. Treat it as a standing operation with an owner, not a one-time cleanup.

Licensing is where the business case quietly dies

This is the section that catches experienced teams, because it is not an engineering problem and engineers do not read contracts.

Microsoft's own licensing notice states that "beginning October 1, 2019, on-premises licenses purchased without Software Assurance and mobility rights cannot be deployed with dedicated hosted cloud services offered by" a named set of providers — Microsoft, Alibaba, Amazon (including VMware Cloud on AWS), and Google — referred to as Listed Providers. Microsoft's stated paths forward are buying the cloud service directly from a Listed Provider, including through providers that participate in the SPLA program; License Mobility through Software Assurance; or Azure Hybrid Benefit on Azure Dedicated Host. The implication holds whatever your estate looks like: the entitlement you own on-premises does not automatically follow the workload, and the answer differs product by product.

There is a second, quieter problem in the sizing itself. Commercial software is frequently licensed per core. On-premises a database might be licensed against a socket count on hardware you already own; in the cloud, the vCPU count of an instance chosen for its memory ratio can drive a materially different license position. You picked a shape for RAM and inherited a core count you owe money on — one of the strongest arguments for replatforming a licensed engine onto a managed or open-source alternative.

The recommendation is blunt. Before the wave plan is approved, someone in procurement or counsel reads the actual agreements for every commercial product and records whether Software Assurance is current, whether mobility rights exist, and what the metric is. That review takes longer than anyone budgets and it changes 7Rs decisions — doing it after wave three means re-deciding workloads you have already moved.

The savings levers have their own traps

Two levers get pulled early because they look free. Both have an ordering constraint.

Committed-use discounts. Reserved capacity and savings-plan style commitments trade flexibility for a lower rate over a fixed term. The trap is sequencing: teams commit on the post-migration footprint, right-size successfully, then find usage below a commitment they cannot unwind. Right-size first, commit second, and commit to the demonstrated floor rather than the forecast.

Storage tiering. Lifecycle policies that push objects into colder classes look like pure savings and are not. Per AWS's storage class documentation, S3 Standard-IA carries a 30-day minimum storage duration and S3 Glacier Instant Retrieval a 90-day minimum, with objects deleted, overwritten, or transitioned early incurring a pro-rated charge for the remaining days — and retrieval charges on top when you read the data back. Tier by access pattern and object lifespan, not age alone.

Underneath both is attribution, and none of it is answerable if resources are untagged — so tag policy has to be enforced at provisioning time through the landing zone's own guardrails, because retroactive tagging campaigns do not finish. For reporting across providers, the emerging common language is FOCUS, a FinOps Foundation specification under the Linux Foundation that "normalizes billing datasets across AI, cloud, SaaS, data center, and other technology vendors." A normalized schema turns "the bill went up" into "this capability, owned by this team, grew for this reason."

What to fix first

If a program can do only a few things before the next wave, this is the order — the first five are the assessment.

1. Baseline the current estate honestly — facilities, power, refresh amortization, licensing, labor. Without it there is no savings claim, only a hope.
2. Build the inventory and dependency graph. A per-workload decision is impossible without knowing what talks to what, and dependency surprises turn a two-week cutover into a quarter.
3. Retire before you migrate, using utilization thresholds and inbound-connection evidence. This is the only lever with no downside.
4. Instrument, then wait — memory metrics on, flow data per application boundary, one full business cycle.
5. Read the licenses — product by product, entitlement by entitlement, before the wave plan is signed.
6. Decide per workload with the cost written beside it. A 7Rs matrix without a cost consequence per row is a sorting exercise, not a decision.
7. Fund the optimize step inside the wave, so it cannot be the line that gets cut when the schedule tightens.
8. Make decommissioning a dated deliverable with an owner. Until the source system is off you pay for both, which is where most "the migration didn't save anything" stories end.

The one-sentence version: migrations overrun because the decision to move gets made before anything is measured, and measurement is the cheapest part of the program.

Sources: GAO-26-107530 — Cloud Computing: Federal Government Needs to Address Procurement Challenges (June 23, 2026); GAO-19-58 — Cloud Computing: Agencies Have Increased Usage and Realized Benefits, but Cost and Savings Data Need to Be Better Tracked (April 4, 2019); AWS Prescriptive Guidance — About the migration strategies (7 Rs); AWS — Free Tier data transfer expansion (100 GB, GovCloud and China Regions excluded); Amazon VPC pricing — NAT gateway rates and pricing example and Amazon VPC User Guide — pricing for NAT gateways; Amazon EC2 On-Demand pricing; AWS Well-Architected — COST08-BP03, implement services to reduce data transfer costs; AWS — Free data transfer out to internet when moving out of AWS; AWS Compute Optimizer — rightsizing recommendation preferences and metrics analyzed; Amazon S3 — understanding and managing storage classes; Microsoft — Updated licensing terms for dedicated hosted cloud services; FinOps Foundation — FOCUS specification. Pricing figures are AWS's published examples and change over time and by region; confirm current rates on the vendor pricing page before using them in a business case. Analysis and framing by Precision AI Academy.

Common questions

Why does a lift-and-shift migration usually cost more than expected? Because rehosting carries the old sizing decisions into a metered environment. AWS states that rehost "helps you to scale your applications without implementing any cloud optimizations that could save you time or money." On-premises servers were sized once, against peak load plus headroom plus a multi-year refresh horizon, on capacity that was already bought. In the cloud that same headroom is billed hourly, indefinitely, until someone deliberately right-sizes it.

What are the network charges people forget to model? Two categories. Internet egress, which AWS prices per gigabyte after a free monthly allowance that does not apply in GovCloud or China Regions. And in-cloud network services that meter traffic which never leaves the provider — a NAT gateway carries a per-hour charge plus a data processing charge for each gigabyte processed "regardless of the traffic's source or destination," with standard data transfer charges on top.

Why do right-sizing recommendations often make things worse? Because of the data underneath them. AWS Compute Optimizer defaults to a 14-day lookback window, which misses monthly and quarterly peaks, and memory utilization is not collected by CloudWatch by default — it requires the CloudWatch agent or an external metrics source. Without memory data and a full business cycle of history, recommendations are shaped by CPU, disk and network alone, which is the wrong axis for memory-bound workloads.

Does moving to the cloud automatically save money? Not automatically, and the federal record is mixed. GAO found in 2019 that 13 of 16 agencies had saved $291 million from cloud services while also reporting that they lacked consistent processes for tracking cloud spending and savings. In 2026, 17 of 24 agencies told GAO that controlling cloud costs required changes in their IT management approaches. Savings are achievable; they are the result of retirement, right-sizing, architecture and decommissioning, not of the move itself.

What should we fix before starting? Baseline what the current estate actually costs including facilities, refresh and labor; build an application inventory and dependency graph; retire zombie and idle workloads before migrating them; instrument memory and network egress for a full business cycle; and have procurement read the actual license terms for every commercial product in the portfolio. Those five steps are the assessment, and they cost far less than the overrun they prevent.