Cloud first was a mistake. Place workloads on evidence instead.

Cloud first was a mistake. Place workloads on evidence instead

A few years ago an organisation I worked for was preparing to move its estate into Azure. The plan had momentum and a rough business case behind it. What it did not have was arithmetic.

We built it. Real utilisation, real growth, real licensing, and what those same workloads would cost on refreshed hardware in a properly designed environment. The business case that came out of that work avoided roughly £3m against the proposed migration and was signed off. The infrastructure stayed where it was, and so did the ability to decide what happened to it next.

Consultants had been brought in to assure the programme. The numbers went in front of them and the recommendation did not shift. Cloud first was still the right answer, apparently, for an organisation with no spare money and services already under pressure. Independent assurance is meant to be the safeguard against this sort of thing. It stops working the moment the reviewers arrive already holding the conclusion.

That is the whole argument in one project. Cloud is a good option. Cloud first was a doctrine, and doctrines stop people doing sums.

The savings were oversold

A server that runs continuously does not become cheaper because it runs in somebody else's building. The cost is repackaged as subscription, consumption, storage tiers, egress, logging, support, backup and licensing. The invoice looks smaller than a purchase order and it never stops arriving.

Spending also spreads. A project starts with compute and storage, then adds monitoring, load balancing, a managed database, a security service, backup, premium support and a third-party tool with its own bill. Test environments outlive their tests. Snapshots stay. Data settles into expensive storage classes. Most organisations I work with cannot explain their cloud invoice line by line. The cause is almost always weak design and absent governance.

The published cases are worth reading rather than arguing about. 37signals moved off cloud after a $3.2m annual bill, spent around $700,000 on hardware, and cut close to $2m a year. Its projected saving now runs beyond $10m over five years. Those figures do not fully price hardware refresh, operational maturity or data centre space over time, so treat them as evidence rather than proof. The lesson is that the sums are worth doing and that nobody can tell you the answer in advance.

The CapEx and OpEx argument was always thin

Hardware has been leasable for decades. Equipment can be financed, hosting can be managed, and British providers were selling infrastructure as a service long before subscription infrastructure became fashionable. Cloud standardised one version of that model and put an excellent self-service portal in front of it.

Predictable spend has value of its own. An owned or leased environment has known capacity and reasonably stable costs across several years. A cloud environment expands with no physical brake, which is an advantage during genuine growth and an expensive habit when what is actually growing is inefficiency.

Control is the part that gets given away

An organisation can own its data completely while depending on another company's infrastructure, identity platform, management plane and commercial terms. A billing dispute, a compromised account, a regional outage or a policy change can reach into services that used to sit behind a door you held the key to.

Hyperscalers invest more in resilience and physical security than any single customer could. They also fail at a scale that makes their bad days everybody's bad day at once. Architectures spread across several services from one provider frequently rest on one dependency underneath. Variety is not independence.

The Competition and Markets Authority examined the UK public cloud infrastructure market, which it valued at around £9bn, and concluded in July 2025 that competition was not working well. Its inquiry group recommended strategic market status investigations into Microsoft and AWS. In March 2026 the CMA board declined to prioritise those investigations and accepted voluntary commitments on egress fees and interoperability instead. Views on that outcome differ. The finding underneath it is not really contested: switching providers is hard.

Exit planning belongs in the original design

Data goes in easily. Large volumes come out slowly and expensively, particularly once systems have grown roots into managed databases, proprietary analytics, identity services and provider-specific APIs.

Every board should be able to answer three questions. How would we recover our data? How would we rebuild these services elsewhere? How long would we keep operating if the relationship with this provider changed? Cloud-first programmes were designed around entry. Very few were asked about the exit.

Security, resilience and the value of hard boundaries

A secure platform does not produce a secure tenancy. Cloud breaches keep involving weak identities, exposed storage, excessive privilege, unmanaged credentials and automation that reproduces a mistake across hundreds of resources before anyone reads the alert.

On-premises has its own risks, and unpatched systems with flat networks are not a safer place to be. What it offers is boundaries you can enforce physically. Sensitive networks off the public internet. Management access restricted to dedicated administrative systems. Backup isolated from production identity. Data in a building you can point at.

Resilience follows the same logic. Availability zones protect against site and hardware failure. They do little against a control-plane outage or an identity failure. A local platform continues working when the connection to the outside world does not, which matters in manufacturing, logistics, healthcare, retail and anywhere the work happens in a physical place.

Cloud exit is ordinary engineering, done carefully

Repatriation gets described as a retreat, usually by people with something to sell. It is a rational response to stable workloads, high data volumes, unpredictable billing or regulatory obligations that are simpler to meet on infrastructure you control.

The work starts with discovery: applications, data stores, interfaces, certificates, service accounts, network dependencies, recovery requirements and every provider-specific component that will not come out cleanly. The replacement platform is designed around real utilisation and real failure scenarios. Then the physical work begins, and it is genuine engineering. Rack space, power, cooling, cabling, optics, firmware, storage paths, backup windows, hardware lead times, routing, tested rollback, verified backups and business acceptance.

The migration is complete when the service is stable, monitored, documented, secured and supported. Powering on the server is the easy part.

Cloud is a good option, but not the only one

Cloud first was a mistake. Cloud is a good option, but it is not the only one. The right answer is to place workloads where the evidence says they belong.

Workload first

On-premises first would be the same mistake wearing different clothes. Each service belongs where the evidence puts it, judged on security, cost, resilience, performance, data sensitivity, the skills available to run it and what the business needs.

Some workloads belong in public cloud permanently. Some belong in private cloud or colocation. Some belong on dedicated hardware you control. Most established organisations need a combination, and it changes as costs, regulation and demand move.