Multi-cloud, post-Broadcom.

Multi-cloud strategy — the deliberate use of multiple hyperscalers to balance risk, leverage best-of-breed services, and avoid lock-in — has been an enterprise architecture talking point for the better part of a decade. The Broadcom acquisition reshaped the multi-cloud story for VMware customers in ways that deserve fresh analysis. The old multi-cloud narrative, anchored on VMware as the consistent operational layer across hyperscalers, no longer holds in the same way. What replaces it matters for how enterprises think about their cloud architecture in 2026.

This article works through the post-Broadcom multi-cloud picture: where the old narrative broke, what the new shape of multi-cloud looks like, the commercial and audit implications, and how customers should approach multi-cloud decisions now.

The pre-Broadcom multi-cloud story

Before the Broadcom acquisition, the multi-cloud story for VMware customers had a clear logic: VMware Cloud Foundation provided a consistent operational layer across on-premises, VMware Cloud on AWS, Azure VMware Solution, and Google Cloud VMware Engine. Workloads could move between environments using familiar VMware tooling. Operations teams could manage a unified estate with consistent processes. The lock-in risk was distributed across multiple hyperscalers because the customer's primary commercial commitment was to VMware, not to any individual cloud provider.

This story had real strategic value. Customers using it could shift workloads between hyperscalers based on pricing, capacity, or regional availability without retraining operations teams or rebuilding tooling. The vendor leverage was real: AWS, Azure, and Google each knew that the customer could shift workloads to their competitors without significant friction.

How Broadcom changed the picture

The Broadcom commercial transition has weakened several of the foundations on which the pre-Broadcom multi-cloud story rested.

VMware is no longer cheap as the consistent operational layer. The subscription pricing across all VMware destinations — on-premises VCF, VMware Cloud on AWS, AVS, GCVE — has moved up materially. The consistent operational layer is now expensive enough that its strategic value needs to be re-justified against the cost.

Hyperscaler-native services have matured. The capabilities that VMware uniquely offered five years ago are increasingly available natively on each hyperscaler. Container orchestration, virtual networking, software-defined storage, and operational tooling have all evolved to the point where the "consistent VMware layer" is no longer the only way to achieve operational consistency across clouds.

Migration friction off VMware has reduced. The tooling and patterns for moving workloads from VMware to hyperscaler-native have improved. The implicit migration cost that anchored customers to VMware is lower than it was, which weakens the strategic case for staying on VMware as the multi-cloud bridge.

Commercial lock-in has shifted. Under the new commercial model, the customer's primary commitment is increasingly a Broadcom subscription that runs across environments. The bundling pitch from Broadcom is exactly the lock-in risk that pre-Broadcom multi-cloud architecture was designed to avoid.

What multi-cloud looks like now

For most enterprises in 2026, the practical shape of multi-cloud architecture differs from the pre-Broadcom pattern in several specific ways.

Hyperscaler-native is the new consistency layer

For the fastest-growing slice of the enterprise estate — net-new applications, containerised workloads, AI/ML services, modern data platforms — operational consistency is achieved through Kubernetes, through GitOps workflows, through cross-cloud observability platforms, and through standardised CI/CD pipelines. These are layered on top of hyperscaler-native services rather than on VMware.

The operational model is different from the VMware-resident estate. It requires different skills, different tooling, and different processes. But the cost and strategic flexibility benefits typically outweigh the investment in the new operational model.

VMware retained for workloads where the case is strong

The VMware-resident slice of the estate is smaller and more targeted than it was. It includes large legacy workloads where re-platforming is not economically justified, specific use cases where the VMware operational model is genuinely valuable (DR, certain regulatory workloads), and bridging deployments during data centre evacuations.

The VMware footprint that remains is harder-negotiated, more carefully scoped, and reviewed regularly against the alternative of migration. The default assumption is no longer that VMware is the right answer; the default is that the case for VMware needs to be made workload-by-workload.

Multi-cloud is multi-hyperscaler, not multi-VMware-on-hyperscaler

The multi-cloud architecture that produces real strategic optionality in 2026 is multi-hyperscaler at the native level: workloads running on AWS-native, Azure-native, and Google Cloud-native services depending on best fit. The previous shape — workloads running on VMware-on-AWS, VMware-on-Azure, and VMware-on-GCP — preserves VMware operational consistency but does not produce the same strategic benefits and costs more.

The commercial implications

The shift from VMware-as-multi-cloud-bridge to hyperscaler-native-as-multi-cloud-foundation has several commercial implications.

More vendor relationships to manage. A customer running meaningful workloads on AWS-native, Azure-native, and Google Cloud-native services has three separate hyperscaler commitments to negotiate, each with its own EA cycle, its own commitment structure, and its own pricing dynamics. This is more work than negotiating a single VMware subscription, but the negotiating leverage is also greater.

EA bundling becomes the primary lever. Each hyperscaler offers significant discounts for committed-spend EAs. The right strategic posture is to use these EAs as the primary commercial vehicle while retaining flexibility on workload placement within each EA. This requires more sophisticated procurement than the historical VMware-as-everything model.

Broadcom relationship narrows in scope. The Broadcom commercial relationship narrows to cover the retained VMware estate, with cleaner contractual boundaries. The audit clause should not extend to hyperscaler-native workloads (it never did, but the new model makes the boundary clearer). The renewal conversation is smaller in scope and easier to manage.

The audit dimension

The audit posture in a hyperscaler-native multi-cloud architecture is structurally different from the audit posture in a VMware-anchored multi-cloud architecture.

In the VMware-anchored model, Broadcom audits had legitimate reach across all VMware-resident environments — on-premises, VMware Cloud on AWS, AVS, GCVE. The customer's compliance posture had to be defended across all of these venues simultaneously.

In the hyperscaler-native model, Broadcom audits are bounded by the VMware-resident footprint, which is smaller. The hyperscaler-native workloads are not part of the Broadcom audit surface. Each hyperscaler has its own commercial audit posture, but those are typically less aggressive than Broadcom's and easier to manage.

The narrower audit surface is one of the underappreciated benefits of the shift away from VMware-anchored multi-cloud. Customers who actively pursue this shift end up with a meaningfully smaller compliance management burden.

Designing the right multi-cloud posture

For enterprises designing their multi-cloud architecture in 2026, several specific design principles apply.

Start from workload requirements, not from vendor narratives. The right destination for any workload depends on the workload's actual requirements: performance, data gravity, regulatory constraints, integration needs, operational profile. Designing top-down from "we want to be multi-cloud" produces worse outcomes than designing bottom-up from "where does this workload best run."

Accept some workload-platform coupling. The principled position that every workload should be portable across clouds at any time is expensive to maintain and rarely produces the strategic benefits it promises. The pragmatic position is that some workloads are committed to specific platforms and that is fine, as long as the commitment is conscious and the cost is understood.

Invest in cross-cloud observability and FinOps. The single highest-leverage investment in a multi-cloud architecture is in cross-cloud cost visibility and operational observability. Customers who have this layered properly across their hyperscaler estates manage cost and operational risk materially better than customers who do not.

Maintain real workload mobility for the workloads where it matters. For the slice of the estate where workload mobility is genuinely valuable — typically modern applications running on Kubernetes — the architecture should preserve that mobility. For the larger slice where mobility is not a real requirement, the architecture should not pay to preserve an option that will not be used.

The role of VMware in the new picture

VMware does not disappear from the multi-cloud picture, but its role changes. The right shape of VMware in a 2026 multi-cloud architecture has these characteristics:

It is a deliberate, justified part of the architecture for specific workloads — typically large legacy applications, DR for those legacy applications, and bridging deployments. It is not the consistent operational layer across hyperscalers; that role has shifted to hyperscaler-native and Kubernetes.

It is contractually scoped tightly. The Broadcom subscription covers what it needs to cover and no more. The audit clause is bounded. The renewal cycle is managed actively against alternatives.

It is reviewed regularly for fit. Workloads that no longer need to be on VMware are systematically migrated. New workloads default to hyperscaler-native unless there is a specific reason to land them on VMware.

This shape — VMware as a targeted, justified component of a broader multi-cloud architecture — is what we see in the customers achieving the best commercial outcomes.

What to do now

Map your current multi-cloud reality

Build an accurate picture of where your workloads actually run today: on-premises VMware, cloud-VMware, hyperscaler-native by provider. The picture is often different from the architecture diagrams, and the differences are usually instructive.

Identify the workloads that should shift

From the current-state picture, identify the workloads that would benefit from a destination change: VMware workloads that should be modernised, cloud-VMware workloads that should be repatriated or modernised, hyperscaler-native workloads that are on the wrong hyperscaler.

Plan the shifts deliberately

Each destination change has cost, risk, and operational implications. Plan them deliberately, sequence them carefully, and execute them with appropriate change management. The total programme of shifts typically takes 18 to 36 months to execute, depending on portfolio size.

Adjust the commercial structure to match

As the workload distribution shifts, the commercial structure should shift with it. Broadcom renewals should reflect the smaller VMware footprint. Hyperscaler EAs should reflect the growing native footprint. The bundling decisions should be reviewed against the new architecture.

The strategic bottom line

Multi-cloud strategy after Broadcom is hyperscaler-native at the core, with VMware as a targeted component for specific workloads. The pre-Broadcom story — VMware as the consistent operational layer across clouds — has been weakened by the new pricing dynamics and by the maturation of hyperscaler-native alternatives.

For customers who shift deliberately to this new shape, the outcomes are good: lower run-rate cost, stronger strategic optionality, smaller audit surface, more flexible commercial structure. For customers who defend the old story without recognising the changed dynamics, the outcomes are uniformly worse over multi-year horizons.

The decision is not between cloud strategies in the abstract. It is between actively managing the shift to the new shape, or passively accepting the cost and audit consequences of the old shape under the new pricing model. The active path is more work but produces materially better outcomes.