According to Flexera's 2026 State of the Cloud report, 89% of enterprises now use multiple cloud providers. The average organization runs workloads across 2.6 platforms. That number gets cited constantly in slide decks as proof that "multi-cloud is the future."
Here's what the number actually proves: most companies don't have a multi-cloud strategy. They have a multi-cloud situation.
How You End Up Multi-Cloud by Accident
The pattern is always the same. Team A builds their service on AWS because the lead engineer knows AWS. Team B picks Azure because they got a good EA deal and their Microsoft rep threw in credits. Then the company acquires a startup that runs everything on GCP. Someone spins up a data pipeline on Databricks, which has its own cloud preferences. Maybe there's a legacy Oracle Cloud contract nobody wants to touch.
Congratulations - you're now a "multi-cloud enterprise." Except nobody planned this. There's no architecture review that decided which workloads belong where. There's no unified anything. You just have three clouds and a lot of confusion.
I've seen this firsthand in conversations with customers at Citrix. An IT director will tell me they're "multi-cloud" like it's a strategic position. Then I ask a few questions and the picture comes into focus: they have AWS for one division, Azure for another, and they're spending roughly 30% more than they would on either platform alone because of the duplication.
The Real Cost of Unintentional Multi-Cloud
When multi-cloud is a situation rather than a strategy, you pay for it everywhere.
Duplicate tooling. Each cloud has its own monitoring stack, its own deployment pipelines, its own way of doing IAM. Without a deliberate consolidation effort, teams build parallel toolchains. I've seen orgs running CloudWatch, Azure Monitor, and Datadog simultaneously - each covering a different slice of infrastructure, none giving a complete picture.
Inconsistent security posture. Your AWS account structure might be locked down with SCPs and GuardDuty. Your Azure environment might have wide-open RBAC because a different team set it up with different standards. Attackers look for the weakest link. In a situation-driven multi-cloud, there are plenty of weak links.
Networking complexity. Cross-cloud networking is hard enough when you plan for it. When it grows organically, you end up with a tangle of VPN tunnels, peering connections, and transit gateways that nobody fully understands. I've sat in incident reviews where the root cause was "traffic took an unexpected path between AWS and Azure" and nobody could explain why that path existed.
Skills gaps. Your team knows AWS deeply but treats Azure like a black box, or vice versa. Incidents on the less-understood platform take longer to resolve because fewer people can debug them. Hiring gets harder too - you need engineers fluent in multiple ecosystems, and those people are expensive.
What Intentional Multi-Cloud Looks Like
At Citrix, we run DaaS workloads across multiple clouds deliberately. There are specific reasons for each placement decision: customer proximity requirements, pricing arbitrage between regions, and resilience against single-provider outages. That's a strategy.
The difference is visible in the details. We have unified deployment tooling that works across providers. Monitoring is consolidated - same dashboards, same alerting rules, same escalation paths regardless of where the workload runs. Teams are cross-trained on both platforms. When we add a new region or shift capacity between clouds, there's a workload placement framework that governs the decision.
An actual multi-cloud strategy requires a few things that most "multi-cloud" organizations are missing:
A workload placement framework. Every workload has a home, and there's a documented reason it lives there. "The engineer who built it preferred AWS" is not a reason. Latency requirements, data residency, cost modeling, service availability - those are reasons. The framework should also specify criteria for when a workload should move.
Unified IAM and security baseline. One set of security standards that applies everywhere, implemented through whatever each cloud's native tooling provides. Not three separate security teams doing three separate things.
Cross-cloud networking that isn't held together with duct tape. A real network architecture with documented traffic flows, consistent IP addressing schemes, and failover paths that someone has actually tested. Ideally managed through infrastructure-as-code so the topology is reviewable and reproducible.
A single observability plane. You need to see all your infrastructure in one place. Logs, metrics, traces - all of it, from every provider, queryable from a single tool. This is table stakes. Without it, you're flying partially blind at all times.
Cross-provider cost allocation. Your finance team needs to understand spend by team, by product, by workload - not by cloud provider. If your cost reporting is "here's the AWS bill and here's the Azure bill," you can't make intelligent placement decisions.
Where Kubernetes Fits (and Doesn't)
Every multi-cloud conversation eventually lands on Kubernetes. "Just run K8s everywhere and your workloads are portable." There's truth in that - Kubernetes does give you a consistent compute abstraction across providers. If your workloads are containerized and stateless, you can move them between clouds with relatively low friction.
But Kubernetes doesn't solve data gravity. Your 50TB Postgres database on AWS RDS isn't moving to Azure just because your application containers can. It doesn't solve provider-specific managed services - if you're using DynamoDB or Cosmos DB, you're locked in regardless of what your compute layer looks like. And it doesn't solve networking. Cross-cloud service mesh is possible but painful, and adds latency that matters for real-time workloads like virtual desktop delivery.
Kubernetes is a useful piece of the puzzle. It's not the whole puzzle.
The TPM's Role
This is an area where the TPM function matters a lot. The drift from strategy to situation happens slowly, one expedient decision at a time. Nobody sets out to create a mess. Each individual choice makes sense in isolation - this team needs to ship fast, that team got a good deal on credits, this acquisition came with its own infrastructure.
The TPM's job is building and maintaining the governance layer. Running cross-cloud architecture reviews so that new workload placements are intentional. Maintaining the workload placement framework and making sure teams actually use it. Tracking when reality drifts from the plan and raising it before the drift becomes permanent.
It's not glamorous work. Nobody writes blog posts about governance frameworks (well, I guess I just did). But without it, every multi-cloud strategy eventually degrades back into a multi-cloud situation. The entropy is constant. You have to actively push against it.
If your organization is already in the "situation" camp, that's fine. Most are. The first step is just being honest about it. Stop calling it a strategy until you've built the infrastructure - both technical and organizational - to make it one.