Cloud Repatriation from VMware: The 2026 Guide

Through the second half of the 2010s and the early 2020s, a meaningful share of enterprise VMware estates migrated from on-premises data centres to VMware Cloud on AWS, to Azure VMware Solution, or to Google Cloud VMware Engine. The proposition was attractive: VMware compatibility, hyperscaler operational backing, no hardware refresh, and a clean migration path for workloads that were not yet ready for cloud-native rehoming.

In 2026, the proposition has changed. The combination of Broadcom-era VMware pricing, hyperscaler infrastructure pricing, and the diminished commercial flexibility of these hosted offerings has produced a category of workloads where the customer is paying premium VMware licensing on top of premium cloud infrastructure — with limited ability to negotiate either line. For a meaningful and growing subset of customers, the right answer is repatriation: moving workloads back to on-premises infrastructure (with or without VMware), or moving them forward to native cloud, but not leaving them on the hosted-VMware platforms.

What "repatriation" actually means in 2026

The term "repatriation" was originally used to describe workloads moving from public cloud back to on-premises infrastructure, typically for cost or sovereignty reasons. In the VMware context in 2026, the term has a more specific meaning: moving workloads off VMware Cloud on AWS (VMC on AWS), Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), or similar hosted-VMware offerings, to a destination that is not also hosted-VMware.

The destinations break into three categories. On-premises VMware — moving the workload back to the customer's own data centre on either continued VMware or one of the VMware alternatives. Native cloud — moving the workload to AWS EC2, Azure VMs, Google Compute Engine, or the equivalent serverless or managed offerings, eliminating the VMware abstraction. Alternative on-premises platforms — moving the workload to on-premises Nutanix, Proxmox, Hyper-V, or OpenShift Virtualization rather than to continued VMware.

Why repatriation is a 2026 conversation

The hosted-VMware platforms made commercial sense for many customers in 2019-2022. Three things have shifted that calculation in 2024-2026.

Broadcom-era VMware pricing

The VMware licensing pricing in the hosted-VMware offerings has moved with the same Broadcom-era pricing dynamics that have affected on-premises customers. The headline pricing of VMC on AWS, AVS, and GCVE reflects substantial per-host cost increases compared with the pre-acquisition era. The discount structures available to customers committing to multi-year terms have shifted; the partner-margin dynamics that produced competitive pricing have largely been removed.

Hyperscaler infrastructure pricing

The underlying hyperscaler infrastructure on which these offerings run continues to be priced at the hyperscaler's discretion. AWS, Azure, and Google Cloud have not generally repriced these offerings in customers' favour during the post-Broadcom period. The combined effect — premium VMware licensing on top of premium hyperscaler infrastructure — produces total cost figures that are often substantially higher than the equivalent workloads running on on-premises VMware or on native cloud.

Native-cloud alternatives have matured

The native-cloud alternatives — AWS-native services with appropriate migration tooling, Azure-native services similarly, Google-native equivalents — have continued to mature. The cost differential between hosted-VMware and native-cloud equivalents has widened in favour of native cloud for the workload profiles where native cloud is operationally appropriate.

The repatriation decision framework

The decision to repatriate is not a single decision; it is a per-workload analysis that produces a portfolio answer. Three dimensions matter most.

Cost profile

The first dimension is the workload's cost profile across the candidate destinations. The cost on hosted-VMware is the baseline. The cost on on-premises VMware (if the customer has the infrastructure), on on-premises alternative platform (if applicable), and on native cloud all need to be modelled. The comparison should include not just the run-rate cost but the migration cost amortised over a reasonable horizon — typically five years.

In our engagement data, repatriation to on-premises typically produces 40-70% run-rate cost reductions for workloads running on hosted-VMware. Repatriation to native cloud typically produces 30-60% reductions for workloads with appropriate consumption profiles (variable, bursty, or seasonally heavy). The cost saving on hosted-VMware exit is among the highest of any infrastructure optimisation in 2026.

Operational fit

The second dimension is whether the destination is operationally appropriate. Workloads that depend on VMware-specific features (advanced networking, specific DR configurations, ecosystem-tool integrations) repatriate more cleanly to a VMware destination than to a non-VMware destination. Workloads that have been operating on hosted-VMware specifically because the on-premises operations team could not support them may face operational gaps if they return to on-premises without addressing the underlying staffing or capability issue.

Strategic direction

The third dimension is the customer's broader infrastructure strategy. Customers building a private-cloud capability may find repatriation a natural fit with that strategy. Customers committed to a cloud-native long-term direction may find direct rehoming to native cloud a better step than repatriation to on-premises that will need to be redone later. Customers with regulatory or sovereignty considerations may find specific destinations preferred for reasons beyond cost.

Per-workload classification

The classification work for repatriation is similar to other migration classifications but with the hosted-VMware specifics added.

Standard workloads — typical Linux and Windows VMs running standard applications — generally repatriate cleanly to any destination. The cost picture favours the cheapest destination consistent with operational fit.

Workloads with hyperscaler-specific integrations — workloads using AWS or Azure native services through their hosted-VMware environment — may be tightly coupled to the hyperscaler region. Repatriation to a different hyperscaler is more disruptive than expected; repatriation to on-premises means re-architecting the hyperscaler-service integration. The disposition depends on the integration depth.

Workloads with VMware-specific deep features — heavy NSX-T usage, specific HA configurations, advanced vSphere features — repatriate most cleanly to VMware destinations. Repatriation to non-VMware destinations may require additional re-engineering work.

Workloads with very high RPO/RTO requirements typically benefit from repatriation to environments with mature DR tooling, whether that's on-premises or appropriately-configured native cloud. The hosted-VMware DR story is functional but not always optimal.

The migration tooling reality

Repatriation from hosted-VMware platforms uses several specific tools.

VMware-native tools

HCX (VMware Hybrid Cloud Extension) handles workload migration between VMware environments — including hosted-VMware-to-on-premises-VMware and the reverse — with live migration capabilities, network reconfiguration, and minimal cutover downtime. The tooling is mature and is the natural choice for VMware-to-VMware repatriation.

Hyperscaler-native tools

AWS Application Migration Service (formerly CloudEndure), Azure Migrate, and Google's Migrate for Compute Engine all provide migration tooling for workloads moving from hosted-VMware to the native cloud services on the same hyperscaler. The integration is generally good for the hyperscaler's own platform; cross-hyperscaler migration is more involved.

Third-party tools

Veeam, Carbonite, and several specialised migration vendors provide repatriation-focused tooling that works across destinations. The flexibility is useful for customers running multi-destination repatriation strategies.

Commercial considerations: the hosted-VMware contract

The hosted-VMware contract structure typically includes specific provisions that affect repatriation economics.

Multi-year commitments. Most hosted-VMware contracts are structured as multi-year commitments with substantial upfront pricing benefits and corresponding exit provisions. Customers part-way through a multi-year commitment face the choice between (a) continuing through the commitment, (b) repatriating but continuing to pay the committed cost, or (c) negotiating an exit with the provider. Each path has different economics; the choice depends on remaining commitment value and the destination's economics.

Reserved-instance and committed-use discounts. Hyperscaler infrastructure discounts attached to hosted-VMware commitments may have their own commercial implications on exit. The combined commercial picture should be modelled, not just the headline VMware-licensing component.

Data-egress charges. Moving substantial workload data out of a hyperscaler region attracts data-egress charges. For repatriation to a different hyperscaler region or to on-premises, egress can be a significant cost line. The egress cost is one-time but real and should be budgeted explicitly.

Sequencing the repatriation

Repatriation projects follow a recognisable pattern.

Phase one: portfolio analysis. Inventory the hosted-VMware estate, classify workloads by repatriation suitability and destination, model the cost across candidate destinations, and identify the workloads that repatriate first (typically those with highest cost saving and lowest migration risk).

Phase two: destination preparation. Prepare the destination infrastructure — on-premises capacity, native-cloud accounts and services, or alternative-platform deployment. For customers without existing on-premises capacity, the destination preparation can be a substantial phase in its own right.

Phase three: wave-based migration. Repatriate workloads in waves, with the first wave focused on highest-value, lowest-risk workloads. Validate the operational model, the ecosystem integration, and the cost-saving realisation on the first wave before scaling.

Phase four: contractual exit. As the hosted-VMware footprint reduces, negotiate the exit from the hosted-VMware contract. The exit timing should be aligned with the contractual commitment structure to minimise residual cost.

When repatriation is not the right answer

Repatriation is not always the right answer, even for customers on hosted-VMware platforms.

Customers without on-premises infrastructure and without the operational capability to build it. Building on-premises infrastructure specifically to repatriate is a substantial undertaking; for customers without existing on-premises capability, native-cloud rehoming is often the better option than repatriation.

Customers with workloads that genuinely benefit from the hosted-VMware integration. Some workloads use the hyperscaler integration deeply — particularly for analytics, AI/ML, or other services that are difficult to replicate elsewhere. For these workloads, the cost premium may be justified by the integration value.

Customers near the end of multi-year commitments where the residual cost is small. Customers with six months left on a hosted-VMware commitment may find it more cost-effective to ride out the commitment and decide at renewal than to repatriate during the commitment.

Customers in active expansion mode where the hosted-VMware platform provides growth capacity that on-premises does not. The strategic context can override pure cost optimisation in specific cases.

Related reading

For the broader alternatives picture, see VMware alternatives 2026. For specific hosted-VMware contexts, see VMware Cloud on AWS licensing, Azure VMware Solution licensing, and Google Cloud VMware Engine. For the broader hybrid-cloud context, see hybrid cloud after Broadcom. For licensing context, see VMware licensing after Broadcom.