Broadcom’s Core Licensing for VMware vSphere – What Customers Need to Know

Broadcom’s Core Licensing for VMware vSphere

Introduction – From Per-Socket to Per-Core

VMware vSphere traditionally used a per-CPU (per-socket) licensing model. This meant that one license covered an entire physical processor, regardless of the number of cores on that chip.

A decade ago, when CPUs had fewer cores, this was straightforward and cost-effective for customers.

However, as modern server CPUs began packing 32, 48, or even 64 cores on a single chip, VMware adjusted its policy. Read our complete guide to VMware Licensing Changes Under Broadcom: vSphere, vSAN, NSX & More.

In 2020, VMware introduced a 32-core per-CPU licensing cap: one license covers up to 32 physical cores on a processor, and CPUs with more than 32 cores require an additional license. (For example, a 48-core CPU would need two licenses under that rule.)

This was VMware’s first step toward accounting for core density in its pricing.

Fast forward to Broadcom’s acquisition of VMware (completed in 2023), and we’re seeing a strict shift from per-socket to per-core licensing. Broadcom is now rigorously enforcing the 32-core rule and even evolving it into a true per-core model for subscriptions.

In other words, VMware under Broadcom is no longer treating a CPU as a single unit if it has high core counts – every core counts toward your license requirements.

This change has huge implications for customers: it can drastically increase costs on today’s multi-core servers and introduces new compliance risks if you don’t adjust your licensing to match your hardware.

IT leaders, procurement teams, and license managers must understand this shift, as the old assumption of one license per CPU is no longer valid.

The sections below break down how Broadcom’s core-based licensing works, what it means for your budget and compliance, and how you can strategize and negotiate to mitigate the impact.

How Broadcom’s Core Licensing Works

Under Broadcom’s updated model for vSphere, a single CPU license entitles you to use up to a certain number of processor cores – historically, 32 cores per CPU. If a CPU has more cores than the entitlement, you must purchase additional licenses for that CPU.

In practice, each license covers up to 32 cores on a processor (and in newer subscription models, this entitlement has even been reduced to 16 cores in some cases).

Any cores above that count effectively consume another license.

This is best illustrated with an example:

• Example: Suppose you have a server with two physical CPUs, each with 64 cores (128 cores total). Under VMware’s old per-socket model, you needed just two licenses (one per CPU). Under Broadcom’s core-based model (32 cores per license cap), you now need four licenses for that server. Each 64-core CPU uses two licenses (since 64 cores ÷ 32 cores/license = 2 licenses per CPU). What used to require two licenses now requires 4 – doubling the license count (and cost) for the same hardware.

The practical impact is that dense, high-core-count servers will incur significantly higher licensing costs.

A 64-core processor is treated like two processors from a licensing perspective.

Even a 40-core or 48-core CPU, which many modern servers have, will require two licenses instead of one.

If you had standardized on AMD EPYC or Intel Xeon chips with very high core counts per socket, your vSphere licensing needs could jump substantially when renewing or expanding under Broadcom’s rules.

It’s also important to note that Broadcom is moving VMware toward pure per-core licensing for subscriptions.

This means the entitlement may not always remain at 32 cores – in fact, recent subscription offerings limit the limit to 16 cores per license. Additionally, Broadcom has introduced a minimum license purchase of 72 cores for many products, including vSphere.

This doesn’t mean a single CPU needs 72 cores; rather, it means when you buy or renew, you must pay for at least 72 cores worth of licensing per product. So, even if you only have, say, 2 CPUs with 16 cores each (32 cores total), you could still be forced to buy a minimum of 72 cores of licenses.

In summary, the new regime counts every core and often results in over-buying licenses if you fall under certain thresholds.

Bottom line:

vSphere is no longer licensed “by the socket” in any practical sense – core counts license it. Customers must calculate their total cores in use and ensure they have the corresponding number of licenses (with each license covering the allowed cores).

Any assumption that a single CPU equals a single license can lead to costly shortfalls.

Cost Impact of Core Licensing

Shifting to a core-based licensing model has an obvious effect on costs: the more cores you utilize, the higher your costs. Organizations running modern high-density servers will feel this the most.

Here are the key cost impacts to consider:

• Higher Licensing Counts = Higher Costs: If your servers have CPUs with dozens of cores, you will need multiple licenses per CPU. For instance, an environment of ten dual-socket servers with 32-core CPUs per socket would have required 20 licenses under the old model (10 servers × 2 CPUs each). If those servers now use 64-core CPUs, the requirement doubles to 40 licenses. In effect, upgrading to newer CPUs can double your vSphere licensing costs for the same number of physical machines. For very core-dense setups (like 4-socket servers or newer 96-core CPUs), the license count (and cost) could triple or quadruple compared to the old per-socket assumption.
• Broadcom Price Increases: Broadcom also has strong incentives to raise the price per license. As they transition customers from perpetual licenses to subscriptions, early reports and negotiations have indicated higher unit costs. A per-core license (or a per-32-core license pack) may be priced higher than the old per-socket license, especially when bundled features are included. Be prepared for the possibility that the list price of a vSphere core license under Broadcom could be higher than VMware’s historical pricing. Broadcom aims to rapidly increase VMware’s revenue, and pricing adjustments are a key component of that strategy.
• Bundling and Suite Costs: Another cost factor is product bundling. Broadcom has begun packaging vSphere into larger bundles, such as VMware Cloud Foundation (VCF) or a slimmed-down vSphere Foundation suite. Instead of selling vSphere (and vCenter) alone, they might require you to purchase a broader solution that also includes vSAN, NSX, or other components. These bundles naturally come with a higher price tag than just vSphere itself. Even if you only need the hypervisor, you might end up paying for an entire stack. For example, a customer who previously purchased vSphere Enterprise Plus and vCenter a la carte might now be required to buy a Cloud Foundation subscription that includes those, as well as additional software (Tanzu, vSAN, NSX, etc.) that they may not have intended to purchase. The cost “uplift” can be dramatic – some customers have reported total renewal quotes climbing by several multiples (2x, 3x, even 5x or more) because of mandatory bundle licensing and per-core metrics. This bundling effectively inflates spend by forcing you to buy more than just the core hypervisor technology.

All these changes point to one outcome: costs are going up for vSphere customers who continue under Broadcom’s default licensing terms. Dense compute environments, in particular, will see significant budget impacts.

It is not uncommon to project double-digit or higher percentage increases in your VMware spend year-over-year due to these licensing changes alone.

In extreme cases (like organizations forced into expensive bundles or massive core-count true-ups), costs might balloon so much that they challenge the financial viability of sticking with VMware without some adjustments or concessions.

Read how to combine negotiations, How to Negotiate vSAN and vSphere Together in Broadcom Deals.

Compliance & Audit Risks

With the move to core-based licensing, compliance becomes a critical concern.

Every physical core in your environment must now be accounted for in your licensing.

If you are not properly licensed for all deployed cores, you are out of compliance with VMware’s terms, and Broadcom is expected to be far less forgiving about that than VMware was in the past.

Key compliance risks and considerations include:

• Under-Licensing is Contract Breach: If, for example, you have a 48-core CPU and only allocated one license to it (assuming it was like the old days), you would be 16 cores under-licensed for that processor. This constitutes non-compliance with the EULA. Under Broadcom, not licensing all cores on all CPUs is a clear breach of your agreement. It’s similar to using more copies of software than you bought – here the “copies” are cores. This kind of shortfall can happen inadvertently if your team wasn’t aware of the 32-core rule or if you added new hardware without purchasing additional licenses. Unfortunately, “we didn’t know” won’t be a valid excuse in an audit.
• Broadcom’s Audit Posture: Broadcom is known for a much more aggressive stance on software audits and compliance enforcement. Now that VMware is under Broadcom’s umbrella, customers should expect increased audit activity. Broadcom’s audit teams will likely scrutinize core counts, license quantities, and deployment data to find any discrepancies. Given the complexity of virtualized environments, it’s easy for licensing deployments to drift out of sync with entitlements, and Broadcom will be looking for those gaps. We anticipate that core count misreporting or ignorance of the 32-core cap will be a prime target in upcoming audits.
• Consequences of Non-Compliance: If an audit reveals that you have unlicensed cores, Broadcom will likely require you to rectify the shortfall retroactively. This could mean purchasing back-dated licenses or subscriptions for those excess cores, potentially with back maintenance fees or at least (non-discounted) pricing. In some cases, vendors also charge penalties or true-up fees for the period you were out of compliance. Broadcom might also use the audit findings as leverage to push you into a new licensing model – for instance, they could require you to transition to a subscription bundle (such as Cloud Foundation) as part of resolving the compliance issue. The worst-case scenario (beyond financial penalties) is that Broadcom could threaten to terminate support or licenses for breach; however, these situations are typically resolved through payment and/or contract adjustments rather than termination. Still, it’s a stressful and expensive process to go through an audit failure.
• No More “Soft” Enforcement: VMware historically gave a grace period when the 32-core rule was introduced (back in 2020, they allowed customers some time to purchase extra licenses if needed). Broadcom’s approach is far less lenient. Now that we’re a few years on, they expect customers to have adjusted. There is little room for pleading that you weren’t aware. Compliance is expected immediately and continuously. Also note that Broadcom instituted a policy where if you renew late (after your license term expires), they impose a hefty 20% premium on the renewal cost. This is essentially a penalty to enforce timely renewals and discourage any lapse in licensing. It’s another form of strict compliance – not only do you need the right core counts, you must also stay on schedule with contract renewals.

In summary, the core-based model introduces more points of potential non-compliance (every CPU’s core count is a checkpoint).

Broadcom is likely to check those points through audits. The onus is on customers to self-audit and remain compliant, because the fallout of being caught under-licensed can be very costly.

It’s wise to conduct internal licensing audits now: inventory all ESXi hosts, document the number of cores each CPU has, and ensure you have the licenses to match.

That way, if Broadcom comes knocking, you’re prepared and in the clear. Also consider negotiating audit-friendly terms (more on that below) to protect yourself.

Negotiation Strategies

In the face of these changes, customers are not without options. Proactive negotiation with Broadcom can mitigate some of the cost and compliance pain.

If you’re entering a renewal or a new agreement for vSphere (or moving to VMware’s subscription model), it’s crucial to bring these issues to the negotiation table.

Here are several strategies and tactics to consider:

• Request Grace for Slightly Over-32 Core CPUs: If your environment includes processors that are just above the 32-core threshold – for example, 36-core or 40-core CPUs – ask for a grace clause or exception in your contract. The idea is to negotiate that those CPUs still count as a single license rather than two. Broadcom may be willing to grant an exception for a small core count overage, allowing up to 40 cores to be covered by a single license. This can save you from paying double licenses for just a few extra cores. Make the case that it’s an important goodwill gesture, especially if only a minority of your hosts exceed the cap.
• Negotiate Core Carve-Outs: For larger enterprises running mixed hardware, you can negotiate an allowance that allows a certain percentage of your servers to exceed 32 cores per CPU without incurring additional charges. For instance, you might propose a carve-out such as: “Up to 10% of deployed CPUs may have more than 32 cores without requiring an extra license.” This kind of clause provides a buffer for those high-core systems. It essentially bundles a bit of extra capacity at no additional cost. Broadcom might agree to this if you’re a valuable customer or are committing to a sizable deal, as it doesn’t cost them much unless your environment is heavily skewed towards very large CPUs.
• Seek High-Core Discounts: If your infrastructure is comprised of high-core-count CPUs (such as 48-core or 64-core chips across the board), be upfront about the cost impact and push for additional discounts to offset the license count increase. You may be able to negotiate a reduced price per license once you exceed a certain number of cores/licenses. For example, after purchasing licenses for the first 500 cores, the next block of cores could be at a lower unit price. Broadcom sales teams do have flexibility on discounting, especially if they sense that costs are becoming a barrier for you. Use data from your environment to show how the new model affects your spend, and request pricing relief in the form of volume discounts or special pricing for high-core deployments.
• Cap Renewal Uplifts: Given Broadcom’s tendency to raise prices, it’s wise to negotiate a cap on annual price increases for your licenses or subscriptions. If you’re signing a multi-year agreement (which Broadcom actually encourages), insist on an uplift cap – for instance, no more than a 3% or 5% price increase per year or at renewal time. This can be written into the contract. It protects you from unwelcome surprises, such as a 20% increase in cost at the next renewal. Multi-year deals give you more leverage to include such caps, because you can commit to a longer term in exchange for price predictability. Don’t accept vague assurances; get a clear percentage cap in writing.
• Consider Enterprise Agreements or Alternative Metrics: If you have a very large VMware estate, you may want to steer the negotiation away from per-core counting entirely. For example, propose an Enterprise License Agreement (ELA) or a per-cluster licensing model. An ELA is where you pay a flat fee for usage up to some defined capacity (or even unlimited use) over the term of the agreement. If Broadcom wants to retain your business, it might consider a custom metric that simplifies licensing for you. Another approach is a per-processor flat fee for your whole environment – effectively honoring the old model in a custom way – or licensing by clusters or host counts instead of cores. These kinds of custom deals are usually only viable for large customers with significant negotiation clout, but if your environment is substantial, it doesn’t hurt to raise the idea. The key is to escape the straitjacket of “each core costs X” and adopt a model that provides cost certainty regardless of minor hardware changes.
• Embed Protective Clauses: As part of your negotiation, also try to insert clauses that protect you in case of compliance issues or changing needs. For example, an audit remedy clause could state that if any licensing shortfall is discovered, you can resolve it at your pre-negotiated discount rates (avoiding punitive list-price charges). Another clause might allow some flexibility to adjust your license counts down if you decommission servers (so you’re not stuck paying for cores you no longer use). Think ahead about what could go wrong (e.g., over deployments, audits, hardware refreshes) and include some safety nets in the contract.

To illustrate, here are a few sample contract clause wordings that reflect these ideas:

• Grace Clause: “Customer shall be entitled to license CPUs with up to 40 cores at the standard per-CPU license cost for the duration of this agreement.” (This gives a bit of breathing room above 32 cores.)
• Core Carve-Out: “Customer may deploy additional cores beyond 32 per CPU in up to 10% of servers without additional license cost.” (This provides a buffer for a limited number of high-core machines.)
• Audit Remedy: “Any license non-compliance identified during an audit shall be resolved at the customer’s contracted discount rates, not at list pricing, with no punitive fees, provided the shortfall is remedied within 30 days.” (This prevents nasty financial surprises in an audit scenario.)

The exact wording and terms will vary, but the takeaway is to be proactive and specific in your negotiations. Don’t simply accept Broadcom’s standard quote or contract language, which will be written in their favor.

Almost everything is negotiable if you have a solid business case or the willingness to push back.

Remember, Broadcom’s sales reps have targets to meet, and they do not want to lose customers, especially large ones. Use that to your advantage to secure concessions that will save your organization money and reduce risk.

Leverage Points

To strengthen your negotiation position, consider the leverage you have (or can create) in the face of Broadcom’s licensing push.

Here are some angles to leverage in your discussions:

• Broadcom’s Cloud Vision vs. Your Plans: Broadcom is very keen on moving customers onto VMware Cloud Foundation and subscription bundles. If this doesn’t align with your current plans, you can use your reluctance as leverage. For example, if they are pushing you to adopt Cloud Foundation (which includes vSphere, vSAN, NSX, etc., in one package), you might say: “We’re not convinced about Cloud Foundation yet; it’s expensive and not in our roadmap. But if you can address our concerns on vSphere licensing costs (or give us a better deal), we might consider evaluating it in the future.” This signals that Broadcom has something to gain by negotiating – your potential buy-in to their strategic products – and they might be willing to relent on core licensing fees or offer incentives to sweeten the deal. Essentially, use Broadcom’s own priorities as bargaining chips. If you don’t actually need what they’re upselling, that’s fine – the point is to extract a concession in return for even considering it.
• Highlight Competition and Alternatives: The virtualization market isn’t a monopoly. As a customer, you do have alternatives: Microsoft Hyper-V (part of Windows Server), open-source KVM (used in many Linux environments and clouds), or Nutanix AHV for those using Nutanix infrastructure, among others. While switching hypervisors or platforms is non-trivial, it’s entirely possible – and Broadcom knows this. Make it clear to Broadcom that you are evaluating other options due to their licensing changes. Even if it’s just a strategic bluff, mentioning that you’re testing Hyper-V or considering moving some workloads to the cloud or to containers can put pressure on Broadcom. They’ll realize that squeezing you too hard on licensing could backfire if you decide to migrate away from VMware. Vendors become much more flexible when they sense a customer is ready to walk. Use the existence of viable alternatives as a negotiation lever: for example, “If we can’t reach a reasonable agreement, we may have to divert new projects to a different virtualization platform.” This can prompt Broadcom to offer discounts or special terms to keep your business.
• Leverage Your History and Size: If you’ve been a long-time VMware customer (especially if you have a significant annual spend), leverage that loyalty. Broadcom might be new to the helm, but VMware’s value to them is in its customer base. They cannot afford to have mass defections. Remind them of your deployment scale and future growth. For instance, “We currently run 500 vSphere licenses and plan to expand – but not if the cost becomes prohibitive. We want to stay on VMware, but we need a sustainable model.” By emphasizing how much you’ve invested and will invest, you put the onus on Broadcom to find a way to keep you on board. They may not budge on the model entirely, but they could offer creative solutions, such as transition credits, flexible payment terms, or bundling something you need at a discount to offset the core costs.
• Timing and Multi-Product Deals: Broadcom aims to achieve aggressive revenue targets promptly. This means that end-of-quarter or end-of-year deals may be particularly ripe for securing concessions, as sales teams rush to meet their quotas. If you can time your negotiation to coincide with these crunch times, you might be able to extract a bit more flexibility. Additionally, if you’re also using other VMware products (or even other Broadcom software), consider bundling your negotiations across products. Perhaps you need to renew vSphere and purchase some security software from Broadcom – negotiating them together could give you more leverage overall, letting you trade something in one area for a benefit in another. Broadcom wants to increase your total account value, so you can say, “I might buy product X from you as well, but only if we can sort out this vSphere licensing issue.” Internal alignment on your side (between teams managing different software) can enable this approach.

In essence, don’t go into discussions as if you have no choice. Leverage every point of influence you have – whether it’s the possibility of taking your business elsewhere, the fact that Broadcom wants to sell you additional products, or your importance as a customer.

This will improve your chances of negotiating a more favorable outcome, or at least tempering the worst of the cost increases.

vSphere Licensing – Old vs. Broadcom Core Model (Comparison Table)

To summarize the differences between VMware’s legacy licensing model and Broadcom’s new core-based model, the table below compares key factors and suggests a buyer’s strategy for each:

(Table: Key differences between legacy VMware licensing and Broadcom’s new core-based model, with strategies for customers to respond.)

FAQs

Q: Do I need to license all CPU cores under Broadcom’s model?
A: Yes. Under Broadcom’s vSphere licensing, every physical core on every CPU must be covered by a license entitlement. In practice, this means if you have a dual-socket server, you count the total cores across both CPUs and ensure you have purchased enough licenses to cover that number (given the per-license core allowance). There is no allowance for “free” cores beyond the cap. If any cores are unlicensed, you are in non-compliance. For example, a single 24-core CPU is fine with one license (since it’s under 32), but a 40-core CPU would need two licenses because one license only covers up to 32 cores – you can’t ignore the extra eight cores. Always assume all cores count toward your licensing requirements.

Q: How much more will vSphere cost if I run high-core-count CPUs (e.g., 48 or 64 cores per socket)?
A: In general, the cost will increase linearly with core count once you exceed the per-license limit. For a 48-core processor, you’ll need two licenses (instead of 1 in the old model), effectively doubling the cost for that CPU. A 64-core processor also needs two licenses (double the cost per CPU compared to legacy). If you have two 64-core CPUs in a server, you need four licenses for that server, whereas previously you would have needed only two – that’s a 100% increase in license count for the server. Therefore, high-core servers can cost approximately twice as much in licensing as before. The exact financial impact depends on your license pricing, but you can expect a substantial increase. Additionally, if Broadcom has raised the price per license (which is likely), the cost increase is compounded: you’re buying more licenses, and each license might be pricier. In some reported cases, organizations have seen their VMware licensing budgets increase multiple times (e.g., 200% or more) when upgrading to newer, high-core hardware, combined with Broadcom’s pricing changes. It’s crucial to forecast these costs before you invest in new servers – sometimes scaling out with more lower-core CPUs might be cheaper than a few monster-core machines once licensing is factored in.

Q: Can I still negotiate a traditional per-socket licensing agreement instead of per-core?
A: Broadcom’s official stance is to license per core (especially for new subscriptions), so you won’t find a standard offering that ignores core counts. However, in negotiations, anything is possible for a large enough deal. While you likely cannot get them to explicitly contract “per-socket unlimited cores” in writing (that would contradict their public policy), you might achieve a similar outcome through creative terms. For instance, a clause that “CPUs up to X cores count as one license” is effectively a per-socket deal up to that core count. Or an enterprise license could allow unlimited use for a fixed price, sidestepping per-core tracking. Some customers have had success obtaining custom agreements, such as host-based or site-based licensing, which simplifies things on their end. These are usually bespoke arrangements for sizable commitments. If you’re a smaller customer, it’s unlikely Broadcom will bend the model for you – your best bet is to negotiate some exceptions or additional discounts (rather than an outright different metric). In summary, traditional per-socket licensing is no longer a standard option. Still, you can negotiate terms to make the core model more palatable or even approximate a per-socket model in effect. This will depend on your leverage and the scale of your deployment.

Q: What are the audit risks if I under-license or ignore the core-based rules?
A: The risks are significant. If you are found to be using more cores than you have licensed (under-licensing), an audit will flag this as a compliance violation. Broadcom’s audit team would then require you to purchase the necessary licenses for those unlicensed cores, typically at the full list price and potentially retroactive to the date the usage began. That could mean a large, unexpected bill. They may also charge backdated support fees for the period during which those cores were in use without a license. In some cases, if the gap is serious, Broadcom may impose penalties or interest on the unpaid licenses; however, the “penalty” is often essentially paying a premium price. Another risk is that Broadcom might use the audit finding to push you into a different licensing model – for example, saying “you need to convert to this subscription (or bundle) to resolve the compliance issue,” effectively upselling you as part of the settlement. While outright legal action is rare, if the customer cooperates to remedy the issue, the process can still strain your budget and relationship. Also, during an audit, you’ll have tight timelines to respond and correct things, which can be disruptive. Prevention is far better; it’s advisable to regularly review your core counts versus licenses and true up proactively if needed (preferably at your negotiated discount rate, not after being caught). If you suspect you’re not in compliance, it may even be worth approaching Broadcom first under a friendly true-up, rather than waiting for an audit. That way, you maintain some control over the process. In short, under-licensing cores is a serious risk under Broadcom’s watch – it can lead to hefty fees and a forced move to costly subscriptions if not carefully managed.

5 Actionable Recommendations for Customers

To navigate Broadcom’s core-based licensing changes, here are five concrete steps and best practices for IT leaders and procurement teams:

1. Audit Your Current Environment Now: Don’t wait for Broadcom to tell you – know your own deployments. Conduct a thorough internal audit of all your VMware hosts. Document the number of CPUs and cores per CPU on each server. Determine how many vSphere licenses you are consuming under the new rules versus how many you actually own. This baseline will identify any compliance gaps (e.g., servers that require additional licenses) and quantify the impact on your license count. Having these facts at your fingertips is essential preparation for both budgeting and any upcoming negotiation or audit. It also helps you identify specific pain points – like a particular cluster with many high-core CPUs – that you might address through hardware changes or contract terms.
2. Proactively Engage Broadcom – Negotiate Grace and Carve-Outs: Don’t passively accept the quote or contract presented. When renewals or new purchases are up for consideration, open a frank dialogue about the core licensing impact. If you’re slightly over the 32-core threshold on some CPUs, request a grace allowance for those. Likewise, negotiate for a core carve-out in your contract (for example, a certain number of cores or a percentage of servers can exceed the limit without extra cost). It’s much better to have these exceptions granted up front in writing than to hope for leniency later. Broadcom may not volunteer such concessions, but if you ask and have a rationale (e.g., “We only have a handful of 40-core CPUs – it doesn’t make sense to double-pay for just those few cores”), you might get relief. Be specific in your requests and get any agreed-upon exceptions documented in the contract or order form.
3. Secure Multi-Year Predictability (Cap Your Uplifts): Broadcom’s pricing can be a moving target year to year. Aim to lock in pricing for 3–5 years if possible. During negotiations, push for a cap on annual price increases or even a fixed price over the term for your vSphere licenses or subscription. For example, negotiate something like “pricing shall not increase by more than 5% at each renewal anniversary” or “the per-core subscription rate is fixed for three years.” In exchange, you might commit to a multi-year term (which Broadcom actually likes, because it guarantees them longer revenue). The benefit to you is stability – you won’t get an unpleasant surprise at the next renewal. This is essentially an insurance policy against Broadcom’s tendency to raise prices once you’re dependent on them.
4. Use Broadcom’s Bundles as Leverage (but Don’t Overbuy blindly): If Broadcom is pushing you toward VMware Cloud Foundation or other bundled offerings, use that as a negotiation lever, but be cautious about adopting bundles you don’t need. Make it clear that you have options: “We could consider Cloud Foundation in the future, but right now it’s not necessary for us – unless there’s a compelling financial incentive.” This sets the stage for Broadcom to possibly offer a better deal on the core licensing or throw in some add-ons at no extra cost to entice you. If you do end up needing parts of the bundle (for instance, if you were planning to deploy vSAN or NSX anyway), leverage that cross-product purchase to negotiate better terms across the board. The key is not to let Broadcom simply dictate the bundle and price; instead, say you’re willing to entertain it if—and only if—the overall proposal (including core licensing costs) makes sense. This approach can either secure a discount or, at the very least, delay the adoption of a forced bundle until you’re ready. Remember, interest in their broader vision doesn’t mean commitment – it’s a bargaining tool for you.
5. Evaluate Alternatives and Prepare a Plan B: The best negotiators have a credible fallback. Even if you prefer to stay with VMware vSphere (and most do, given its market-leading status), it is advisable to research and evaluate alternative platforms as a contingency. Look at the feasibility of moving some workloads to Microsoft Hyper-V or to cloud services, or using an open-source hypervisor. Also, assess emerging solutions like Nutanix AHV if you’re in a hyper-converged infrastructure, or Red Hat virtualization stacks if you lean towards open-source solutions. By having a “Plan B” (even a partial one, such as migrating non-critical environments or halting the expansion of VMware), you gain leverage. Internally, quantify what it would take to transition X% of your estate off VMware – cost, time, savings. You can then use that in discussions, for example: “If VMware costs spike, we have approval to shift our DR environment to Hyper-V – we’d prefer not to, but we have to be cost-conscious.” The mere fact that you have an alternative path will make Broadcom more inclined to negotiate reasonably. And if worst comes to worst, you actually have an exit strategy to avoid being hostage to untenable licensing costs. Preparing alternatives is both a negotiation strategy and a risk mitigation strategy for your organization’s IT roadmap.

By following these recommendations, you’ll be better positioned to handle Broadcom’s core-based licensing for VMware vSphere.

The key is to be proactive, informed, and firm. Don’t get caught off guard by the new rules – anticipate them and plan your response.

Broadcom’s changes do present challenges, but with savvy management and negotiation, you can continue to leverage the benefits of VMware’s technology without succumbing to budget shock or compliance nightmares.

The ultimate goal is to strike a balance where you remain compliant and well-supported and your costs stay within reason for the value delivered.

With preparation and the right approach, you can achieve that even in this new licensing era.

Read more about our VMware & Broadcom Licensing Consulting Services.

Do you want to know more about our Broadcom Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit