The VMware Reset: How ModernZ Turns a Broadcom Renewal Into a Self-Funding AWS Migration

This post is co-written with Narayan Bharadwaj and Ashish Aggarwal from ModernZ

Two events make 2026 the year VMware customers cannot put infrastructure decisions off any longer. First, the three-year renewal wave following the Broadcom acquisition is landing now across thousands of enterprise accounts. Second, Broadcom has confirmed publicly that vSphere 8 reaches End of General Support on October 11, 2027 — a hard 13-month deadline for every vSphere 8 customer. For the roughly 300,000 organizations globally that built their infrastructure on VMware[IDC], the renewal conversation now has to answer a bigger question than it did a year ago: what comes next?

For AWS Partners, this is one of the most significant customer-engagement opportunities of the decade. Two cloud platforms on AWS are well suited to the conversation, and customers should choose between them based on their goals. Amazon Elastic VMware Service (Amazon EVS) — the strategic AWS first-party service for running VMware Cloud Foundation on AWS — lets customers preserve their existing VMware operational model inside their Amazon VPC, with a choice of customer self-managed or Partner Managed operations. Cloud-native Amazon EC2 gives customers the full benefit of AWS services and managed offerings, with the flexibility to modernize each workload to its best-fit destination. Many engagements ultimately combine both: EVS as a fast datacenter exit, EC2 as the modernization target.

This post lays out what AWS Partners need to know about the VMware cost landscape today, where legacy assessment tools need additional context to be fully accurate, and how to position the EVS and EC2 platform choices based on customer goals.

Understanding What Has Changed

Most VMware customers are aware of the broad narrative. Broadcom acquired VMware in late 2023, consolidated the product line into VMware Cloud Foundation (VCF), and moved to a per-Core subscription model with a minimum licensing requirement of 16 Cores per Processor[Broadcom]. What many have not yet fully modeled is how that consolidation translates into the renewal invoice — and how differently it affects different customer segments.

In practice, most VMware deployments run vSphere, often with Aria Operations alongside it, while vSAN, NSX, and the broader Aria suite are deployed selectively or not at all. The consolidated VCF subscription brings all of these components into a single integrated stack. For customers who already operate the full set, this is a packaging change. For the larger segment of customers who do not, the question becomes how the broader stack fits their existing environment.

Several customer situations come up frequently in these conversations. Some customers have existing investments in third-party storage and networking platforms that they do not want to displace with vSAN or NSX, and the bundled licensing complicates the financial case for keeping those investments in place. Other customers have a growing AWS footprint and operations skill base, and an integrated AWS path may fit their direction of travel better than expanding into VCF capabilities they have not previously run. Still others lack the in-house SDN or hyperconverged skills required to operate a self-managed VCF environment at the level the product is designed for. Each of these situations is a reason to model the cloud options carefully against the renewal quote, not a reason against VCF in principle.

Under the current per-Core VCF subscription model, the consolidated packaging combined with the 16-Core-per-Processor minimum result in a licensed Core count that exceeds the physical Core count on hosts where individual processors have fewer than 16 cores. The net effect for many customers is a higher annual run rate relative to the prior à-la-carte model when compared at list pricing. The cost gap narrows after negotiation, since both Broadcom and AWS offer volume-based discounts; partners should always model on a like-for-like discounted basis, not on list prices alone.

Four structural elements of the new model drive this outcome.

Consolidated VCF Packaging

The new model consolidates previously modular components. Customers who separately licensed vSphere, vSAN, NSX, and Aria now purchase VCF as a single integrated stack. Customers who used only a subset of those components now pay for the full integrated bundle as part of the renewal.

Storage Bundling

VCF includes 1 TiB of vSAN capacity entitlement for each VCF Core licensed[Broadcom]. Because most on-premises environments run below 50% storage utilization, customers receive bundled storage entitlement built into the per-Core price that exceeds their typical use. Data-intensive workloads that exceed the bundled entitlement are billed at the per-TiB vSAN overage rate.

Anniversary Date Alignment

Renewals that are not aligned to the customer’s Broadcom anniversary date carry an alignment surcharge. This is a one-time cost that customers should factor into their first-year renewal budgeting.

The 16-Core-per-Processor Minimum and the Management Domain

Broadcom’s VCF Specific Program Documentation states that the Software is licensed on a per-Core metric with a minimum licensing requirement of 16 Cores per Processor[Broadcom]. The customer-facing Broadcom KB explains the effect with a worked example: a host configured with two CPUs of 8 cores each is licensed as if it had two CPUs of 16 cores each, i.e., 32 Cores rather than 16[Broadcom]. The same KB confirms the rule applies to both VCF and VVF deployments.

This rule interacts with the dedicated management domain that every VCF deployment requires. The management domain runs vCenter, NSX Manager, SDDC Manager, and related control-plane components on a minimum of four hosts. These hosts run no customer workloads, but under the per-Core model they are licensed at the same rate as production hosts, and the 16-Core-per-Processor minimum applies equally.

A typical four-host management domain with dual-Processor servers carries a meaningful licensed Core count, consuming licensing capacity that does not produce application output. As the workload environment grows and additional workload domains are added, each new domain requires its own dedicated management instances. The management domain does not scale linearly — it expands in discrete jumps, and each jump adds another block of fully-priced Cores dedicated to control-plane functions.

The practical impact varies inversely with environment size. In a 12-host deployment, the management domain consumes roughly one-third of total licensed capacity. In a 20-host deployment, it is closer to 20%. For mid-market organizations in the 128–500 Core range, this overhead is a material cost line that legacy assessment tools do not isolate by default. Surfacing it explicitly is one of the highest-leverage things a partner can do in a renewal conversation.

The vSphere 8 Deadline

vSphere 8 (ESXi 8.0, vCenter Server 8.0, vSAN 8.0) was released on October 11, 2022. Under Broadcom’s product lifecycle model — five years of General Support followed by two years of Technical Guidance — vSphere 8 enters two distinct end-of-support phases:

• End of General Support (EoGS): October 11, 2027[Broadcom]. After this date, vSphere 8 enters the Technical Guidance phase. General Support includes ongoing security patches, bug fixes, hardware compatibility updates, and full technical assistance; once it ends, those activities generally stop.
• End of Technical Guidance (EoTG): October 11, 2029[Broadcom]. Technical Guidance is a reduced-support phase — documented self-service guidance rather than new patches, fixes, or hardware certifications.

Most enterprise IT teams treat EoGS, not EoTG, as the real deadline. That gives every vSphere 8 customer a 13-month window of full support to choose between three actions: continue on a Broadcom-supported on-premises VCF release, migrate to Amazon EVS, or migrate workloads to cloud-native AWS. Each path has a meaningful lead time. Customers who begin scoping in the second half of 2026 are operating with realistic margin; customers who wait until 2027 will be making decisions under deadline pressure.

CPU Compatibility and Hardware Refresh

Hardware refresh is another budget line worth modeling alongside the software invoice. Current VCF releases have tighter Hardware Compatibility List (HCL) requirements than earlier versions, and some pre-2020 servers do not qualify. For customers planning to upgrade, this can mean a one-time hardware refresh to bring the estate onto a supported baseline. Subsequent point releases generally hold to the same HCL.

The timing of that one-time refresh intersects with the broader server hardware market. DDR5 and server-grade RDIMM pricing has risen through 2025 and 2026[TrendForce]. High-density virtualization hosts require maxed-out RDIMM configurations to maintain VM density, which leaves VCF deployments more exposed to memory pricing than general-purpose workloads.

None of these factors is dispositive on its own. Taken together with the new VCF subscription pricing, they are worth including in the on-premises continuation case so customers can compare it accurately to the cloud options.

The Full-Burden Cost Picture

Most renewal conversations anchor on the software invoice alone. The real total cost of staying on-premises with VCF spans six cost lines, and the comparison to AWS options requires modeling all of them. The table below shows the full picture for a recent assessment of a large industrial manufacturing organization (anonymized at the customer’s request), with the on-premises baseline alongside the two AWS platforms.

Figures reflect a representative engagement and use list-to-list pricing for VCF software lines; actual amounts vary with negotiated discounts on both the Broadcom and AWS side.

For the on-premises baseline, the software invoice ($723,900 plus $76,800 in management Cores) represents only 42% of the true annual cost. Hardware refresh cycles, DC facilities, and specialized VMware administration FTEs account for the remaining 58%. Renewal conversations anchored to the software line item alone systematically understate the cost of staying put.

The Amazon EVS column removes hardware and DC facility costs while continuing the VCF software subscription under BYOL. The cloud-native EC2 column removes the VCF subscription entirely and replaces the on-premises stack with native AWS infrastructure and storage. Both platforms reduce administration overhead, with EC2 reducing it further because cloud-native operations do not require VMware-specialist administration skills.

Figure 1 — The full-burden TCO across the three options. The software invoice is 42% of on-prem cost; the cloud paths remove different combinations of the remaining lines.

The Market Is Segmenting Along Predictable Lines

Not every VMware customer faces the same calculus. The opportunity for AWS Partners maps to three distinct segments.

ROBO and Edge (small core counts). The 16-Core-per-Processor minimum[Broadcom] hits this segment hardest. A small site with a single-Processor host that has only 8 cores must license 16 cores; a two-Processor host with two 8-core CPUs licenses 32. Smaller sites systematically license more capacity than they consume. Cloud-native Amazon EC2 or a non-VMware alternative such as Nutanix Cloud Clusters on AWS (NC2) is usually the better landing zone.

Mid-market (128–500 Cores). This segment faces the sharpest combination of cost pressure and skills gap. The SDN requirements in current VCF releases push many mid-market IT teams outside their current skill envelope. Cloud-native EC2 — with mature elastic compute, managed services, and built-in AI infrastructure — makes a compelling alternative.

Enterprise (500+ Cores). The strategic question for enterprise customers is rarely “stay or go” framed against the current footprint. It is “what is the best path to modernize the application portfolio?” — and the answer is usually a mix. EVS can host the workloads that need to move quickly without operational change; EC2 supports the longer modernization arc for the workloads where business value justifies it. The renewal cycle is the right moment to set both paths in motion.

Current VCF Releases: Why Staying Also Means Changing

Current VCF releases raise the operational bar alongside their architectural advances. They require a net-new SDDC stack implementation — NSX-T overlay, BGP/VTEP setup, and SDDC Manager lifecycle initialization — typically a six-month project that benefits from SDN specialists many mid-market IT teams lack in-house. Operations also carry a new obligation: under Broadcom’s VCF Specific Program Documentation, customers must submit an unaltered compliance report within 180 days of license registration and every 180 days thereafter. The VCF Specific Program Documentation [Broadcom] ties continued access to updates and upgrades to timely submission of the compliance report. That reporting cadence is worth modeling for regulated environments and any team whose patching depends on uninterrupted update access.

Together with the new commercial structure and the vSphere 8 EoGS deadline, these operational requirements are bringing many customers’ infrastructure decisions forward in the planning cycle.

Two AWS Platforms for VMware Customers

Customers leaving the on-premises VCF footprint have two well-supported destination platforms on AWS. They are not in competition — they serve different goals, and many engagements use both.

Amazon EVS — VMware Cloud Foundation, Hosted on AWS

Amazon EVS runs VCF workloads inside the customer’s Amazon Virtual Private Cloud (Amazon VPC) on a BYOL model. It is available in two operating models: customer self-managed (the customer’s VMware team retains day-to-day operations) and Partner Managed (an APN partner provides managed operations on the customer’s behalf). It is well suited for organizations with an active Broadcom agreement, established VMware operations or partner-supplied managed operations, and a hardware refresh or datacenter lease decision driving them off-premises in the next 12–18 months.

Amazon EVS pricing has three dimensions: Amazon EC2 i4i.metal instance charges, VPC Route Server Endpoints per environment, and an EVS Control Plane at $0.92/instance-hour[AWS]. An EVS cluster has a minimum size of four hosts and a maximum of sixteen[AWS]. A representative four-node US East environment runs approximately $35,000/month on-demand, $23,800 on a one-year savings plan, or $17,800 on a three-year commitment. The VCF license remains the customer’s responsibility under BYOL.

Cloud-Native Amazon EC2

For customers ready to adopt cloud-native AWS services, Amazon EC2 is the destination platform. Amazon EC2 provides the elastic compute foundation, with the full breadth of AWS-native services available as the migration progresses: Amazon Elastic Block Store (Amazon EBS) and Amazon S3 for storage, Amazon RDS and Amazon Aurora for managed databases, Amazon Elastic Kubernetes Service (Amazon EKS) for container workloads, and AWS Graviton Processors for price-performance gains on compatible workloads.

This is the right platform choice for customers whose primary objective is to leave the VMware operational model entirely and modernize workload-by-workload where the business case supports it. It removes the VCF subscription from the cost structure, eliminates the need for VMware-specialist administration, and opens the door to per-workload modernization that EVS, by design, does not.

Complementary AWS options for specific architectural needs. Beyond the two primary platforms, AWS offers several first-party and partner services that broaden the option set for customers with specific hypervisor, storage, or container requirements. Nutanix Cloud Clusters on AWS (NC2) provides an alternative hyperconverged hypervisor stack on AWS for customers who prefer Nutanix’s architecture or want a non-Broadcom HCI path. Amazon FSx for NetApp ONTAP (Amazon FSxN) is a managed NetApp-compatible storage service that pairs well with both Amazon EVS[AWS] and cloud-native EC2 for customers extending existing NetApp investments into AWS. Red Hat OpenShift Service on AWS (ROSA) is a managed OpenShift platform for customers whose modernization target is container-based application platforms. These services are not substitutes for the EVS or EC2 platform choice itself; they are options that partners can fold into the broader architecture conversation based on customer constraints and preferences.

Figure 2 — Placement grid for VMware-to-AWS conversations. Position the customer on the two axes; the quadrant indicates the platform play and partner motion.

The Five-Adjustment Framework: Closing the Gap Legacy Tools Leave Open

Legacy migration assessment tools produce a useful starting point but leave five categories of cost and placement unaddressed. ModernZ applies these five adjustments as a repeatable framework on every VMware-to-AWS engagement to convert a partial estimate into a defensible, licensing-accurate TCO comparison. The categories themselves are not proprietary, and any qualified APN partner with VMware modernization expertise should surface them; what ModernZ brings is the discipline of applying all five, in sequence, on 100% of the estate. Customers should expect to see them in a credible renewal assessment.

1. Management domain Core isolation. Separate management-domain licensing Cores from workload Cores. Legacy tools count all Cores equally; isolating the management overhead shows customers what they are paying for control-plane functions alone.
2. vCPU right-sizing on both sides. Legacy assessment tools size AWS targets against allocated source vCPUs and ignore that on-prem ESXi runs at 3:1 to 5:1 vCPU-to-physical-core density on properly utilized estates. The real performance baseline is the customer’s observed physical-core-equivalent throughput, not the sum of allocated vCPUs. Intel-based EC2 instances apply the same hyperthreading mechanics as on-prem Xeon hosts (2 vCPUs per physical core), so once the source baseline is corrected, the source-to-target vCPU mapping is direct. Layering in observed utilization data tightens the target further. Latency-sensitive workloads (real-time databases, HFT, low-latency messaging) should be sized at 1:1 on both sides and considered for metal or dedicated-host targets.
3. Storage tier mapping. Map on-premises storage consumption to the appropriate AWS storage tier (Amazon EBS gp3, io2, or Amazon S3) rather than assuming a single block-storage equivalent. Most VMware estates carry 40–60% of data on tiers that map to lower-cost object or infrequent-access storage in our experience.
4. Windows and Oracle license placement. Identify Windows Server and Oracle Database workloads and place them on Amazon EC2 Dedicated Hosts, enabling BYOL and eliminating duplicate licensing fees that legacy assessments do not model.
5. Zombie VM identification. Flag VMs with no meaningful CPU, memory, or network activity over a 90-day window. These VMs consume active licensing cost on-premises but require no target-state compute. Removing them before migration reduces both the VCF renewal baseline and the AWS target cost.

Putting It Into Practice: A Recent Engagement

Any partner applying this framework in full should see results in the same shape — the methodology is replicable. The following engagement is representative. In a recent engagement led by ModernZ for a large industrial manufacturing customer (anonymized), applying all five produced the following outcome compared to the legacy assessment baseline:

• Full-burden VCF on-premises: $1,901,310 annually
• Optimized AWS target: $842,322 annually
• Annual saving: $1,058,988 (~56%)

The legacy assessment tool covered roughly three-quarters of the estate and fully mapped about half, leaving the SAP and VDI tiers for additional analysis. The five-adjustment framework assessment covered 100% of the estate and identified hundreds of zombie VMs consuming active licensing cost with no productive workload attached. Placing Windows Server and Oracle workloads on Dedicated Hosts eliminated roughly $350,000 of operational cost — at which point the migration self-funds from cost arbitrage within the first year.

From Assessment to Migration: Pairing Strategic Planning with Execution

ModernZ Assess, now available on AWS Marketplace, is natively integrated with AWS Transform and can be selected as an agent capability directly inside any AWS Transform workspace chat session, so the handoff from assessment to migration execution happens inside a single tool experience. Engagements like the one above combine two distinct layers of work. The first is the strategic planning and assessment layer — producing the full-burden TCO model, applying the five adjustments, isolating management-domain overhead, modeling licensing placement, and recommending the workload-to-platform mapping across EVS and EC2. This work is typically delivered by APN partners with VMware modernization expertise. The second layer is migration execution to AWS — carried out using AWS Transform, the strategic AWS service for VMware migration to Amazon EC2, with its agentic capabilities for server, storage, and network migration. Customers moving to Amazon EVS typically use VMware HCX for the workload transfer into the EVS environment. Pairing an accurate plan with an automated execution path produces faster timelines and tighter cost outcomes than either layer can produce alone.

Why This Moment Matters for AWS Partners

Customers whose VCF agreements are expiring before Q4 2026 are making architectural decisions now. They are looking for partners who can model the full range of options accurately — continuation on VCF, transition to Amazon EVS, and cloud-native migration to Amazon EC2 — with licensing-accurate TCO models and a credible execution path. The five-adjustment framework, full-burden cost picture, and EVS/EC2 platform positioning in this post are the fluency partners need for those conversations.

Engage AWS and a Qualified APN Partner

If you are an AWS Partner working with a VMware customer in a renewal cycle, or a customer evaluating your VCF renewal alongside cloud options, the right next step is to engage your AWS account team and a qualified APN partner with VMware modernization expertise. A joint assessment can produce a licensing-accurate TCO model covering on-premises continuation, Amazon EVS, and cloud-native Amazon EC2, structured against your specific commercial timeline.

ModernZ, a co-author of this post, is an APN partner built specifically for the VMware-to-AWS moment. To engage ModernZ, subscribe to ModernZ Assess SaaS for AWS Transform or ModernZ Applied Professional Services on AWS Marketplace, contact your AWS account team, or reach out through AWS Partner Central.