I’ve reviewed cloud migration budgets for about twenty Australian organisations over the past three years. Exactly two of them came in under budget. The rest overran by between 30% and, in one memorable case, 180%.

The pattern is depressingly consistent. The initial budget covers infrastructure costs, some consulting time, and a contingency buffer that’s never large enough. Everything else gets discovered along the way.

Here’s where the money actually goes.

The Costs You Forgot

Data egress and transfer. Everyone budgets for cloud compute and storage. Almost nobody budgets adequately for moving data. Getting terabytes of data from on-premises into cloud isn’t free, and it isn’t fast. AWS charges for data transfer out. Azure charges for data transfer out. These costs compound quickly when you’re running hybrid during migration—which you will be, for months longer than planned.

A financial services client estimated $12,000 per month in data transfer costs during migration. Actual cost: $34,000 per month, because their applications were chattier between environments than anyone expected.

Application refactoring. “Lift and shift” is a myth for anything beyond the simplest workloads. Applications that worked fine on-premises develop unexpected behaviours in cloud environments. Network latency changes. DNS resolution works differently. File system assumptions break. The AWS Well-Architected Framework acknowledges this—most applications need at least some modification.

Budget for it. Specifically, budget 40-60% more application development time than your initial estimate.

Skills and training. Your team knows on-premises infrastructure. They don’t know cloud-native operations. Training costs money, but more importantly, it costs time. Your best people will be less productive for 3-6 months while they build cloud competency. Factor in temporary contractor support to backfill.

Parallel running costs. During migration, you’re paying for both environments. Your on-premises infrastructure doesn’t disappear the day you start moving workloads. Existing lease commitments, support contracts, and power costs continue. Most migrations run parallel for 12-18 months. That’s 12-18 months of double infrastructure costs that rarely appear in the original budget.

The Timeline Problem

Budget overruns are partly about missing cost items, but they’re mostly about timeline slippage. Migrations take longer than planned, and every extra month multiplies costs.

Why do timelines slip? Dependencies. Application A can’t move until Database B is migrated. Database B can’t move until the networking team implements the VPN tunnel. The networking team is waiting on the security team’s firewall rule review. The security team is understaffed because two people quit last month.

I’ve never seen a migration timeline that adequately accounted for internal dependencies. The Gartner research on cloud migration consistently shows that organisations underestimate migration timelines by 40-70%.

How to Build a Better Budget

Start with an honest application inventory. Not the one in your CMDB—the real one. Walk the data centre. Talk to application owners. Find the shadow IT systems running on that server in the corner that nobody remembers deploying.

For each application, assess:

• Can it move as-is, or does it need modification?
• What data does it depend on, and where does that data live?
• Who has the knowledge to migrate it, and are they available?
• What compliance requirements affect where it can run?

Then build your budget in three tiers:

Tier 1: Known costs. Cloud infrastructure, licencing, consulting fees. These are the easy ones.

Tier 2: Likely costs. Application refactoring, training, extended parallel running, data transfer. You can estimate these with reasonable accuracy if you do the application assessment properly.

Tier 3: Contingency. Not 10%. Not 15%. Budget 25-30% contingency for a first-time migration. If that sounds excessive, talk to anyone who’s been through one. They’ll tell you it’s barely adequate.

Working with AI strategy support firms can help model these costs more accurately, particularly when assessing which applications need refactoring versus replacement—a decision that dramatically affects the budget either way.

What Success Actually Looks Like

The two organisations that came in under budget shared two characteristics. First, they took six months longer to plan than everyone thought was necessary. Second, they migrated fewer applications than originally scoped, choosing to retire or replace some rather than move them.

That’s the counterintuitive lesson. The way to hit your cloud migration budget is to spend more time planning and migrate less. Move the workloads that genuinely benefit from cloud. Retire the ones that don’t. Replace the ones that need replacement regardless.

Your cloud migration budget is probably wrong. The question is whether you’ll discover that now, while you can still fix it, or later, when you’re already committed and the board is asking uncomfortable questions about cost overruns.

I know which conversation I’d rather have.