The common post migration cost surprises are data movement charges (egress between regions and availability zones, traffic out to the internet, and NAT gateway processing), oversized compute from lift and shift sizing that copied physical servers, snapshot and backup sprawl that nobody prunes, the premium of managed services chosen for convenience, and logging and observability volume that scales with traffic. None are exotic; they are the metered cost of habits that were free on owned hardware. They appear differently by cloud, NAT and cross zone transfer on AWS, Log Analytics ingestion on Azure, network service tiers on GCP, and comparatively cheaper egress on OCI, but the pattern is universal. Review the first full bill, act in the first 90 days, and the surprise becomes a one time correction rather than a permanent baseline.
Migration plans model compute and storage carefully and almost never model the metered behaviours that dominate the first real bill. Here are the lines that surprise teams, why they appear, and how each one is distinct per cloud.
Why does data movement cost so much now?
On a local network, moving data between servers was free, so architectures grew chatty without penalty. In the cloud every hop can meter. Traffic out to the internet bills as egress, traffic between availability zones bills as cross zone transfer, traffic between regions bills again, and a NAT gateway charges both an hourly rate and a per gigabyte processing fee for outbound traffic from private subnets. A workload that talks constantly across zones or routes everything through a single NAT can run a data movement bill larger than its compute. On AWS the NAT gateway and cross zone transfer lines are the classic offenders; on GCP the choice between premium and standard network tiers changes egress materially; on OCI egress is materially cheaper than the hyperscalers, which changes the math for data heavy workloads. The fix is architectural: keep chatty traffic in zone, place NAT deliberately, and use private connectivity for high volume paths.
Why is lift and shift compute oversized?
Physical servers were bought for peak load years out, so they ran with large headroom that cost nothing extra once purchased. Lift and shift copies that headroom into cloud instances that bill every hour for capacity the workload never uses. The result is an estate sized for hardware procurement habits, not for actual demand. Rightsizing against real utilization, and moving to cost efficient processor families and modern storage types where the software supports them, typically recovers a large block of compute that was never needed. This is usually the single biggest controllable line after migration.
What about snapshots, managed services, and logging?
Three quieter surprises round out the bill. Snapshot and backup sprawl accumulates because automated snapshots are easy to create and nobody owns deleting them, so storage grows indefinitely behind the scenes. Managed services chosen for convenience carry a premium over self managed equivalents that is worth paying when it saves real operational effort and worth questioning when it does not. And logging and observability ingestion scales with traffic, so a verbose configuration that was harmless on premises becomes a metered line that grows with success; on Azure, Log Analytics ingestion is the usual culprit and needs its own retention and sampling discipline. Each is small per item and large in aggregate.
| Surprise line | Why it appears | Distinct per cloud |
|---|---|---|
| Data egress and transfer | Local network moves were free | GCP network tiers; OCI cheaper egress |
| NAT processing | Outbound private traffic now meters | AWS NAT gateway hourly plus per GB |
| Oversized compute | Physical sizing copied across | Graviton, gp3, flexible shapes help |
| Snapshot sprawl | Easy to create, nobody prunes | All clouds, varies by storage class |
| Logging ingestion | Verbose config scales with traffic | Azure Log Analytics is the usual one |
Table: the recurring post migration surprises and how they differ across AWS, Azure, GCP, and OCI.
A worked example
A Fortune 500 manufacturer completed a lift and shift to AWS and saw the first full month land well above the migration model. The review found three causes. Cross zone and NAT processing charges were large because a chatty data pipeline spanned availability zones and routed through a single NAT. Compute was sized from the old physical servers and ran far below capacity. And automated snapshots had accumulated for months with no retention policy. Keeping the pipeline traffic in zone, rightsizing onto cost efficient instance families, and setting snapshot retention removed a substantial block of spend inside the first 90 days, with no change to the application. The estate settled into a baseline materially below the surprise bill. Figures are verified against billing data and anonymised.
Where this fits the wider decision
Catching surprises early depends on tracking the migration properly, covered in migration cost tracking and accountability, and it informs whether the move made sense at all, which is the subject of the migration decision framework. For workloads where the cloud math does not hold, see the hybrid estate cost model. The full cross cloud picture lives in the cross cloud cost optimization guide.
Frequently asked questions
Why does the cloud bill jump after a migration?
What is the most common post migration cost surprise?
How soon should you review costs after migrating?
Catch your surprises early with us
We run a cost assessment on your migrated estate across AWS, Azure, GCP, and OCI, find the metered surprises, and fix them in the first 90 days, with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.