Hybrid cloud, after Broadcom.

Hybrid cloud has been the dominant enterprise infrastructure pattern for nearly a decade, and VMware sat at the centre of it. The Broadcom acquisition reshaped the economics around hybrid VMware in ways that force every enterprise running a hybrid estate to reconsider the architecture, the destinations, and the commercial structure. This article works through what hybrid cloud looks like in 2026 after the Broadcom transition — what changed, what stayed, and how to design for the new commercial reality.

The bottom line is that hybrid VMware is not over; it is meaningfully smaller in scope and more deliberately structured than it was before. Customers who treat this as a design constraint rather than a problem to be solved end up with architectures that hold up commercially and operationally.

What hybrid cloud meant pre-Broadcom

The pre-Broadcom hybrid cloud playbook for VMware customers rested on three assumptions: that on-premises VMware was the operational baseline, that the same operational model could extend to public cloud through VMware on hyperscaler offerings, and that the licensing economics across the two halves were broadly comparable.

The architecture that emerged was a familiar one: a substantial on-premises VMware estate, an extension into VMware Cloud on AWS or Azure VMware Solution for specific use cases (DR, cloud bursting, data centre evacuation, application modernisation runway), and a separate AWS-native or Azure-native footprint for net-new cloud workloads. The hybrid VMware bit covered the workloads that needed to be portable; the native-cloud bit covered the workloads that were born in the cloud.

The commercial relationships were similarly distributed: on-premises VMware contracts with VMware directly, hyperscaler VMware contracts with either VMware or the hyperscaler (depending on the offering), and hyperscaler-native contracts with AWS, Azure, or GCP for the native-cloud workloads. Three sets of commercial counterparties, three sets of audit clauses, three procurement cycles.

What changed under Broadcom

Several specific shifts in the commercial landscape have reshaped the hybrid VMware architecture.

Unified Broadcom commercial relationship. On-premises VMware and direct-Broadcom hyperscaler offerings (notably VMware Cloud on AWS) now sit under a single Broadcom commercial relationship in many cases. The pitch is operational simplicity; the practical effect is reduced negotiating leverage and a single, large commercial exposure.

Subscription pricing parity. The pricing differential between on-premises VCF and VMware Cloud on AWS has narrowed substantially under the new per-core subscription model. The cost arbitrage that used to make cloud-VMware attractive for specific use cases (especially DR) has compressed.

Audit reach expansion. Broadcom audits now routinely read across on-premises VMware, VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine, and the customer's hyperscaler-native footprint. The audit surface that customers need to manage is larger and more interconnected than it was.

Migration friction reduction. Counter-intuitively, the friction of moving workloads off VMware altogether has decreased relative to the friction of staying on VMware under the new commercial model. Hyperscaler-native tooling has matured; the cost differential against VMware has widened; the strategic momentum has shifted.

The current hybrid cloud architecture

For most enterprises operating a hybrid VMware estate in 2026, the right architecture differs meaningfully from the pre-Broadcom pattern. Several specific design principles apply.

Smaller, harder-negotiated on-premises VMware footprint

The on-premises VMware estate continues to anchor the architecture for workloads where the technical or commercial case for staying is strong. The footprint is typically smaller than it was, with workloads that have weak fit (small VM counts, modernisable applications, light operational integration with VMware) systematically pruned. The remaining estate is harder-negotiated at every renewal, often with substantial outside advisory support on the contract terms.

Targeted, justified cloud-VMware footprint

The cloud-VMware footprint is no longer a default. It is a targeted, use-case-specific deployment for workloads where the cloud-VMware operating model is the right answer: large legacy workloads that cannot economically be re-platformed but need cloud adjacency for specific reasons, DR targets where the cloud-VMware operational continuity is genuinely valuable, and short-term bridging deployments during data centre evacuation projects.

Expanding hyperscaler-native footprint

The fastest-growing slice of most hybrid estates is the hyperscaler-native footprint. Net-new applications, containerised workloads, modern data platforms, and AI/ML workloads are landing on native-cloud services rather than on cloud-VMware. The operational model is different from the VMware-resident estate, but the cost economics and the strategic optionality typically justify the investment in new skills and tooling.

Disciplined commercial separation

Customers who maintain disciplined separation between their commercial relationships — Broadcom for VMware (on-premises and direct cloud), Microsoft or AWS or Google for hyperscaler-native services, and any specialised SaaS vendors separately — tend to negotiate better outcomes than customers who allow Broadcom to bundle everything into a single subscription. The bundling pitch is attractive on simplicity but consistently produces worse total cost over multi-year horizons.

The use cases that justify cloud-VMware

For customers planning their hybrid architecture, it is worth being precise about which use cases still justify a cloud-VMware footprint under the new commercial model.

Large legacy workloads. Mission-critical applications that have been running on VMware for a decade or more, with deep operational tooling and process integration, often cannot economically be re-platformed in any reasonable timeframe. Where these workloads need cloud adjacency — for data integration, for performance reasons, for closing on-premises data centres — cloud-VMware remains a practical destination despite the cost.

DR for in-flight on-premises modernisation. Where the strategic direction is to move workloads off VMware over time but the on-premises VMware estate still needs a credible DR target during the transition, cloud-VMware can be the right interim answer. The interim qualifier is important: the cloud-VMware footprint is sized to retire over a defined period, not to grow.

Specific data sovereignty. Where regional data sovereignty requirements align with the hyperscaler's footprint but not with the customer's on-premises data centres, cloud-VMware can satisfy both the sovereignty and the operational-continuity requirements simultaneously.

Acquisition integration runway. When acquiring companies bring VMware estates that need to be integrated into the acquirer's infrastructure, cloud-VMware can provide a holding pattern that allows the integration to happen in stages without forcing immediate decisions on every workload.

The use cases that no longer justify cloud-VMware

Equally important is identifying the patterns where cloud-VMware no longer makes economic sense:

Net-new cloud-resident applications. Applications being built from scratch should land on hyperscaler-native services. Running them in cloud-VMware preserves a VMware operational model that the application does not need and incurs ongoing Broadcom subscription cost for no architectural benefit.

Short-lived or unpredictable workloads. The per-node and per-core commitment models in cloud-VMware are a poor fit for workloads with variable demand. The pricing structures push customers to commit capacity they may not need, which produces stranded cost.

Workloads that could be modernised at reasonable cost. Where a workload could be re-platformed to native cloud services within a 12-18 month timeframe and a reasonable budget, the right answer is usually to modernise rather than to lift-and-shift into cloud-VMware. The Broadcom subscription cost over a 5-year horizon typically exceeds the modernisation investment.

Small VMware footprints. Customers with fewer than a few dozen VMware hosts often find that cloud-VMware minimum commitments overshoot the actual demand. Consolidating onto a tight on-premises footprint or migrating off VMware altogether typically produces better economics.

Cross-environment management

The single most underappreciated complexity of the post-Broadcom hybrid estate is the cross-environment management discipline required. Three areas in particular deserve attention.

Entitlement reconciliation

Customers running on-premises VMware plus one or more cloud-VMware destinations need a single, authoritative view of entitlement versus deployment across all environments. Without it, the customer cannot defend audits effectively and cannot optimise commercial structures at renewal. The reconciliation is process work supported by tooling, not a one-off project.

Workload placement decisions

The right destination for any given workload depends on factors that change over time: workload demand profile, cloud pricing, on-premises capacity, regulatory constraints. Mature hybrid operators establish a regular workload placement review process that surfaces opportunities to move workloads to the optimal destination as those factors shift.

Cost visibility

Hybrid estates are notoriously hard to cost-attribute. Workloads that span on-premises VMware and cloud-VMware, or that consume cross-environment data transfer at scale, can rack up costs that no single environment owner sees clearly. Customers who treat hybrid cost visibility as a first-class problem — with dedicated FinOps capacity and integrated cost tooling — consistently end up with better economics.

The audit defence for hybrid estates

Audit defence in a hybrid estate is a more complex discipline than audit defence in a pure on-premises estate. Three specific patterns are worth understanding.

Cross-environment exposure aggregation. Broadcom's audit team aggregates entitlement consumption across on-premises and cloud-VMware environments. Customers who do not have a clean cross-environment picture frequently find audit findings that double-count or otherwise inflate the exposure. The fix is documentation: clean records of which workloads ran where, when, and under which entitlement.

Wholesale-versus-direct distinction. AVS and GCVE workloads are covered through wholesale agreements between the hyperscaler and Broadcom. The defence requires articulating clearly that these wholesale-covered workloads should not be counted against the customer's direct Broadcom subscription. This needs contractual support and operational documentation.

Contractual scope limitation. The on-premises Broadcom subscription should have language that limits the audit clause to the customer's directly-licensed environments. Where that language is missing or ambiguous, Broadcom's audit team interprets the clause broadly. Customers negotiating new or renewing contracts should push for explicit scope language even when Broadcom's negotiator resists.

The renewal cycle for hybrid customers

The renewal cycle for hybrid customers is multi-layered and benefits from a structured approach.

The on-premises VMware renewal happens through the direct Broadcom relationship. The cloud-VMware renewals happen through either Broadcom (for VMware Cloud on AWS) or the hyperscaler (for AVS and GCVE). The hyperscaler-native commitments happen through separate cycles with each cloud provider.

Customers who synchronise their renewal cycles — bringing the direct Broadcom renewal, the cloud-VMware renewals, and the related hyperscaler EA renewals into a unified planning cycle — produce better outcomes than customers who treat each renewal as a separate event. The synchronisation is hard work and often requires renegotiating term lengths to align, but the negotiating leverage produced by an integrated approach pays back materially.

What good looks like

The customers we see with the best hybrid cloud economics in 2026 share a few specific characteristics.

They have a workload-by-workload picture of what is running where and why, with documented economic justification for each destination choice. They review the picture regularly — quarterly at minimum — and shift workloads to optimal destinations as economics change.

They maintain disciplined commercial separation between their major vendor relationships. Broadcom is one relationship; each hyperscaler is a separate relationship; bundling is resisted unless it produces clear and demonstrable cost reduction.

They invest in cross-environment management capability — tooling, process, dedicated people. The discipline pays back in lower run-rate cost, better audit posture, and stronger negotiating leverage.

They retain specialist advisory support for the Broadcom-specific contract and audit dynamics. The contract knowledge required to negotiate effectively here is not standard procurement skill, and the customers who recognise that get better outcomes consistently.

What to do now

Map the current state honestly

The first job is to build an accurate picture of the current hybrid estate: workload-by-workload, with destination, entitlement consumption, and rough total cost. Most enterprises have not done this comprehensively for years, and the picture that emerges is usually different from what people thought.

Identify the obvious adjustments

From the current-state picture, the obvious adjustments usually emerge quickly: oversized cloud-VMware reservations to reduce, modernisable workloads to migrate, small or stranded footprints to consolidate, audit-exposure gaps to close. Pursue these in priority order.

Plan the structural changes deliberately

The larger structural shifts — moving workloads off VMware altogether, repatriating cloud-VMware footprints, restructuring contracts — should be planned deliberately with a clear-eyed view of the costs and benefits. Avoid both reactive defence of the status quo and unconsidered radical change.

The strategic bottom line

Hybrid cloud after Broadcom is leaner on cloud-VMware, larger on hyperscaler-native, and more contractually layered than it was before. For customers who design the architecture deliberately and manage the commercial relationships actively, the model still works — with lower run-rate cost, stronger audit posture, and clearer strategic optionality than the pre-Broadcom equivalent.

For customers who treat hybrid cloud as a default architecture and do not actively manage the new commercial reality, the model produces escalating cost, growing audit exposure, and weakening negotiating position over time. The difference is not architectural sophistication; it is discipline and active management.

The customers we see thriving in this environment are not the largest or the most technically advanced. They are the ones who treat hybrid cloud as a strategic capability that needs continuous attention, not as a one-time architecture decision. That posture produces durable advantage in a landscape that continues to evolve.