Cloud migration budgets are almost always wrong. Not off by a rounding error — off by 40, 60, sometimes 90 percent. The usual culprit is not the compute bill everybody modeled in the original business case; it is the long tail of costs that appear only after the first workload actually moves. Over the past two years the TechGrid NexStream team worked alongside five organizations — a regional insurer, a SaaS startup scaling past Series B, a mid-market manufacturer, a university research group, and a logistics provider — and collected every invoice, every change order, and every line item that showed up in their cloud spend from kick-off to steady state. What follows is what the spreadsheets actually said, not what the pre-sales slide decks promised. Some of the numbers will surprise you. A few of them surprised us.
The baseline everyone models: compute, storage, network — and why it is still wrong ¶
Every migration starts with a sizing exercise. Engineers audit on-premises VMs, map CPU and RAM to cloud instance families, and produce a monthly compute estimate. In the five projects studied, this estimate was the most accurate single line item — and it was still wrong in four out of five cases. The insurer, for example, modeled 340 instances in AWS and landed at 412 within six months because application owners kept finding workloads that had been missed in the initial discovery scan. The startup underestimated storage by 60 percent because nobody counted log retention volumes. The lesson is not that sizing is useless; it is that discovery is almost always incomplete. One practical fix: run cloud-native discovery agents such as AWS Migration Evaluator or Azure Migrate for a minimum of 30 days before any estimates are written down. Two weeks of data will catch scheduled batch jobs; 30 days catches month-end processing spikes that can double the required instance tier.
Egress fees: the line item that haunts every post-migration review ¶
Data egress — the charge for moving data out of a cloud provider's network — is priced in a way that is genuinely confusing, and cloud providers have not gone out of their way to clarify it. AWS charges nothing for data in, but between $0.08 and $0.09 per GB out to the internet as of early 2025. Azure and GCP are roughly comparable. In the logistics provider's migration, a nightly ETL process pushed 900 GB of processed records to a third-party analytics vendor. Nobody had modeled that flow. The monthly egress bill came to just under $7,000 — a number that appeared nowhere in the original business case and that persisted for four months before the team rerouted the pipeline through a compressed format and cut the volume by 55 percent. The manufacturer had a similar surprise: their IoT telemetry platform ingested data from 12 facilities into the cloud, then wrote aggregated results back to on-premises dashboards. That bidirectional pattern is almost never caught in a one-way inventory. Map every data flow, label its direction, and annotate its approximate daily volume before migration day.
Parallel-run licensing: the cost of keeping the lights on in two places ¶
There is a period in every migration — sometimes four weeks, sometimes four months — when both the old environment and the new one are running simultaneously. During that window, the organization is paying for everything twice. Compute is the obvious one, but software licensing is where the real surprises live. The insurer ran Oracle Database on-premises under a perpetual license. Moving to AWS RDS for Oracle meant paying Oracle's cloud licensing fees while still covering maintenance on the legacy contract. The overlap lasted 11 weeks and cost $214,000 in licensing alone, a figure that had been estimated at $60,000 in the business case. Microsoft 365 and Windows Server licensing under the Azure Hybrid Benefit program can soften this for Microsoft-centric shops, but the benefit requires careful activation and is routinely missed. The university research group missed it entirely for the first three months and overpaid by roughly $18,000 before a billing review caught the gap. Assign one person — not a committee, one person — to track license state weekly during the parallel-run window.
Professional services scope creep: how a fixed-fee engagement becomes a time-and-materials nightmare ¶
Four of the five migrations used an external systems integrator at some point. Three of those four ended with a contract amendment increasing the original fee. The SaaS startup signed a fixed-fee statement of work for application refactoring at $180,000. By go-live the total professional services spend was $310,000, driven by three change orders: one for unexpected dependency mapping on a legacy authentication service, one for additional security hardening required by a compliance audit that surfaced mid-project, and one for extended hypercare support when the cutover took 36 hours instead of the planned 8. None of these were frivolous; all three were genuinely necessary. The problem was the original scope document, which contained 14 open-ended items described with phrases like 'as required' and 'subject to assessment.' The single most effective contractual protection is a clearly defined change-order threshold — any additional work above a stated dollar figure requires written sign-off from both technical and finance leads before the integrator begins. Setting that threshold at $10,000 per change creates accountability without creating bureaucratic friction on small items.
Training and productivity loss: the human cost that finance models as zero ¶
In every budget model reviewed for this piece, the cost of retraining operations staff appeared as either zero or a nominal $5,000 line item for online course subscriptions. In practice it was never zero. The manufacturer's platform engineering team, six people, spent an average of 22 percent of their working hours over a four-month period on cloud-specific upskilling — reading documentation, attending vendor training, building and tearing down proof-of-concept environments. At fully loaded salaries that represented roughly $96,000 in diverted labor. Productivity loss during the cutover itself is harder to quantify but real: the logistics provider's operations team reported a 15 percent throughput reduction in shipment processing for the three weeks following their database migration, attributable almost entirely to staff unfamiliarity with the new monitoring tooling. Training costs should be modeled as a percentage of affected headcount's annual compensation — the data from these five projects suggests 8 to 12 percent as a reasonable range for a 6-month migration.
Reserved instance commitments and the cost of getting the term wrong ¶
Cloud providers offer substantial discounts for committing to a resource for one or three years. AWS Reserved Instances and Savings Plans, Azure Reserved VM Instances, and GCP Committed Use Discounts can reduce compute costs by 30 to 60 percent compared to on-demand pricing. But the commitment has to match the actual workload, and during a migration the actual workload is a moving target. The insurer committed to a three-year Reserved Instance for a database tier 60 days into their migration — before the full workload picture was clear. Six months later, an application consolidation effort made two of those reserved instances redundant. Selling unused Reserved Instances on the AWS Marketplace is possible but typically yields 80 to 85 cents on the dollar. The insurer recovered $41,000 of a $52,000 commitment, a loss of $11,000 on a decision made prematurely. The practical rule that emerged from reviewing these cases: do not make term commitments during the first six months of a migration. Absorb the on-demand premium, understand the steady-state footprint, then commit.
Building the honest cost model: a category-by-category checklist ¶
Across all five projects, the categories that were most consistently undermodeled were: data egress (missed entirely in three of five cases), parallel-run licensing (underestimated in four of five), professional services change orders (underestimated in three of four projects that used an SI), and staff productivity loss (absent from all five original budgets). A more honest model builds from the inside out. Start with a 30-day discovery-agent baseline for compute and storage. Layer in a network flow map annotated with daily data volumes and directions. Price every software license in both environments for the expected parallel-run window, and add 50 percent to that window as a buffer. Cap professional services scope with explicit change-order controls. Model training as 10 percent of affected headcount compensation. Delay any term commitments for six months. If the resulting number is larger than the first estimate — and it will be — that is not a reason to kill the project. It is a reason to have the right conversation about timeline and phasing before any work begins.
The five organizations in this study all completed their migrations and, in steady state, all of them are paying less than they paid on-premises — the cloud economics argument is real. What was also real was the gap between the cost they expected and the cost they experienced, which ranged from 38 percent to 91 percent above the original estimate. The gap is not inevitable; it is a modeling problem, and modeling problems have solutions. The invoices do not lie.