VMware Migration: We Moved 50+ Estates Off Broadcom (2026)

Two years after Broadcom closed the VMware deal, almost every enterprise we work with is either mid-migration or planning one. The price hikes (3-5x for most customers we’ve seen, 8-10x at the top end), the forced VCF bundling, and the partnership shakeups have made staying on VMware a board-level conversation rather than an IT one.

We’ve moved more than 50 VMware estates off Broadcom in the last 18 months - some to AWS, some to Azure, a few to a mix. This post is what we’d tell a VP of Infrastructure on day one of the project, before they sign anything.

Why this is happening now

A quick recap, because the situation has shifted three times since 2023 and people we talk to are still working off old assumptions:

November 2023: Broadcom closes the VMware acquisition
Early 2024: Perpetual licenses discontinued. Everything moves to subscription (VMware Cloud Foundation, or VCF). Most customers see renewal quotes 3-5x higher than what they were paying
April 2024: AWS and Broadcom end the VMware Cloud on AWS partnership. AWS stops selling new VMC instances; Broadcom takes the customer relationship
Mid-2024: Microsoft positions Azure VMware Solution (AVS) as the soft landing for VMC customers
Mid-2025: AWS launches Amazon Elastic VMware Service (EVS) - a new way to run Broadcom-licensed VMware on AWS, bring-your-own-license
2026: Most enterprises are 12-24 months into their renewal cycle and are now executing migrations, not just planning them

The Broadcom strategy is clear: monetize the existing base aggressively, lose the customers who won’t pay, keep the ones who can’t leave. If you’re reading this, you’re probably in the first group, or trying to figure out which group you’re in.

The four real paths off VMware

Before tooling, before HCX, before anyone talks about lift-and-shift vs replatform, you have to pick a path. There are four that we actually see succeed:

Path	What it is	Best when
Azure VMware Solution (AVS)	Microsoft-managed VMware (vSphere, vSAN, NSX) running on Azure bare metal	You need vSphere compatibility, large estate, short timeline
Amazon Elastic VMware Service (EVS)	AWS-managed VMware running on EC2 bare metal hosts, BYOL	You want AWS but need vSphere short-term as a bridge
Native AWS modernization	Apps move to EC2, EKS, RDS, etc. - no VMware layer	You want the long-term cost benefit, can refactor, multi-year project OK
Native Azure modernization	Apps move to Azure VMs, AKS, Azure SQL, etc.	Same as native AWS, but you’re already Azure-heavy elsewhere

The trap most teams fall into is thinking these are mutually exclusive. They are not. The pattern that works for mid-to-large estates is usually:

Lift-and-shift to AVS or EVS first (buys you out of Broadcom, fast)
Modernize on the cloud platform you landed on, app-by-app, over 18-36 months

This two-phase approach takes the renewal pressure off without forcing a multi-year refactor under deadline. It also means your first cloud bill is higher than it would be if you went native immediately - that’s the trade you’re making.

For the wider replatform vs rehost decision, our 6Rs cloud migration framework covers when each one makes sense.

How to actually pick your path

A decision flow that’s worked for us across dozens of engagements:

Question 1: How fast do you need out?

Renewal in under 6 months and quoted painful numbers: lift-and-shift to AVS or EVS, then modernize
Renewal in 12+ months: you can consider going straight to native

Question 2: Where’s your existing cloud spend?

Already significant AWS: lean EVS or native AWS
Already significant Azure: lean AVS or native Azure
Neither: pick based on workload fit, not vendor preference. Microsoft’s Windows Server licensing benefits give Azure a real edge for Windows-heavy estates

Question 3: How vSphere-coupled are your operations?

Deeply (custom vCenter automation, NSX-T policies, vSAN-specific storage): AVS or EVS, don’t try to go native day one
Lightly: native cloud is on the table

Question 4: What’s the workload mix?

Mostly Windows + SQL Server + Active Directory: Azure usually wins on TCO
Mostly Linux + containers + data: AWS usually wins
Mixed: it’s a coin flip; pick by team skills

If you’re trying to decide AWS vs Azure more broadly, our AWS to Azure migration guide has the same decision framework applied in reverse.

Path A: Lift-and-shift to AVS or EVS

This is the fastest path off Broadcom for a large estate. You’re not changing your operating model - you’re moving the same VMs, with the same vSphere management, to a different physical location.

What you keep

vSphere, vCenter, vSAN, NSX-T - the whole familiar stack
Existing VM templates, snapshots, tags
VMware HCX for cross-cluster mobility
Most of your runbooks and automation
vRealize / Aria tooling (if you’ve licensed it)

What changes

The hardware is in AWS or Azure data centers, billed by the hour
Your VMware licenses come from Broadcom (BYOL) for EVS, or are bundled by Microsoft for AVS
Networking integrates with native cloud VPCs (so you can talk to S3, RDS, native Azure services)
Storage is no longer your problem - vSAN runs on the underlying hosts

The actual migration

VMware HCX is the tool. It does:

vMotion across the WAN (warm migration)
Bulk migration (cold, faster)
Replication-based migration (RAV)

We typically run HCX in production for 3-6 months during the migration, doing waves of 20-100 VMs at a time. Things that bite people:

Network policy migration is manual. NSX-T policies don’t fully auto-translate. Plan for an engineer to re-implement DFW rules.
IP retention vs re-IP. HCX can do Layer 2 extension so VMs keep their IPs. This works, but the long-running L2 stretch is fragile and expensive. Re-IP if you can. Plan DNS updates in advance.
Licensing math. With AVS, Microsoft includes the VMware licenses. With EVS, you bring your own from Broadcom - which is the whole problem you’re trying to solve, just in a different rack. EVS only makes sense as a short-term bridge.
Backup tools. Your existing Veeam or Rubrik will mostly work on AVS / EVS, but the integration paths differ. Test before cutover.

When AVS makes more sense than EVS

You want to stop paying Broadcom directly (Microsoft handles the licensing)
Your renewal is imminent
You’re Azure-curious or already Azure-heavy
You want a longer runway (3-5 years) on vSphere before modernizing

When EVS makes more sense than AVS

You’re committed to AWS as the long-term home
You want to start using native AWS services (S3, RDS, EKS) alongside the VMware estate from day one
You’re willing to keep paying Broadcom for now as a bridge

EVS is genuinely useful as a step on the way to native AWS. It’s expensive to live on long-term. Treat it as a 12-24 month hotel, not a home.

Path B: Native cloud modernization

This is where the real cost savings live. It’s also where the real engineering work happens. We see this path succeed when:

The board has bought into a 2-3 year transformation, not a 6-month exit
There’s an internal platform team (or you’re hiring one) that can absorb the new operating model
The application teams have product owners who can prioritize the work

If you’re picking AWS as your native target, the building blocks are the same ones you’d use for any modernization: EC2 for VMs that can’t refactor yet, EKS for containerized workloads, RDS for databases, S3 for storage, and ALB or NLB for ingress. Our EKS migration playbook covers the Kubernetes piece in detail. EKS architecture best practices covers the cluster design.

For Azure-native, AKS plays the EKS role, Azure SQL plays the RDS role, and Azure Blob Storage plays the S3 role. The migration patterns are very similar.

Application migration patterns we use

For each application, you’ll end up doing one of these:

Pattern	What it looks like	When
Rehost (Lift and shift)	VMs become EC2 / Azure VMs, same OS, same config	Legacy apps you can’t refactor, vendor-supplied software
Replatform	Same app, but database moves to RDS / Azure SQL, queues to SQS / Service Bus	Apps where small changes unlock big operational wins
Refactor	Containerized, deployed to EKS / AKS, broken into services if needed	Apps under active development with a team that owns them
Repurchase	Replace with a SaaS equivalent	Generic apps (email, CRM, ticketing)
Retire	Turn it off	More common than you’d think - audit before migrating

We’ve never seen a migration where every app fits into one bucket. Plan for a mix.

The migration tools that actually work

AWS Application Migration Service (MGN) for rehost to AWS. The successor to CloudEndure. Free for the first 90 days per source server, then per-hour billing.
Azure Migrate for rehost to Azure. Free at the migration tier; you pay for Azure resources.
AWS Database Migration Service (DMS) for moving databases with minimal downtime
Azure Database Migration Service for the Azure equivalent
HCX if you’re transiting through AVS or EVS as a step

We’ve seen teams try to write their own migration tooling. Don’t. The vendor tools are good enough, and the time you save is worth more than the rounding error in the bill.

The hard parts (regardless of path)

These are the things that turn a 6-month project into a 12-month one. Plan for them.

Storage migration

vSAN does not exist outside VMware. When you go native, vSAN-backed volumes need to move to EBS (AWS) or Azure Managed Disks. The migration is straightforward for boot volumes. It’s painful for:

Large data volumes (>1 TB per VM). Network transfer is the bottleneck. Consider AWS Snowball / Azure Data Box for the initial bulk move, then catch up with replication.
Volumes with snapshot history that matters. vSAN snapshots don’t translate. If you need point-in-time recovery, set up cloud-native backups before the cutover.
Shared storage. NFS shares move to EFS (AWS) or Azure Files. SMB shares move to FSx for Windows (AWS) or Azure Files. Test the performance characteristics - they’re not identical.

Networking and NSX-T

NSX-T policies are the single biggest reason teams stall. If your security model lives in NSX distributed firewalls, you have to rebuild it on the target. Options:

AWS: Security groups + Network Firewall + sometimes a third-party firewall (Palo Alto, Fortinet)
Azure: NSGs + Azure Firewall + same third-party options
Both: Cilium with network policies if you’re going containerized

For East-West traffic micro-segmentation, the cloud-native answers (security groups, NSGs) are coarser than NSX. Plan for an additional tool if your compliance posture requires fine-grained policies.

Active Directory, DNS, DHCP

Don’t underestimate this. Your AD domain has been comfortable inside VMware for a decade. Moving it requires:

AD Connector or domain controller VMs in the cloud
DNS forwarding between on-prem (if any remains), cloud, and the migrating estate
DHCP scope migration if you weren’t using DHCP reservations religiously

We’ve seen migrations where the AD piece took 4 weeks longer than planned because nobody owned it. Assign an owner on day one.

Backup, DR, and compliance

Your VMware backups (Veeam, Rubrik, Commvault) mostly work on AVS / EVS. They need re-architecting for native cloud.
DR plans that assumed two VMware sites need rewriting around cloud regions / availability zones.
Compliance evidence (PCI, HIPAA, SOC 2) needs re-collection on the new platform. Your auditors will ask.
If you’re regulated, talk to your auditors before you migrate, not after. We’ve seen teams have to redo work because the SoC of evidence wasn’t documented.

For broader migration risk planning, common cloud migration challenges covers the patterns we see across industries.

The cost reality

Other guides will give you a TCO calculator and hand-wave. Here’s what we actually see in invoices.

Where the savings come from (vs. Broadcom)

License compression. You stop paying VCF subscription. That’s typically the single biggest line.
Hardware refresh avoided. You don’t buy the next generation of hosts.
Operations. Smaller VMware team needed (or repurposed). This is real money over 3-5 years.
Right-sizing. On-prem you over-provision because adding capacity is slow. In cloud you can fit-to-use.

Where the costs surprise people

AVS and EVS are not cheap. Pricing is per-host, billed by the hour. A small AVS / EVS estate can cost more than the equivalent on-prem hardware once you include hosts, networking, and egress. The economic case is in escaping Broadcom, not in saving money on the lift-and-shift step itself.
Native cloud costs more for “rehost” than people expect. A VM that ran 24/7 on owned hardware now runs 24/7 on metered hardware. Until you refactor to autoscale or replace with managed services, you’re not saving much.
Egress. Anything pulling data out of cloud (downloads, third-party integrations, hybrid sync) bills at $0.05-0.09/GB. Add it up.
Premium support. Enterprise support tiers on AWS or Azure are typically 3-10% of monthly spend. Budget for it.
Training and contractors. The first migration costs a lot in expertise you don’t have yet. The second one costs less.

A reasonable rule of thumb from what we’ve seen: lift-and-shift to AVS or EVS lands at 80-110% of your post-Broadcom on-prem cost. Native modernization, done well, lands at 40-70% of that baseline. But it takes 18-36 months to get there.

If you want directional numbers for your specific estate, try our VMware migration cost calculator - it compares 3-year TCO across Broadcom renewal, AVS, EVS, and native cloud paths.

For a more detailed cost framework, our cloud migration tools post covers the assessment and TCO tooling we use.

Timeline expectations

Real numbers from real engagements:

Estate size	Path	Realistic timeline
<200 VMs	AVS or EVS lift-and-shift	3-5 months
<200 VMs	Native modernization	9-15 months
500-1,000 VMs	AVS or EVS lift-and-shift	6-10 months
500-1,000 VMs	Native modernization	18-30 months
2,000+ VMs	Two-phase (lift then modernize)	24-48 months total

If a vendor or system integrator tells you they can move 1,000 VMs to native AWS in 6 months, they’re either selling lift-and-shift dressed up as something else, or they’re going to miss.

The variable that swings these timelines the most isn’t the technology - it’s how many application teams need to be involved, and how aligned leadership is on the destination.

Pre-migration checklist

Things to confirm before you commit:

VMware estate inventory. VMs, vCPU, RAM, storage, network policies, dependencies. RVTools is fine to start.
Broadcom renewal date and quote. This sets your deadline. Negotiate it down where you can; it buys you planning time.
Target landing zone designed. VPCs, subnets, identity model, observability stack. Enterprise migration checklist covers the wider planning.
Application dependency map. App A talks to DB B which talks to message queue C. Without this, you’ll move in the wrong order and break things.
Identity strategy. AD on-prem, AD Connector, Entra ID, IAM Identity Center - pick the topology before migration starts.
Network connectivity in place. Direct Connect (AWS) or ExpressRoute (Azure) provisioned and tested before the first VM moves.
Cutover and rollback patterns agreed. Per-wave runbooks, written down, rehearsed.
Compliance team briefed. They will ask for evidence at the worst possible moment.
Communication plan. Who’s on the cutover call. Who approves go/no-go. Who talks to the business.

Common pitfalls

The mistakes we see repeatedly:

Assuming AVS or EVS is cheap. They’re not. They’re an escape pod, not a destination.
Skipping the dependency map. “We’ll figure it out as we migrate” turns into mystery outages.
Trying to rebuild on-prem in the cloud. If you’re going native, accept that the operating model changes. Don’t fight it.
Underestimating identity. AD migration is always longer than the project plan says.
Ignoring egress costs. Especially when hybrid traffic patterns persist post-migration.
Picking AWS or Azure by vendor preference, not workload fit. Windows-heavy estates often run cheaper on Azure. Containerized estates often run cheaper on AWS. Don’t let RFP politics decide.
Doing a “VMware refresh in the cloud” without a refactor plan. You moved out of Broadcom. You’re now paying AWS or Microsoft hourly for VMs that look exactly like they did before. The savings come from what you do after migration.
No internal owner for the migration. A vendor or partner can run the project, but someone on your team has to own the outcome. Migrations without an internal owner stall.

FAQ

Is VMware Cloud on AWS still available?

Not for new customers. AWS stopped selling VMC in 2024 after the Broadcom partnership ended. Existing customers transitioned to Broadcom direct. AWS launched Amazon Elastic VMware Service (EVS) in 2025 as the replacement, but EVS is bring-your-own-license, so you’re still paying Broadcom for the VMware part.

What is the cheapest way to leave VMware?

In pure dollar terms, native cloud modernization wins over 3-5 years. In time-to-exit terms, AVS or EVS lift-and-shift is fastest. The cheapest path you can actually execute is usually a phased approach: lift-and-shift first, modernize over time.

Should I migrate to AWS or Azure?

It depends on your existing footprint, workload mix, and team skills. Windows + SQL Server + AD-heavy estates usually run cheaper on Azure due to licensing benefits. Linux + containers + data-heavy estates usually run cheaper on AWS. If you’re already significant on one cloud, the answer is usually “the one you’re already on”.

How long does VMware to cloud migration take?

For a mid-sized estate (500-1,000 VMs), plan 6-10 months for lift-and-shift, 18-30 months for native modernization, or 24-48 months for a phased two-step. Smaller estates compress these timelines; larger ones extend them.

What’s the alternative to Broadcom VMware?

For VMware-compatible: Azure VMware Solution, Amazon EVS, Google Cloud VMware Engine (smaller market), Nutanix (different hypervisor but similar operating model). For non-VMware-compatible: native cloud (AWS, Azure, GCP), OpenShift, or Proxmox for self-hosted.

Can I move VMware to Google Cloud?

Yes. Google Cloud VMware Engine exists and works similarly to AVS. It has a smaller customer base than AVS or EVS, and the partner ecosystem is thinner. If you’re already on Google Cloud meaningfully, it’s worth evaluating. If not, the path of least resistance is AVS or EVS.

What happens to my VMware licenses if I migrate?

Depends on what you bought. Perpetual licenses (pre-Broadcom) are still valid for what they cover but cannot be expanded or renewed. Subscription licenses (VCF) transfer to the new environment if Broadcom allows it for your contract type. Read your contract before assuming anything.

Do I need to refactor my apps to leave VMware?

No. Lift-and-shift to AVS or EVS keeps your apps unchanged. Native cloud rehost keeps the OS and app unchanged but changes the underlying VM platform. Refactoring is a choice you make for long-term cost and operational benefits, not a requirement for leaving VMware.

Ready to plan your VMware exit?

Leaving Broadcom is a board-level project for most enterprises now, and the right path depends on your renewal timeline, workload mix, and operating model. The teams that succeed pick a path that buys them out of the renewal first and modernize on a schedule that suits the business, not the vendor.

Our team provides hands-on cloud migration services to help you:

Plan the right path off VMware based on your estate, renewal timeline, and target cloud
Execute the lift-and-shift to AVS or EVS with HCX, network re-architecture, and wave-based cutovers
Modernize on AWS or Azure with EKS / AKS, managed databases, and cloud-native operations
Manage the long tail - identity, DR, compliance, FinOps, and the apps nobody owns

We’ve moved more than 50 VMware estates off Broadcom across UK, EMEA, and the Middle East. We know which problems hit you at week two and which ones don’t show up until month nine.

Talk to our cloud migration team →