"Cloud is always cheaper." I must hear this ten times a month. From CTOs who've been briefed by vendors, from CFOs who've skimmed a Gartner summary, from board members who picked it up at a dinner. And honestly, it's one of those statements that's true often enough to be dangerous - because when it's wrong, it's wrong by a lot.
I sat in a budget review with a mid-sized financial services firm last year. They'd migrated their primary web infrastructure to Azure eighteen months earlier, partly because the on-premise hardware was due a refresh and partly because, their words, "everyone's moving to cloud." The CTO pulled up the numbers. Annual cloud spend was running 40% above the original estimate. Egress fees alone were costing them more per month than they'd budgeted for the entire year's storage. The CFO looked at the CTO. The CTO looked at the table. Then the CFO looked at me.
What I told them wasn't particularly comforting: nobody had done anything wrong, exactly. They'd just compared the wrong numbers at the wrong time horizon. They'd looked at the monthly infrastructure cost, seen a saving against their on-premise maintenance bill, and approved the migration. What they hadn't modelled was the three-year picture - including the migration cost itself, the parallel-run period where they were paying for both environments simultaneously, the egress fees, the premium support tier they'd need once their two in-house infrastructure people were redeployed.
They stayed on Azure, by the way. Migrating back would have cost more than riding it out and renegotiating the contract. That's the kind of corner you can paint yourself into when the business case was built on a twelve-month comparison.
That's the problem I want to unpack here. Not whether cloud is good or bad - that's a meaningless question without context - but how to actually work out which scenario you're in. The financial analysis that determines whether cloud saves you money or costs you more requires a three-year cost model, not an annual licence comparison.
I've written a companion piece on total cost of ownership for digital platforms more broadly - the framework here is a specific application of that wider TCO model, focused on the cloud vs. on-premise question.
Let me start with the scenarios where the financial case for cloud is strong. Not theoretically strong. Actually strong, in a way that holds up when you model it properly over three years.
Variable or unpredictable workloads. If your web traffic spikes seasonally - say you're a consultancy that publishes an annual benchmarking report and traffic quadruples for three weeks - you're sizing on-premise infrastructure for peak demand and paying for that capacity the other forty-nine weeks. Cloud's elastic scaling means you pay for what you use. A firm I worked with in professional services was running servers sized for their busiest month. Eleven months of the year, they were using about 30% of capacity. The maths on that one was straightforward.
Approaching a hardware refresh cycle. On-premise infrastructure has a three-to-five-year replacement cycle. When you're staring down a six-figure refresh bill plus the ongoing maintenance and internal IT time to manage it, cloud often wins - particularly when you cost your IT team's time honestly, which almost nobody does. I'll come back to that.
IT teams buried in infrastructure management. This one's subtle but significant. If your infrastructure team is spending most of its time keeping the lights on - patching servers, managing backups, dealing with capacity planning - that's time they're not spending on anything that moves the business forward. Cloud-managed infrastructure eliminates a whole category of work. The resulting capacity for higher-value activity is a real saving, even if it doesn't show up on a line item.
Disaster recovery that's expensive to replicate on-premise. Cloud providers offer geographic redundancy and automated failover as standard. Building equivalent resilience on-premise - a secondary data centre, replicated storage, tested failover procedures - requires investment that most mid-market firms simply haven't made. If your current DR plan involves someone driving a backup tape to another building, we should talk.
Here's where it gets interesting. And where I lose some people, because we've all been marinated in the "cloud is inevitable" narrative for so long that questioning it feels a bit like suggesting we go back to fax machines.
Cloud is always cheaper. That's what everyone says.
Right. And everyone said open-plan offices boosted collaboration, too. The evidence was thinner than advertised.
Stable, predictable workloads. If your infrastructure requirements are consistent - same traffic, same processing needs, month in, month out - you're paying a premium for elasticity you never use. Over three years, the fixed cost of properly sized on-premise infrastructure is typically lower than equivalent cloud capacity for stable workloads. Not always. But typically. And "typically" matters when you're making a three-year commitment.
But we might need to scale quickly. What if we grow faster than expected?
Fair point. Worth modelling. But "we might need to scale" is a reason to include a scaling scenario in your cost comparison, not a reason to skip the comparison altogether. I've seen that logic used to justify cloud migrations where the firm's traffic had been flat for four years. Hope is not a cost model.
Significant existing infrastructure that isn't end-of-life. This one frustrates me because it's so avoidable. I've seen firms migrate to cloud when their on-premise hardware still had two or three years of useful life. They've effectively written off that remaining value and added migration costs on top. If your current infrastructure is working, is supported, and isn't due for refresh for a couple of years - the financially rational thing to do might be to wait. I know that's not exciting. But your CFO will thank you.
Simple hosting needs. Not every workload requires the capabilities of AWS or Azure. A marketing website with moderate traffic and straightforward content management is often cheaper on a managed hosting provider or a co-location arrangement. The major cloud platforms are engineered for complexity and scale. If you don't need either, you're paying for capabilities you'll never touch. It's a bit like hiring a removal lorry to take one box across town.
This is the section I wish more people read before signing cloud contracts. The gap between estimated cloud cost and actual cloud cost, across dozens of client engagements, consistently runs 20-40% above the initial projection. Not because anyone lied. Because the initial projection didn't account for several line items that only become visible once you're in.
Data egress fees. Cloud providers charge you to take data out of their environment. Moving data in is free or cheap. Moving it out costs money. If you're running a high-traffic website, serving large media files, or moving data between cloud and on-premise systems, egress fees add up fast. One client of ours, a professional services firm with a substantial media library, was paying more in egress fees than their original hosting bill. Nobody had modelled it because nobody had asked the question. Eek.
Storage cost creep. Cloud storage is cheap per gigabyte. That's true. But data volumes grow. Content libraries expand. Backup and logging data accumulates. And unless someone is actively managing storage - archiving old data, cleaning up redundant backups, right-sizing retention policies - the total cost drifts upward. We've seen firms whose storage costs doubled within eighteen months, not because they'd done anything dramatic, but because nobody was watching.
Premium support. The default support tier on most cloud platforms is designed for organisations with dedicated cloud engineering teams. If you're a 200-person professional services firm with a small IT function, and your production site goes down at 9 am on a Monday, you need someone on the phone within minutes. That level of support isn't included in the base price. Premium and enterprise support contracts from AWS and Azure add materially to the annual cost - and they're rarely included in the business case.
The migration itself. Moving applications, data, and configurations to a new environment is a project. It requires testing, validation, and a parallel-run period where you're paying for both environments simultaneously. That parallel period - three months is typical, six months isn't unusual - is always the most expensive phase of a cloud migration. I've seen business cases that treated migration as a one-line item at 10% of the first year's cloud cost. The actual figure was closer to 40%.
Compliance configuration. If you're in financial services, legal, or any regulated sector, your cloud environment needs specific security controls, audit logging, data residency configuration, and access management. This isn't optional and it isn't trivial. We worked with a US bank that had migrated to a cloud-hosted CMS only to discover - three months after launch - that their data residency configuration didn't satisfy their regulator's requirements. Fixing it cost more than the original migration. You can read about how we approached a similar situation in our work with a regulated US bank.
Here's the framework I'd recommend. It's not complicated, but it does require you to be honest about all the costs on both sides. I've seen too many business cases that are rigorous about cloud costs and hand-wavy about on-premise costs, or vice versa.
Year 0 - the capital comparison. For cloud: what does the migration actually cost? Include testing, parallel run, compliance configuration, and staff time. For on-premise: what does the hardware refresh cost? Include installation, configuration, and any associated software licence renewals.
Years 1-3 - the annual running costs. For cloud: subscription fees, support tier, estimated egress, storage (with a growth assumption), and any compliance maintenance. For on-premise: hardware maintenance contracts, software licences, IT labour allocated to infrastructure management (be honest about this - it's usually higher than people think), power and facilities costs, and the opportunity cost of your infrastructure team's time.
Year 3 - residual value. On-premise hardware has residual value at year three - it's still functional, even if it's approaching end-of-life. Cloud has an exit cost if you ever want to migrate away. Neither of these is zero.
Run the comparison as three scenarios: conservative, central, and optimistic. Both cloud and on-premise costs have genuine uncertainty. A cloud migration that wins in the central scenario but loses in the conservative scenario should be presented to the board as a risk, not a clear financial win. That's not being negative, it's being accurate.
If you want the three-year cost comparison model as a pre-built spreadsheet - covering all five cost categories for both cloud and on-premise, with a three-scenario output - download it here. It's designed so that a CTO and CFO can sit down together and work through it in half a day with the infrastructure cost data you already have.
There are genuine non-financial benefits to cloud that matter. Security, for one. Cloud providers' infrastructure security is typically superior to what a mid-market firm can build and maintain on-premise. That's real. I've written separately about the security risks hiding in legacy platforms - and cloud migration can address several of them.
Disaster recovery capability is another. Automated geographic redundancy and failover is genuinely valuable, and building equivalent resilience on-premise costs serious money.
Development flexibility too. Spinning up test environments, experimenting with new architectures, provisioning infrastructure for a new project in hours rather than weeks - these are real operational advantages.
But here's the thing: these benefits belong in the decision, not in the cost model. The moment you start converting vague operational benefits into financial projections to make the cloud business case work, you've lost the financial rigour that makes the analysis credible. Quantify them separately. Present them alongside the cost comparison, not baked into it. Your CFO will respect you more for it.
This all feeds into the broader question of how you're investing in your digital estate - and there's a separate piece on cloud strategy for mid-market service firms that covers the decision framework beyond just the financials.
Cloud saves money for some firms, in some scenarios, when you do the sums properly over three years. It costs more for others. The difference isn't a matter of opinion - it's a matter of arithmetic. But only if you're doing the arithmetic with all the costs on both sides of the ledger, over a realistic time horizon, with scenarios that account for the things you don't know yet.
The worst outcome isn't choosing cloud when on-premise was cheaper, or vice versa. The worst outcome is making a three-to-five-year infrastructure commitment based on a comparison that only looked at the first twelve months. That's the mistake I keep seeing. And it's entirely avoidable.
If you're currently evaluating a cloud migration, or if you've already migrated and the costs aren't where you expected, download the cost comparison template and run the numbers properly. Or get in touch for a cloud readiness assessment. Sometimes half a day with the right framework saves you three years of overspending.