The Costs Your Cloud Migration Business Case Didn't Include
In this article

We have reviewed cloud migration business cases for organisations ranging from 500 to 15,000 employees. The pattern is always the same. The spreadsheet shows current on-prem costs on the left, projected cloud costs on the right, and a neat 20-40% savings at the bottom. Then reality hits.
Gartner reported earlier this year that enterprise cloud spending exceeds initial budgets by 20-30% on average. That number is generous. In our experience, the first 18 months of a cloud migration cost 40-60% more than planned. Not because cloud is a bad deal, but because the business case only counted the costs that are easy to count.
The compute, storage, and networking line items are correct. Everything around them is missing.
The Business Case Only Counts What It Can See
A typical migration business case compares annual data centre costs (hardware depreciation, hosting fees, power, cooling) against projected cloud spend (VM instances, managed databases, storage, bandwidth). The math is clean. You can pull the cloud pricing from a calculator and the DC costs from last year’s invoices.
What the business case almost never includes:
The people who will build and run the cloud platform. The months (or years) you will pay for both environments simultaneously. The licensing that gets more expensive when it moves off your own hardware. The productivity loss while 200 engineers learn a new stack. The applications that need partial or full rewrites because lift-and-shift doesn’t work.
These aren’t edge cases. They show up in every migration above a certain scale. Let’s put numbers on them.
Platform Teams Nobody Budgeted For
Your on-prem environment has an ops team. You assumed they would “become the cloud team.” Some of them will. Most won’t, at least not at the speed the migration demands.
A functioning cloud platform team for a mid-size enterprise needs 4-8 people: cloud architects, infrastructure-as-code engineers, security specialists, and someone who understands networking in both worlds. In Western Europe, that’s EUR 500K-900K in annual salary costs. If you’re hiring externally (and you will be, because the internal team is still running the data centre), add 20-30% for recruitment fees and ramp-up time.
We helped one financial services client build out an Azure landing zone and the platform team alone consumed EUR 1.2M in the first year. That number wasn’t anywhere in the original business case. The business case assumed “existing IT staff” would handle the cloud, with perhaps one additional hire.
The platform team isn’t optional. Without it, you get shadow IT in the cloud, which is shadow IT on a credit card with auto-scaling turned on. That’s more expensive than whatever you were trying to save.
The Dual-Run Trap
Here is the cost that surprises leadership the most: you will run both environments in parallel for far longer than planned.
Every migration plan we’ve seen assumes a 6-12 month transition window. In practice, it takes 18-30 months. Applications have dependencies. Database migrations take longer than estimated. The team that owns the legacy payroll system has other priorities. Compliance requires parallel testing before decommission.
During the dual-run period, you are paying for everything twice. The data centre lease doesn’t get cheaper because you moved 40% of workloads. The hosting contract has minimum commitments. Your VMware licenses are annual. Meanwhile, cloud costs are ramping up as workloads go live.
One manufacturing client we worked with planned a 12-month migration. At month 18, they had moved 60% of workloads to Azure but were still paying 85% of their original data centre costs. The remaining 40% of workloads included their ERP system, a mainframe integration, and three applications with no documentation and no original developers. Those workloads took another 14 months.
For 18 months, they paid roughly 1.8x their original infrastructure costs. That overlap period cost EUR 2.1M more than budgeted.
Licensing: The Silent Budget Killer
Software licensing on cloud infrastructure is a minefield, and the vendors know it.
SQL Server is the most common trap. On-premises, you probably run SQL Server Enterprise on a few large hosts with Software Assurance. In Azure, you have options: Azure SQL Managed Instance, SQL on VMs with Azure Hybrid Benefit, or Azure SQL Database. Each has different licensing implications. Without Azure Hybrid Benefit (which requires active Software Assurance), running SQL Server Enterprise on a 16-core VM in Azure costs roughly USD 6,700/month in license fees alone. Per VM.
Oracle is worse. Oracle’s licensing policy for cloud environments has been deliberately ambiguous for years. Running Oracle Database on AWS EC2 requires counting vCPUs, but Oracle’s definition of “processor” doesn’t match AWS’s definition of “vCPU.” We’ve seen clients face Oracle audit claims that doubled their expected licensing costs after moving to cloud.
Windows Server licensing in the cloud isn’t free either. Azure Hybrid Benefit helps, but only if you have Software Assurance. If your EA expired during the migration, you might be buying Windows Server licenses at retail cloud rates.
Then there are the tools: your monitoring suite (Datadog, Dynatrace, New Relic) now instruments twice the infrastructure during the dual-run period. Your backup solution needs cloud connectors or replacement. Your SIEM needs cloud log ingestion. Each of these is a line item that the original business case treated as “equivalent cost,” but cloud monitoring at scale often costs 2-3x what on-prem monitoring did, simply because there’s more telemetry to collect.
Training and Hiring Costs
Moving to the cloud means your engineers need new skills. Not “watched a Pluralsight course” skills. Hands-on, production-grade skills with IAM policies, networking constructs, IaC tooling, and cloud-native services they’ve never used.
A realistic training programme for a team of 50 engineers looks like this: 2-3 days of formal training per person (EUR 1,500-2,500/person), plus 3-6 months of reduced productivity while they build muscle memory. The formal training costs EUR 75K-125K. The productivity loss is harder to measure but far more significant. Developers who took 2 days to ship a feature on-prem now take 5 days because they’re learning Azure Resource Manager, figuring out why their app can’t reach the database through a private endpoint, and reading documentation for services they’ve never touched.
Then there’s attrition. Some of your best on-prem engineers don’t want to learn cloud. They leave. Replacing a senior engineer costs 6-9 months of salary in recruitment and ramp-up time.
The organisations that handle this well invest in a self-service platform with guardrails so that application teams don’t need to become cloud infrastructure experts. But building that platform is itself an investment of 3-6 months of platform team effort.
What a Realistic Migration Budget Looks Like
Take your original compute-only cloud estimate. Now add:
- Platform team costs: 4-8 FTEs for 2+ years (EUR 1-2M depending on location and seniority)
- Dual-run overhead: 12-24 months of paying for both environments (30-80% of your current DC costs, depending on contract flexibility)
- Licensing remediation: audit your SQL Server, Oracle, Windows, and third-party tool licenses before you move. Budget 15-25% above your current licensing costs for the transition period
- Training and productivity: EUR 2K-5K per engineer for formal training, plus 15-25% productivity reduction for 6 months across the engineering org
- Application refactoring: 20-30% of workloads won’t lift-and-shift cleanly. Budget 2-4 sprints per application for re-architecture, whether that’s containerisation, database migration, or rewriting the authentication layer
- Consulting and external support: unless you’ve done this three times before, you need people who have. Budget EUR 200-500K for architecture guidance, landing zone design, and migration execution support
Add those together and the first two years of a cloud migration for a mid-size enterprise (1,000-5,000 employees) typically cost 50-80% more than the compute-only estimate.
That doesn’t mean cloud is a bad investment. It means the payback period is 3-4 years, not the 12-18 months your CFO’s spreadsheet promised.
Why Migrations Still Make Sense (With Honest Numbers)
DHH’s cloud exit posts at Basecamp made headlines this year. His math is correct for his situation: a stable, predictable workload with a team that can run bare metal. Most enterprises aren’t Basecamp. They have variable workloads, compliance requirements that favour managed services, and an IT team that’s already stretched thin.
Cloud migration makes financial sense for most enterprises. But only if you budget for what it actually costs, and plan for a 3-5 year payback instead of pretending you’ll break even in year one.
Three things we recommend to every client starting a migration:
Run the licensing audit first. Before you move a single workload, model every software license in the cloud target. This single exercise has saved our clients hundreds of thousands in unexpected costs.
Plan for 24 months of dual-run. If it takes 18 months, great. If it takes 24, you’re not scrambling for emergency budget. Negotiate break clauses in your DC contracts if you can.
Fund the platform team from day zero. Don’t wait until the migration is underway to hire cloud engineers. The platform team should be building the landing zone, the IaC pipelines, and the operational runbooks 3-6 months before the first workload moves. By the time applications start migrating, the platform should already be proven.
The cloud will probably save you money in the long run. But “the long run” starts after you’ve paid for everything that wasn’t in the original spreadsheet.
Looking for Azure architecture guidance?
We design and build Azure foundations that scale - landing zones, networking, identity, and governance tailored to your organisation.