The VMware Renewal Decision: When Azure VMware Solution Fits, and When Native Azure Is the Better Answer

The renewal quote lands on a Tuesday. The number is a multiple of last year's — often 3×, and in the cases quoted to regulators, far more.

Somewhere in the next 30 minutes, someone will say "let's just lift it to Azure VMware Solution." That sentence is a strategy decision wearing a migration task's clothes — and getting it wrong is a multi-year, multi-million-dollar commitment.

The Renewal Quote Is a Forcing Function

For a decade, "what do we do about VMware" was a question you were allowed to not answer. The hardware ran. The team knew every quirk of vCenter by heart.

The perpetual licenses were bought and paid for years ago. Modernization sat in the backlog behind every revenue feature, lost every planning round, and no one was blamed for the delay. That was the arrangement.

Broadcom changed the arrangement. Perpetual licensing has been retired in favour of subscriptions. The product catalog has collapsed into a small set of bundles (VCF and VVF).

The minimum subscription order moved to 72 cores. For a small estate of modest dual-socket hosts, that floor alone can mean licensing more cores than you actually run — before any per-core price change.

This is not a handful of unlucky customers venting:

The exit most teams reach for first — lift it to Azure VMware Solution and sort the licensing out later — has quietly picked up an expiry date of its own, courtesy of Microsoft's 2025–27 AVS licensing changes. That story is a few sections down, and it moves the deadline closer.

Here's the trap. A renewal deadline creates urgency, and urgency collapses a strategy question into a procurement question.

The room stops asking "where should these workloads live for the next seven years" and starts asking "what's the fastest way to not pay this invoice." Those are different questions with different right answers.

Microsoft's Cloud Adoption Framework is unusually blunt about where Azure VMware Solution fits: it's the right choice "when the business value of moving to Azure is clear, and the cost, risk, or time required to redesign applications aren't acceptable." That's the sentence to anchor the whole decision on.

Meridian's platform owner did the thing that feels responsible: she asked her team for a migration plan. Two weeks later she had a Gantt chart for lifting 340 VMs into Azure VMware Solution.

What she didn't have was an answer to the question the board would actually ask — why AVS and not native Azure, and what does this commit us to?

The Wrong Question

"How do we migrate?" is the wrong first question, because it has already chosen the destination. The right first move is to interrogate the destination itself — because lift-and-shift to AVS isn't a neutral parking spot on the way to somewhere better. It's a fork in a roadmap you'll be living with for years.

Say yes to AVS and you've said yes to three things, whether or not anyone spelled them out in the meeting:

• You stay in the VMware business. vSphere, vSAN, NSX — the same stack, the same daily operations, just running on hardware Microsoft racks and patches instead of hardware you bought.
• Your bill is set by the host, not the workload. AVS charges per AVS host, never per VM — so a half-empty cluster costs exactly what a full one does, and every point of consolidation you skip before you migrate is money you keep paying every month afterward.
• Broadcom is still your vendor. You still buy the VCF portable subscription — now straight from Broadcom, not folded into the Azure price. AVS changes who racks the servers; it doesn't end the Broadcom relationship. It splits your VMware estate across two suppliers, each with its own contract and its own renewal clock.

None of this is an argument against AVS. It's an argument for choosing it with your eyes open — with the case for not doing it sitting on the same table.

And "AVS vs. refactor" isn't the whole board either. The full slate is wider: the other hyperscalers' VMware services (AWS, Google Cloud, OCI), re-hypervisoring to Hyper-V or another platform, Nutanix on Azure, or a deliberately smaller on-premises footprint.

Most of those are worse fits for a renewal-clock timeline — but a platform owner who hasn't named them on a slide will get asked why in the board meeting, not before it.

One more thing the Gantt chart won't show you: the portable VCF subscription is bought directly from Broadcom, on Broadcom's terms and timeline.

Through 2025 those quotes were inconsistent — slow to arrive, re-priced, occasionally refused. If your AVS plan depends on a renewal-window cutover, get the licensing commitment in writing before you cancel anything on the old platform.

When AVS Is the Right Call — and When It Isn't

The Cloud Adoption Framework lists five situations that point toward AVS. Treat them as a checklist, not a menu — the more that are true for you, the stronger the case:

The CAF is just as direct about when to send the workloads to native Azure instead. Lean native if:

• You plan to modernize or refactor the applications in the near term anyway.
• The workloads run well on Azure VMs with no VMware dependencies.
• The VMware footprint is small enough to migrate directly to native services.
• Your primary objective is long-term cloud optimization, not VMware continuity.
• Most of the estate is new or could be built cloud-native from the start.

In those cases, the CAF notes, "moving directly to Azure IaaS or PaaS services often provides greater cloud-native benefits and can reduce long-term platform costs." AVS there is an expensive way to postpone a decision you've already made.

When the signals point native, the target is workload-specific, not one-size-fits-all. The common mappings:

For workloads that fit it, native Azure tends to lower long-term infrastructure dependency — consumption pricing, no dedicated-host floor, no separate VCF subscription, and lower exit friction.

The trade is a real operating-model change and per-application migration and remediation effort, which is why a renewal clock rarely leaves room to do it all at once.

The AVS vs Native Azure Decision Matrix

Neither platform is the default. Run each workload group through these questions. The more the answers lean one way, the clearer the call — but the answer still has to be confirmed with workload-level assessment.

This matrix is directional. The final answer needs workload-level assessment, dependency analysis, commercial modelling, and business-owner validation — not a score sheet.

Four Paths, Not One Destination

For most large, heterogeneous VMware estates, the practical answer is a portfolio strategy rather than a single destination. Every workload takes one of four paths:

Assess each workload against: business criticality, technical dependencies, migration complexity, latency needs, licensing, supportability, modernization readiness, remaining application lifespan, security requirements, the migration deadline, and the business owner's appetite for change.

The mix that results — not a single platform — is the strategy.

The Comparison That Makes AVS Look Like a Bad Deal

When the renewal quote is on the screen, one mistake gets made almost every time: someone pulls up the Azure VMware Solution price, sets it next to the price of a plain Azure VM, sees that AVS costs more per unit, and calls it a bad deal.

Wrong thing to compare. AVS isn't going up against a rack of Azure VMs. It's replacing your whole VMware platform — the servers, the vSphere and vSAN and NSX licenses, the datacenter or colo space they sit in, the DR site, and the hours your team spends patching and nursing all of it.

The Cloud Adoption Framework says it in one line: measure AVS against the full cost of the platform you run today.

Line up that whole bill and the picture flips. Per unit of compute, AVS will never beat hardware you've already paid off — it was never going to. The savings are in the lines that disappear: the colo contract, the next hardware refresh, the half-idle DR site, the firmware-and-vCenter babysitting your admins stop doing.

Microsoft's commissioned Forrester study pins roughly 90% of its modelled return on just two of those — skipping the hardware refresh and walking away from the datacenter — plus admin time moved off maintenance.

One more line that's easy to forget: AVS bundles free Extended Security Updates for out-of-support Windows Server and SQL Server. On-premises, you pay for those.

None of these are quotes. Where you land depends on estate size, how densely the hosts run, your reservation term, and how hard your renewal was priced — build the real model in the Azure pricing calculator against your own finance data. Just build it on the right row: the platform you run today versus AVS — not a spreadsheet of Azure VM sizes.

One floor to know before you model: an AVS cluster has a three-host minimum, so the smallest production private cloud is three hosts regardless of how little you're running on it.

Below roughly that footprint, native Azure IaaS is almost always the cheaper answer — which is exactly the CAF's "small VMware footprint" exclusion, expressed as a bill.

Two levers move the AVS number more than anything else, and both are yours to pull:

• Host density. Because you pay per host, a cluster running at 45% utilization is burning roughly half your spend on air. Right-sizing and consolidation before migration is the highest-ROI work in the whole program.
• Reserved instances. A 1- or 3-year reservation on AVS hosts changes the comparison materially against a fresh hardware capital outlay. If the workloads are staying put for three years — and if you're choosing AVS, they are — not reserving is leaving money on the table. Reservations also affect the licensing runway: an active VCF license-included reserved instance keeps its included license until the reservation expires or 30 August 2027, whichever comes first; any new reservation is BYOL from the start.

Questions to Ask Before Sizing a Single AVS Host

These are the questions to put on the table in a discovery workshop — before anyone opens the pricing calculator. If the answers aren't there, the sizing isn't ready.

From Decision to Proposal: How You Get the Numbers

Everything to this point is the argument. What a board actually approves is the argument with a costed proposal stapled to it: host counts, a three-year TCO, a wave plan, and a defensible number for "why not just go native." In Azure, that deliverable comes out of one place — Azure Migrate.

What the assessment actually produces

Azure Migrate does three jobs, and they line up one-to-one with the questions a platform owner has to answer:

The AVS assessment is the output that anchors the proposal. Per workload group it returns a readiness verdict (Ready / Ready with conditions / Not ready), the number of hosts required, and — the useful part — the limiting factor that drives that count: CPU, memory, or storage.

It also bakes in the management overhead for vCenter, NSX, and HCX (roughly 44 vCPU, 75 GB RAM, and 722 GB of storage before dedupe), a fixed tax on the first host that catches people sizing on a spreadsheet.

Host count isn't a fixed readout. A short list of settings moves it — and moves the bill — which is where an experienced assessor earns the engagement fee:

The prerequisites nobody budgets time for

"Run Azure Migrate" sounds like something you do in the last week before the renewal date. It isn't. Performance-based sizing needs a representative sample of real load — one day at the absolute minimum, one to four weeks to trust the confidence rating — and that clock only starts once the plumbing is in place:

• the Azure Migrate appliance deployed as a VMware OVA (one instance scales to roughly 10,000 VMs);
• a read-only vCenter account — and for dependency and software inventory, that account also needs Guest Operations rights plus valid in-guest credentials loaded into the appliance, with VMware Tools running on the guests;
• outbound connectivity from the appliance to Azure.

The shortcut — importing an RVTools export or the CSV template — produces a rough sizing in an afternoon, but with no dependency map, no software inventory, and no performance-confidence rating. It's a way to start the business case, not a substitute for letting the appliance watch real load.

The anatomy of an AVS bill

After the wrong-baseline mistake, the second most common costing error is quoting the host price as the all-in number. It never is. Here's what actually reaches the invoices — and note the two separate names in the "billed by" column:

A 1- or 3-year reserved instance materially reduces the hourly host rate versus pay-as-you-go; model the exact discount for your region and term in the pricing calculator rather than assuming a figure. The current host SKUs (verify against Microsoft Learn before sizing):

Minimum three hosts per cluster (Microsoft recommends four for vSAN maintenance headroom); maximum 16 per cluster. Usable vSAN is well below raw once the failure-tolerance (FTT/RAID) policy is applied. Pull exact rates from the Azure pricing calculator for your region and offer, and a Broadcom quote for the VCF cores.

The subscription trap that stalls programs

The Gen1 vs Gen2 Decision You Make Once

Azure VMware Solution ships in two private-cloud generations. The vSphere, vCenter and NSX experience is broadly consistent, but the difference is more than networking. Gen2 changes the network attachment model, the host SKU, the vSAN storage architecture, and how the private cloud lands in your Azure design.

Microsoft product facts (per Microsoft Learn, checked September 2026 — verify before you design):

Either way, decide early. Microsoft's guidance is blunt: moving between generations requires workload migration. It is not a setting you toggle later — getting it wrong means migrating twice.

The Shared Responsibility Line — and Where It Cuts You

Microsoft operates and maintains the Azure infrastructure and the VMware platform: bare-metal hosts, and the deploy, patch and upgrade of ESXi, vCenter, vSAN and NSX. Microsoft also supports VMware HCX on AVS. That is real operational load lifted off your team.

What stays yours: applications, VMs, operating systems, data, NSX network and firewall configuration, identity and RBAC, security policy, compliance, backup and BCDR tooling (Microsoft's partner ecosystem here includes VMware Live Site Recovery, JetStream, Zerto and others).

And the one that surprises people: monitoring consumption and scaling host capacity to meet demand while balancing performance, resilience and cost.

On Gen2, Azure-native controls such as NSGs against the private cloud also become yours to design.

In an owned datacenter, running out of headroom is a slow, visible problem: someone notices the cluster is full and starts a six-week procurement. In AVS, adding a host is an API call — which is exactly the risk.

A poorly-governed AVS environment scales its own bill. The classic failure mode: a "temporary" capacity add to survive a quarter-end becomes permanent because nobody owns the decision to scale it back down.

The Adoption Sequence

Whatever you land on — AVS, native Azure, or a mix — the path is the same six steps. The first two are decision work, and they fit inside the renewal window. The other four are delivery, measured in months. Do them in order — tick them off as you go.

Taking the Decision to the Board

The board question isn't "did you migrate VMware." It's "what did this commit us to, and for how long."

A platform owner who has done the work walks in with three things:

• a fully-loaded comparison — the platform you run today versus AVS versus native, not a per-VM rate card;
• a one-line answer to "why not just refactor everything" that names the deadline and the workloads that can't move yet;
• and a dated, funded modernization backlog for whatever lands on AVS as a bridge.

Resist the urge to declare a single financial winner.

Which option has the lowest three-year cost depends on migration complexity, VMware and VCF licensing, hardware-refresh timing, datacenter costs, application-remediation effort, dual-running periods, skills, security redesign, reserved capacity and Azure commitments — and those vary by estate.

A more defensible way to present it to the board:

Put the numbers behind each row from your own assessment — not from this table. And build the business case as a full TCO, not AVS host cost versus Azure VM cost:

Azure VMware Solution is a strong answer to a specific question: we must leave this datacenter faster than we can safely re-architect, and enough of the estate has real VMware dependencies that a lift is the lower-risk path. Where that is the question, it is the right tool.

Where it isn't — where the estate is small, or modernization is already funded and scheduled — paying AVS host rates to keep running vSphere is the expensive version of not deciding.

Executive Conclusion

A VMware renewal is a platform-strategy trigger, not a licensing renewal to sign.

Azure VMware Solution earns its place when workload constraints, migration risk and business timing point to it — a hard datacenter-exit date, genuine VMware dependencies, high refactoring risk. It is one landing zone among several, not the automatic answer, and where it is used as a bridge it needs a funded exit.

Native Azure often fits better where modernization is funded, the workload has no real VMware dependency, or the five-year target state is VMware-free — accepting the higher upfront migration and change cost.

Neither vendor's platform is obsolete, and neither is automatically superior. The right answer depends on business constraints and workload characteristics, and it is rarely the same answer for the whole estate.

The goal is not to move VMware somewhere else. It is to make a deliberate platform decision, workload by workload, while balancing deadline, risk, economics and the long-term cloud architecture.

Ready to operationalize your Azure journey?

If a VMware renewal is forcing a datacenter-exit decision and you need the fully-loaded AVS-vs-native comparison, the Gen2 landing zone design, and a modernization backlog the board will sign off on — that's the conversation worth having.