The Premium You Didn't Budget For: Running a Second Cloud Estate in the UK

Multi-cloud often arrives in a UK organisation the same way a spare umbrella does: someone senior gets caught in a shower, and the next thing you know there are two of everything in the cupboard. The board slide says we are resilient because we are not dependent on one provider. The invoice says something else. It says you are now running a second estate.

That is not an argument against multi-cloud. It is an argument for pricing it honestly. Resilience is an insurance product, and insurance has a premium. In cloud, the premium is not just the contract. It is the skills, identities, data movement, support arrangements and management attention that come with a second platform. If those costs are not in the business case, the business case is a wish.

The premium is not the line item you expected

Most UK teams are good at costing the obvious things: compute, storage, a few licences, maybe a migration partner. The harder costs sit underneath. A second cloud means a second set of networking quirks, a second permissions model and a second way of doing managed databases. It means two sets of documentation, two sets of guardrails and two sets of problems that only one or two people understand.

None of that is wasted money if you genuinely need it. The problem is buying it by accident. A multi-cloud strategy that exists mainly to reassure a board or satisfy a procurement checkbox will still need a team to operate it on a wet Tuesday in Leeds.

Skills are duplicated, not halved

A common assumption is that a cloud team can simply learn the other provider. Some can. But fluency takes time, and the UK market for people who are genuinely strong across two major clouds is thinner and more expensive than the slide deck suggests. You do not need every engineer to be bilingual. You do need enough people who can debug identity policies, read network logs and know when a managed service is behaving badly on each platform.

There is also the on-call rota. Two clouds can mean two escalation paths, two sets of runbooks and two different ideas about what counts as a major incident. If the same small team carries both, the rota gets heavier. If you hire separate teams, the payroll gets heavier. Either way, someone pays.

Identity gets split down the middle

Identity is where the second estate often becomes visible first. One cloud has its groups, roles and policy language. The other has its own. Single sign-on can make the login screen look tidy, but authorisation is not one thing. Joiners, movers and leavers need consistent treatment across both platforms. Break-glass accounts need to be tested in both. Access reviews need evidence from both.

A useful test is to ask whether you can answer one simple question in under an hour: who can read the customer database, across every cloud you run? If the answer involves two spreadsheets, three screenshots and a meeting, the operating model is not finished. Central identity governance helps, but it has to be designed rather than assumed.

Data movement has a meter and a memory

Cross-cloud data movement is the cost that hides best in architecture diagrams. One arrow between two boxes looks elegant. The invoice sees egress charges, replication traffic, backup copies and possibly a second set of data processing tools. Latency also has a cost, especially for UK users outside the M25 who are already sensitive to response times.

Then there is the compliance memory. If data sleeps in two places, you need to know which copy is the record, how deletion works, where backups live and how you would prove it to an auditor or the Information Commissioner's Office if asked. Multi-cloud can improve resilience, but it also multiplies the places where data has to be understood.

Support tiers rarely line up

One provider's premium support is not the same as another's. Response times, severity definitions and escalation routes differ. During a real incident, that difference matters. You may have one account team on a bridge call and another sending a form. You may have two status pages telling two slightly different stories.

Before adding a provider, compare the support contracts side by side and write down how a joint incident would actually be run. Who declares a major incident? Who talks to the business? Which provider leads if both are degraded? A shared severity matrix and a named escalation path are cheap compared with finding out during an outage.

Not every workload needs a second home

The strongest multi-cloud business cases are specific. A payment platform may need a credible alternative if one region fails. A regulated dataset may need a second provider for commercial or jurisdictional reasons. A collaboration tool may not need either. The temptation to run everything everywhere is understandable, but it turns an insurance policy into a full second estate with all the overhead that implies.

Tier your workloads by business impact. Match the resilience pattern to the recovery time and recovery point the business actually needs, not the one that sounds impressive in a workshop. Sometimes multi-region within one provider is the right answer. Sometimes a validated backup and a tested restore is the right answer. Sometimes a second cloud is the right answer. The point is to choose, not to default.

Write the costed exit before you sign

Multi-cloud is often sold as a way to avoid lock-in. That can be true, but only if you maintain a costed exit from each provider. What would it take to leave? Which data would need exporting, in what format? Which workloads would need rebuilding? What notice period applies? Who would do the work, and what would you stop doing to free them up?

A costed exit is not a prediction. It is a control. It tells you whether the second estate is buying real optionality or just adding another dependency to manage. UK teams in regulated sectors should also check how the arrangement fits their operational resilience obligations. The rules may differ by sector, but the question is universal: can you keep the service inside its impact tolerance if one provider leaves the room?

A short checklist for UK buyers

Before adding another provider, put these on one page:

• The failure scenario you are insuring against, in plain English.
• The workloads that will actually run there, and the ones that will not.
• The skills gap, training plan and on-call impact.
• The identity model, including joiners, movers, leavers and break-glass.
• The data flows, egress estimate and deletion evidence.
• The support matrix and joint incident process.
• The costed exit, reviewed on a schedule.

Multi-cloud is not a trick or a status symbol. It is an operating choice with a bill attached. The UK teams that get value from it are the ones that treat the second estate as a second estate: staffed, governed and costed. At WooCloud, we would rather see a smaller, well-run estate than a grand diagram nobody can operate. Everyone else is just paying a premium for a slide.