Others have tackled this question with more data than we have. But we have a different angle on it — one that comes from sitting inside enterprise IT programmes and watching the cloud bill grow while the business case that justified the migration quietly gets forgotten.
The short answer to the question in the title is: sometimes. The longer answer requires you to be honest about a few things that most cloud migration business cases aren’t.
The op-ex trap
Cloud is sold on operational expenditure. No capital outlay, pay for what you use, scale up and down as needed. For the right workloads — variable demand, short-lived environments, genuinely elastic compute — this model is compelling.
For the wrong workloads, it’s expensive. And enterprise IT has a lot of the wrong workloads.
Here’s the question nobody asks loudly enough in a migration business case: how long will this application actually run in the cloud before it’s replaced, upgraded, or decommissioned? Application owners will say three years. The realistic answer, based on the average enterprise application lifecycle, is closer to seven. Double the op-ex figure in your business case. You are almost certainly underestimating it.
A workload with a steady-state compute requirement of 48 vCPUs and 192GB RAM — not unusual for an enterprise application — will cost you roughly £1,670 per month on Azure or AWS at on-demand rates. That’s £20,000 a year. Over five years, £100,000. The equivalent on-premise hardware — a Dell PowerEdge R750 configured to spec — costs around £9,700 as a one-off capital purchase. The numbers are not always in the cloud’s favour, and anyone who tells you otherwise without running the actual numbers for your specific workload is selling you something.
But the on-premise comparison is also wrong
The hardware cost comparison is real, but it’s incomplete. On-premise compute comes with costs that rarely appear in the comparison: data centre space, power, cooling, network switching, hardware refresh cycles, and the operational cost of the team managing it. Depending on your organisation, these can add 40-60% on top of the hardware cost. The cloud vendors know this and will happily remind you of it.
The honest answer is that neither side of the argument — cloud evangelists or cloud sceptics — is presenting the full picture. The right answer depends on your workload profile, your existing contracts, your operational model, and your time horizon.
Where cloud genuinely wins
Variable and unpredictable demand. If your workload has peaks and troughs — seasonal retail, batch processing, development and test environments — cloud economics work in your favour. You’re not paying for capacity that sits idle at 3am on a Tuesday.
Speed to market. Provisioning a new environment in Azure takes minutes. Procuring, racking, and configuring on-premise hardware takes weeks. For organisations that need to move fast, the operational flexibility has real value that doesn’t appear on a cost comparison spreadsheet.
Managed services. Running your own SQL Server cluster, your own Kubernetes infrastructure, your own backup and recovery systems — these all have operational costs. Azure SQL, AKS, and Azure Backup shift that operational burden to Microsoft. The compute cost might be higher, but the total cost of ownership can be lower.
Resilience and DR. Building genuine high availability and disaster recovery on-premise is expensive. Cloud platforms make it significantly cheaper to achieve the kind of resilience that most enterprises struggle to justify on-premise.
Where cloud loses
Stable, predictable, high-compute workloads. If you have an application that needs 48 vCPUs and 192GB RAM running 24/7 for the next five years, and that requirement doesn’t change, you are probably better off on reserved hardware. The cloud break-even point on reserved capacity (1 or 3-year commitments) improves the picture significantly — a 3-year Reserved Instance on Azure or AWS reduces the monthly cost by roughly 40-60% — but you’re now making a commitment that undermines one of the core arguments for cloud in the first place.
Egress costs. This one catches organisations out repeatedly. Getting data into cloud is cheap or free. Getting it out costs money. If your workload generates significant outbound data — backups, integrations, reporting — the egress costs alone can make the economics uncomfortable.
What we actually do about it
The organisations that manage cloud spend well have three things in common. First, they have visibility — tagging policies that attribute every pound of spend to a business unit, application, or environment. Without this you are managing a bill, not a budget. Second, they have governance — budget alerts, anomaly detection, and a process for reviewing spend against expectations. Third, they make architectural decisions with cost in mind — choosing the right service tier, using spot or preemptible instances where appropriate, rightsizing compute rather than provisioning for peak and leaving it there.
At Xpress Net we’ve delivered cloud cost reductions of up to 30% for clients who had been running in Azure or AWS for two or more years without a formal FinOps practice. In most cases the savings were hiding in plain sight — oversized VMs, orphaned resources, missing Reserved Instance coverage, and PaaS services running at full price when a lower tier would have been more than adequate.
The cloud commercial model can make sense for enterprise. But only if you’re running the right workloads on it, with the right architecture, and with someone watching the bill.