I’ve reviewed cloud migration budgets for over forty organisations in the past three years. I can count on one hand the number that accurately predicted their actual spend. The rest underestimated by 30-50%, and a few blew past their budgets by even more.

This isn’t because the people building the budgets are incompetent. It’s because cloud migration has a structural tendency toward hidden costs that don’t appear until you’re well into the process. Understanding where these costs hide is the first step toward building a budget that actually holds.

The Lift-and-Shift Illusion

Most migration budgets start with a compute mapping exercise. You inventory your on-premises workloads, find the equivalent cloud instances, and calculate the monthly cost. Then you add some buffer for data transfer, tooling, and project management. The number looks reasonable. It’s wrong.

Lift-and-shift rarely works as planned. Applications that ran fine on dedicated hardware behave differently on shared cloud infrastructure. Performance issues appear that require larger instances than planned. Dependencies between systems create unexpected networking costs. Applications that shared on-premises database servers need their own cloud database instances.

One organisation I worked with budgeted for 40 cloud instances based on their on-premises server count. They ended up running 67 instances because of shared services that needed to be separated, development and staging environments that previously ran on spare capacity, and performance requirements that demanded larger instances than the on-premises hardware specification suggested.

Data Transfer Costs

Cloud providers charge for data egress — moving data out of their platform. This is one of the most consistently underbudgeted items because it’s difficult to predict before migration and the pricing model is counterintuitive for organisations used to paying for bandwidth rather than data volume.

Inter-region data transfer, data flowing between cloud services, and backup data leaving the cloud all incur charges. During migration, you’re often running hybrid — some systems on-premises, some in cloud — which means constant data flow between environments.

A financial services company I advised budgeted $8,000 per month for data transfer. Their actual costs hit $32,000 per month during the hybrid operating period because their applications exchanged far more data between systems than anyone had mapped. The data transfer costs didn’t reduce until the full migration was complete and all systems were within the same cloud environment.

The AWS pricing calculator and equivalent Azure tool help estimate steady-state costs but consistently underestimate migration-period expenses because they can’t model the temporary hybrid architecture accurately.

The Skills Gap Tax

Your existing team knows your on-premises environment intimately. They don’t know cloud. Training takes time, and during that learning curve, everything takes longer and costs more.

Tasks that took an experienced on-premises engineer two hours take a cloud-learning engineer two days. Configuration mistakes happen — and in cloud environments, misconfigurations cost money directly through overprovisioned resources or security incidents, not just through lost productivity.

Most migration budgets include a line item for training courses. Very few account for the productivity loss during the learning period or the cost of cloud-specific mistakes. I typically advise organisations to assume their team will operate at 60% productivity for the first six months of cloud operations and budget accordingly.

Some organisations bring in contractors or consultants to bridge the gap. That works, but it’s expensive and creates a different problem — knowledge concentrated in temporary staff who leave when the contract ends.

Security and Compliance Rework

Cloud security is fundamentally different from on-premises security. Network perimeters don’t work the same way. Identity management is more complex. Data classification and encryption requirements change. Compliance controls that worked in a data centre need to be reimplemented for cloud.

I’ve seen organisations discover mid-migration that their compliance framework doesn’t cover cloud-hosted data. The remediation work — updating policies, implementing new controls, conducting audits — wasn’t in the migration budget because nobody flagged it during planning.

The Australian Cyber Security Centre’s cloud security guidance provides a useful framework, but implementing it properly takes time and specialist knowledge that most organisations don’t have in-house.

Application Refactoring You Didn’t Plan For

The migration plan says lift-and-shift. Reality says otherwise. Applications with hard-coded IP addresses need modification. Software that depends on specific hardware configurations needs rearchitecting. Licensed software with physical-server-based licensing needs renegotiation.

Database migrations are particularly problematic. Moving from on-premises SQL Server to Azure SQL or from Oracle to Aurora involves more than copying data. Stored procedures may need rewriting. Query performance changes. Failover and backup configurations work differently.

Every migration I’ve been involved with has discovered at least three applications that couldn’t be lifted and shifted as planned. The refactoring work typically adds 20-30% to the project timeline and 15-25% to the budget.

How to Budget Better

Build your migration budget, then add 40%. I know that sounds simplistic, but the data supports it. The consistent pattern of 30-50% overruns means your baseline estimate needs significant contingency.

More specifically:

Run a proper discovery phase. Spend money upfront on detailed application dependency mapping, data flow analysis, and workload profiling. The discovery phase typically costs 5-10% of the migration budget and saves multiples of that by catching hidden costs early.

Budget for a longer hybrid operating period. Most organisations underestimate how long they’ll run both on-premises and cloud simultaneously. Budget for six months longer than your plan says.

Include operational cost changes. Cloud operations require different tooling — cost management platforms, security monitoring tools, infrastructure-as-code pipelines. These are ongoing costs that didn’t exist in your on-premises environment.

Plan for the post-migration optimisation phase. Your initial cloud deployment won’t be cost-optimised. Budget for three to six months of right-sizing, reserved instance purchasing, and architectural optimisation after migration is complete.

The organisations that get cloud migration budgets right are the ones willing to spend money on thorough planning and honest contingency. The ones that get them wrong are usually the ones who skipped discovery to save money and then paid for it three times over during execution.