Termination of VMware Perpetual Licenses: What Enterprises Can Do

VMware Perpetual Licenses Terminated — What That Means Now

VMware’s new owner, Broadcom, has ended the sale of perpetual licenses for VMware products.

In late 2023, just after the acquisition, VMware customers lost the option to buy licenses they own outright. Instead, all new VMware licensing is subscription-only.

This shift has immediate implications: you can continue running existing VMware versions you’ve already bought, but once your current support contract expires, you lose access to patches, updates, and technical support. Essentially, owning your virtualization software “forever” is no longer on the table.

For enterprise buyers, this raises urgent questions.

There’s pressure to re-license under Broadcom’s subscription model to stay supported and secure. However, moving to subscription may upend your budget (turning a one-time CapEx spend into ongoing OpEx) and lock you into multi-year commitments.

Fortunately, you still have choices. You can stick with your legacy VMware setup, convert to subscriptions on negotiated terms, or evaluate alternatives outside VMware. Each path comes with trade-offs in risk, cost, and control.

The key is to chart a course for each system that preserves your compliance and uptime without handing Broadcom a blank check.

What Changed for Enterprise Buyers

The shift from perpetual licenses to subscriptions is more than a pricing tweak – it’s a fundamentally new reality for IT procurement and operations.

Here’s what changed:

• Budget Impact: Perpetual licenses were purchased up front and used for years. Now, VMware licensing is subscription-based, meaning recurring fees (OpEx). Many enterprises face higher 3- to 5-year costs with subscriptions than they did under perpetual models. Broadcom often seeks multi-year commitments (e.g., three-year lock-ins) for VMware subscriptions, reducing your flexibility. If you try to renew for shorter terms or lapse on renewals, you risk steep uplift penalties. In short, expect to negotiate harder to control costs, since the default subscription pricing can climb over time.
• Operational Changes: Under Broadcom, VMware’s product catalog was streamlined into bundles. You can no longer buy certain components standalone – for example, vSphere, vSAN, and NSX now come packaged together in suites. This might force you to pay for features you don’t use, or adapt your tooling to fit VMware’s bundles. Additionally, VMware’s customer portal and licensing system moved to Broadcom’s platforms in 2024. Accessing your license keys and downloads now requires using Broadcom’s support portal, and only licenses with active support contracts were carried over. If your support lapsed, you may find your entitlement information missing online. Administrative processes (like how license keys are merged or split) have also changed under the new portal. Be prepared for some internal effort to adjust tooling and processes around license management.
• Support and Patches: Broadcom is honoring existing support contracts for their duration, but will not sell renewals on perpetual licenses beyond limited grace periods. After support expiry, you won’t get security patches or bug fixes for those VMware products. Running mission-critical systems on unpatched hypervisors obviously introduces risk. Broadcom’s stance is effectively “subscribe or go unsupported.” This creates a timeline for each environment: know when your support ends, because that date is when your risk profile sharply increases.
• Audit Posture: With the transition, compliance enforcement is tightening. Broadcom has signaled a stronger focus on license compliance and revenue growth. Enterprises should expect more frequent audits of VMware deployments to ensure they’re not exceeding what they’ve purchased. If you remain on legacy licenses without converting, you might come under scrutiny to confirm you aren’t using unauthorized versions or extra capacity. Even under subscriptions, the new licensing metrics (like core counts, host limits, or vSAN capacity) require close tracking to avoid inadvertent overuse. In this climate, maintaining good records and staying within entitlements is critical to avoid surprise fees or legal issues.

Checklist — New Reality Briefing

• Map your current VMware entitlements and versions: Create an inventory of all VMware products and versions you’re running and note which licenses are perpetual vs. subscriptions. This should include license keys, contract IDs, and the support end dates for each.
• Confirm support status and portal access: Check the support expiration date for each VMware license. Ensure you can access the Broadcom support portal and that all active entitlements appear there. If some licenses with expired support are missing from the portal, retrieve any archived keys or files you need from older VMware portals or your own records. Identify any dependencies on VMware support – for example, do you rely on VMware for timely patches, or have systems integrated with VMware’s update repositories?
• Identify systems with zero-tolerance for downtime or security events: List which VMware-hosted environments are most critical (e.g., production clusters for core business apps). You cannot afford to run these without vendor support or security fixes for long. Knowing this will guide whether those systems must migrate to a subscription or other solution sooner rather than later.

Pro Tip: Treat this as a program, not a one-time purchase. Moving beyond perpetual licenses isn’t just buying a new SKU – it’s a strategic program.

Plan and execute it like a project with workstreams for technical changes, contract negotiation, and risk management. Involve stakeholders from IT, security, finance, and procurement early, and give the initiative a clear executive mandate.

Your Three Main Options (and Trade-Offs)

With VMware’s perpetual licensing gone, enterprises have three main paths forward for each environment they run:

Option A: Stay on Legacy VMware Versions
You can keep using your VMware installations without converting to Broadcom’s subscription model. The upside is you maximize the value of sunk costs – you’ve already paid for these licenses. Your environment remains stable with no disruptive changes or migrations. There’s no new spend required upfront, and you avoid the complexity of re-platforming in the short term. However, the downsides are serious. Once your support expires, you stop receiving patches and updates so that security vulnerabilities may accumulate. Official support will be unavailable, leaving your ops team alone for troubleshooting or critical fixes. You may also face compliance risks; while you have a legal right to use perpetual licenses, auditors might scrutinize unsupported software usage, especially if any usage exceeds your purchased quantities or violates contract terms. In short, staying legacy is viable only if you thoroughly mitigate the risks, and even then, it should be a bridge, not a destination.

Option B: Convert to VMware Subscription
This is the “stay with VMware” path under Broadcom’s terms. You would transition your licensing to a subscription contract (for vSphere+ and the new bundles like VMware Cloud Foundation or vSphere Foundation). The clear benefit is continuity and currency: you get the latest features and improvements and retain full vendor support for any issues. Broadcom’s compliance audits become routine rather than high-stakes events, since you’ll be properly licensed under the new model. Theoretically, this option minimizes operational risk because your platform stays current and supported. The drawbacks are largely financial and contractual. Subscription licensing can carry a higher total cost of ownership over 3-5 years compared to running perpetual licenses you already own. Broadcom may offer discounts initially, but you could face price increases (“uplifts”) at renewal time. Additionally, most Broadcom deals require committing to multi-year terms, which locks you in and could limit flexibility if your strategy or budget changes. You must negotiate carefully to avoid unexpected cost escalations and secure terms that allow

Option C: Evaluate Alternatives to VMware
The third path is to explore alternative solutions for virtualization and infrastructure. This could mean migrating some workloads to public cloud or a different hypervisor (like Hyper-V or an open-source KVM solution), adopting a hyperconverged infrastructure platform (for example, Nutanix AHV), or containerizing certain applications to reduce dependence on VMware entirely. The advantage here is regaining leverage and potentially lowering long-term costs. By seriously considering other platforms, you might find a solution that meets your needs at a lower price point or with more favorable licensing. Even if you don’t switch everything, having a credible Plan B strengthens your hand in negotiations with Broadcom – it creates price pressure on them to offer a fair deal. It also positions your organization for more strategic independence so you’re not overly beholden to one vendor’s whims in the future. The disadvantages revolve around execution: migration risk and effort. Moving off VMware isn’t trivial – it requires detailed planning, testing, and often retraining staff. There’s a risk of downtime or performance issues in transitioning critical systems. Your team will need new skills to manage the alternative technology, and an initial investment in new tools or cloud resources. Adopting alternatives is usually a phased, multi-step journey, not an overnight flip. So while it can yield savings and strategic benefits, it demands commitment and has its own costs and risks to manage.

Pro Tip: One size does NOT fit all—you can mix and match strategies. The best answer might differ for each system or application.

Many enterprises will adopt a hybrid approach: for example, they will keep some stable, low-risk systems on legacy VMware for now, convert their most critical systems to subscription for full support, and start migrating development or less critical workloads to an alternative platform.

Don’t assume you must pick only one option enterprise-wide. Segmentation is key.

Decision Matrix — Pick the Path Per System

Not sure which option to choose for a given system? Use a per-system decision matrix. Classify each environment by its profile (criticality, stability, growth, budget sensitivity), then see which path is generally the best fit:

In this table: ✅ means recommended, ⚠️ means risky or last resort, and ⚪ means neutral or case-by-case. For example, a mission-critical system with a strict uptime SLA is generally too risky to leave on an unsupported legacy version (hence ⚠️ under Stay Legacy).

Pro Tip: Segment first. Decide second. Before making any big moves, break your VMware estate into categories (by business criticality, technical requirements, lifecycle stage, etc.).

This segmented approach prevents knee-jerk, one-size-fits-all decisions and lets you apply the right strategy to each case.

If You Stay on Legacy — How to Reduce Risk

If you stay on legacy VMware versions (at least temporarily), your number one concern is mitigating risk. You must shield your environment through configuration and defensive measures with no new patches.

Here’s how to reduce risk on unsupported VMware systems:

• Freeze on a stable version and disable auto-updates: Pick a VMware version/build known to be stable for you, and stick with it. Disable any automated update checks or version upgrades. You don’t want an accidental update you aren’t entitled to (or that introduces a bug you can’t easily fix without support). Staying static buys you predictability – you’re running a well-understood configuration.
• Isolate and harden the network: Treat legacy VMware hosts as high-risk assets. Isolate them from the open internet and from less-trusted networks. Lock down inbound and outbound connections (restrict egress so the hypervisor or VMs can’t reach out to download anything malicious). Use firewalls, VLANs, or DMZ approaches to cordon off these systems. The goal is greatly reducing exposure to threats since you won’t get security patches for any newly discovered vulnerabilities.
• Layer on security controls: Compensate for the lack of vendor fixes by deploying strong endpoint and network security around the legacy environment. For example, ensure you have up-to-date endpoint detection and response (EDR) agents on VMs to catch malware. Use intrusion detection/prevention systems (IDS/IPS) at the network level to spot suspicious traffic. Apply strict access control lists so only authorized management workstations can reach the hypervisors. These layers help catch or prevent exploitation of vulnerabilities that remain unpatched.
• Archive everything you might need: Take VMware’s documentation and support knowledge base with a grain of salt – once your product is out of support, those resources might not be there forever. Download and archive installers, patches, license keys, and documentation for your VMware version to an internal repository. Keep proof of your license entitlements (contracts, keys) filed safely. If you need to rebuild a host or add a component, you aren’t stuck because VMware’s site no longer provides the software or your license info.
• Test and monitor vigilantly: Just because you’re not getting new updates doesn’t mean you operate on autopilot. Run regular health checks on the environment. If you have a lab setup, test disaster recovery procedures with the legacy software to ensure you can recover if something fails. Monitor those systems closely (performance, logs, anomalies) since you won’t have vendor support to rely on, so early detection of issues will be on you.

Checklist — Legacy Hardening (if running VMware without official support)

• Quarterly vulnerability scans: Run security scanning tools on your VMware hosts and management network at least every quarter. Identify known vulnerabilities in the hypervisor, VM tools, or management interfaces. This helps prioritize your compensating controls and justifies urgent upgrades if a risk is too high.
• Strict change control on hypervisor hosts: Freeze non-essential changes. If you must reconfigure or tweak something on ESXi hosts or vCenter, put it through a rigorous change management process. With no vendor to fall back on, even minor changes should be carefully evaluated and tested to avoid knocking a host offline.
• Document “compensating controls” for each risk: Write down how you mitigate every significant security or operational risk you accept by staying on legacy. Example: “No patch available for vulnerability XYZ – mitigated by firewall rule ABC and network segmentation.” This documentation guides your team’s actions and will be useful evidence in audits or security reviews to show that you have addressed the risk responsibly.

Pro Tip: When you stop getting vendor patches, your security layers must take over that job. Be intentional in designing a fortress around your legacy VMware environment. The effort and cost to harden and monitor will be your “tax” for not paying VMware subscription fees – budget and plan accordingly.

If You Convert — How to Negotiate Smart

If you decide to transition to VMware’s subscription model under Broadcom, do so on your terms.

Here’s how to approach the conversion in a way that protects your interests:

• Engage early and leverage your current investments: Don’t wait until the last minute (like a week before support expiration) to start conversion discussions. Begin well in advance to avoid desperation. In negotiations, ask for conversion credits for your existing perpetual licenses. Broadcom wants to move you to subscription – use that as leverage to say, “We already paid for these licenses; give us a fair credit towards the subscription cost.” For example, some customers negotiate reduced first-year rates or one-time credits based on the original license spend.
• Secure price protections (no surprises mid-term): A key risk of subscriptions is escalating costs. Negotiate caps on annual price uplifts. For instance, if you sign a three-year deal, get a clause that limits any year-over-year price increase to a certain percentage (or even better, fixed pricing for the term). Also, clarify renewal terms beyond the initial period – if Broadcom’s standard terms are vague, push for an explicit cap on renewal pricing (e.g., “no more than X% increase at first renewal”). The goal is to avoid a situation where you’re locked in and hit with a massive price hike later.
• Align contracts to your budget cycles: Try to co-term and align renewal dates with your fiscal year or planning cycles. If you have multiple VMware products, consolidate them so they renew simultaneously, or at least on predictable schedules. This makes budgeting easier and gives you a single negotiation window to potentially bundle for better discounts. Broadcom might want to upsell additional products; by co-terming, you ensure those come up simultaneously rather than piecemeal (which can lead to “add-on creep” without holistic oversight).
• Start with a pilot, then expand deliberately: You don’t have to convert everything in one big bang. Consider doing a pilot conversion on a limited scope first – for example, convert one cluster or one environment to subscription and see how it goes (technically and contractually). Use this pilot to validate that the new licensing works as expected, that you’re getting the support quality promised, and that your cost model holds. Structure your agreement with Broadcom to allow scaling up in phases. For instance, a contract might allow you to add more hosts in quarter two at the same negotiated rate after an initial batch in quarter one. This phased approach reduces risk and keeps some leverage in your hands – Broadcom still has to earn your additional business.
• Negotiate service and support terms too: Price is not the only factor. If converting, ensure the support level (SLAs) meets your needs. See if you can get enhanced support or guarantee response times for mission-critical environments. Also clarify transfer rights or cloud use rights if you plan hybrid deployments. Since you’re effectively rewriting your VMware contract, pin down all important terms now.

Pro Tip: Your history as a long-time VMware customer is bargaining power. Use it. Remind Broadcom of your perpetual investment: “We’ve spent $X over Y years on VMware; we could just stay on that investment a bit longer.”

If they sense you have the will (and option) to ride out your existing licenses, they’ll be more inclined to offer a sweeter deal to get you on subscription.

In negotiations, always have alternative plans (even if that alternative is “we’ll just hold off and use what we have”). Leverage the fact that Broadcom needs customers to renew as much as you need support – it’s a two-way street.

If You Explore Alternatives — Make It Credible

Exploring alternatives to VMware is a smart move, even if you ultimately stick with VMware for some systems. But to be effective, your exploration must be serious and credible.

Here’s how to do it right:

• Shortlist realistic alternative platforms: Identify which solutions could feasibly run the workloads VMware currently handles for you. This might include other hypervisors or virtualization stacks (Microsoft Hyper-V, open-source KVM distributions, Proxmox VE, Nutanix AHV, etc.), hyperconverged infrastructure (HCI) solutions, or moving some workloads to public cloud or managed Kubernetes if appropriate. Don’t list every tech under the sun – pick a few that align with your environment and application needs. Consider factors like what your team is familiar with, what your hardware supports, and where the industry is going. The aim is to focus your evaluation on 2–3 strong contenders.
• Build a 3-year TCO comparison: For each alternative, work up a three-year total cost of ownership model and compare it to the projected cost of staying with VMware (whether legacy or subscription). Include license or subscription costs of the alternative, any new hardware needed, training or hiring costs, migration services, and support. Also factor in any savings (for example, an open-source solution might save licensing fees, but perhaps you’d spend more on support staff – include it all). Doing this homework tells you if an alternative is economically attractive and arms you with data in discussions with leadership or Broadcom. If you can say “Solution X would cost us $Y over three years versus Broadcom’s offer of $Z,” you have a strong case to switch or push VMware for a price match.
• Conduct a proof-of-concept (PoC): Don’t commit to an alternative based only on brochures. Test it in a contained environment. Take a representative sample of workloads (maybe a dev/test environment or a low-stakes production service) and migrate it to the alternative platform. Run it for weeks or months to gauge performance, stability, and management overhead. This PoC will surface practical challenges (integration issues, skill gaps, etc.) that you can address in your plan. It will also demonstrate to skeptics (internal or external) that you can operate without VMware.
• Maintain parallel negotiations: While you evaluate other platforms, keep the dialogue open with Broadcom/VMware. One common mistake is telling VMware “we’re leaving” too early and cutting off communication. Instead, quietly progress your alternative plans while negotiating with Broadcom in good faith. Each side should know you have other options, but you don’t need to broadcast all details. The fact that you’re genuinely exploring alternatives will usually reach Broadcom through subtle signals (delayed responses, pointed questions about exit terms, etc.). Ideally, you want to reach a point where either the alternative proves worthy and you switch, or Broadcom senses your credible intent and offers a more favorable deal to retain your business. Either outcome is a win for you – but only if your alternative evaluation is real.

Pro Tip: A bluff won’t cut it – you must be willing and able to follow through on moving to an alternative. Alternatives give you leverage only when the vendor believes you’re serious.

That belief comes from your actions: engaging in PoCs, involving your architects in migration plans, and not behaving like a captive customer. Even if you prefer to stay with VMware, the mere fact that you could leave will change the tone of negotiations.

Third-Party and Hybrid Support Options

Another avenue to manage the transition is using third-party support for VMware.

This can safely extend the life of your legacy deployments or supplement a partial move to subscription.

Here’s how third-party and hybrid support models can help:

• Third-party support for legacy VMware: Independent support providers (specializing in enterprise software) offer support services for VMware products that VMware/Broadcom no longer supports. These firms, such as specialized support vendors, can provide services like troubleshooting, guidance on known issues, and even security alerts or workarounds for older VMware versions. They don’t have the source code to issue patches, but they often employ ex-vendor engineers who understand the products deeply. If you plan to stay on VMware 6.x or 7.x without official support, contracting a third-party support provider for a few years can be wise. It’s typically cheaper than a vendor subscription and buys you time to upgrade or transition.
• Define the scope of support clearly: If engaging third-party support, nail down what they will and won’t do. Generally, third-party support can handle break/fix tickets, usage questions, configuration assistance, and guidance on critical vulnerabilities (like telling you how to mitigate a known exploit via config changes). They usually also help with licensing compliance questions since they know you’re out of contract with the vendor. However, understand that they cannot deliver new patches or major upgrades. If a brand-new vulnerability is found, at best, they’ll give mitigation steps or monitor if the community finds a fix. Ensure you also clarify how they handle severity-1 emergencies and the SLA for response and resolution. Treat it as you would any support contract: know what you’re paying for.
• Retain in-house VMware expertise: If you pivot to third-party support or even a hybrid model (some systems on VMware subscription, some not), keeping your skilled VMware admins and engineers close is critical. Third-party vendors can guide and advise, but your internal team will still do the heavy lifting day-to-day and during incidents. Make sure you don’t downsize your VMware knowledge too early. In fact, consider training some team members specifically in troubleshooting without vendor help – for instance, deeper training in vSphere diagnostics, or how to manually apply workarounds. Combining your seasoned internal team and third-party support as backup can be quite effective.
• Use savings strategically: The savings from third-party support (versus paying Broadcom’s subscriptions) can be substantial – often 50% or more cheaper. Reinvest those savings wisely. One smart play is to funnel saved budget into your modernization projects or alternative platform trials. Another is to fund a future VMware subscription for the subset of systems that truly need it. For example, you might keep three older clusters on third-party support and save enough money to afford subscriptions for two new clusters that require the latest features. In essence, support where you must, and save where you can, balancing cost and risk across your environment.

Pro Tip: Not all systems need premium vendor support. Evaluate which parts of your VMware estate are stable and well-understood – those could be candidates for third-party support or no support (with heavy hardening).

Meanwhile, identify areas where you cannot risk even a day of downtime or where new features are vital – those are where you invest in official support or faster upgrades.

This mix-and-match approach can dramatically cut costs while keeping overall risk within acceptable bounds.

Compliance & Audit Readiness in Any Path

Whichever strategy you pursue (stay, convert, or migrate), license compliance and audit readiness must remain a priority. Broadcom’s acquisition doesn’t change that VMware environments are subject to license rules and audits.

Here’s how to stay clean and prepared:

• Keep all entitlement records organized: Ensure you have a secure repository of all your VMware license documents – contracts, purchase orders, invoices, license keys, support renewal confirmations, EULA terms that were in effect when you bought the licenses, etc. If an audit comes or you need to assert your rights (say, to prove you have a perpetual license for vSphere 7 even if Broadcom’s portal doesn’t show it), these documents are your evidence. Don’t rely on VMware’s old Customer Connect portal (now defunct) or Broadcom’s new portal alone – maintain your copies of everything.
• Regularly reconcile licenses to deployments: Map out how your VMware licenses map to actual usage. For instance, if you had 100 CPU licenses for vSphere Enterprise Plus, ensure you’re not running 120 CPUs worth of ESXi hosts in production. Check those usage numbers if you have vRealize or vSAN licenses with capacity metrics. Do this license vs. usage audit internally every few months. If you spot any over-use (perhaps you stood up a new host and forgot to license it properly), correct it proactively by decommissioning, reallocating licenses, or informing procurement to purchase additional ones. The worst time to discover you’re 20% over-deployed is during an official vendor audit.
• Centralize audit communications: If Broadcom initiates a license audit (or even a friendly license review), channel all communications through a single point person or team on your side. This could be someone in IT asset management, compliance, or procurement who is well-versed in your VMware licensing. Having one owner prevents different individuals from inadvertently providing conflicting or extra information. This person/team should log every interaction, and ideally loop in your legal counsel early, especially if it’s a formal audit. A unified front ensures you respond accurately but without volunteering more than necessary.
• Scope and limit data shared: In an audit, you’ll typically receive a data request – be deliberate about what you share. Only provide scope-relevant data. For example, suppose the audit is about vSphere licensing. In that case, you likely need to share host CPU counts and license keys for vCenter/ESXi – you probably don’t need to share every installed software on every VM or details of unrelated environments. If you run multiple sites and the audit is focused on one region, consider limiting data to that region. Always review data for accuracy and completeness before handing it over. Keep copies of exactly what you provided. This way, if the auditor later says, “We see 101 CPUs used but only 100 licensed,” you can cross-check against your records confidently.
• Stay within bounds of your entitlements: Avoid doing things that clearly violate license terms, because those are indefensible in an audit. For instance, don’t use a single-use license in two places concurrently, don’t apply a license key meant for one product to another, or use evaluation licenses beyond their allowed period in production. It sounds obvious, but admins sometimes do quick fixes that create compliance exposure under pressure. Set internal policies to prevent that – e.g., require any license-key use in production to go through the asset management team.

Pro Tip: Documentation is your compliance currency. Better documentation usually wins or mitigates the outcome if you ever face an audit or a licensing dispute.

Treat every license purchase like a financial audit record—keep it organized and updated.

Also, document your internal compliance practices (like quarterly self-audits, etc.). Showing auditors that you have a strong internal compliance process can sometimes lead them to soften their approach or give you the benefit of the doubt.

Budgeting the Transition — Avoid Shock

A transition away from perpetual licenses requires financial foresight.

A poorly planned move could lead to budget shocks – either overspending on subscriptions or costly emergencies if something breaks and you must reactively fix it. Follow these budgeting best practices to stay in control:

• Model out multi-year costs for each path: Develop a simple financial model projecting your VMware-related costs for different scenarios over the next 3–5 years. One scenario could be “stay on legacy as long as possible,” another “convert all to subscription immediately,” and perhaps a hybrid scenario “stagger conversion and some migration to alternatives.” Include everything: license or subscription fees, support costs, hardware refresh if due, potential third-party support fees, etc. Don’t forget to factor in things like expected growth (if you anticipate adding more VMs or hosts, what does that do to costs under each model?). This exercise will highlight the long-term cost difference. You might find, for example, that staying on legacy is cheapest for two years, but then risk forces a sudden, expensive change in year 3. Or that subscription costs are steady but significantly higher over time. Knowing this helps you choose a course your organization can afford and justify.
• Account for training, tools, and migration expenses: It’s not just licensing dollars. If you move to subscription, you might need training on new VMware features or Broadcom’s portals and processes if you evaluate alternatives, plan for pilot costs, possibly consulting, data migration tools, or downtime costs, and retrain staff. Even staying on legacy may incur expenses like beefing up security tools or hiring short-term experts to audit your setup. Include these in your budget plan. They can be non-trivial, and having a realistic estimate upfront is better than being surprised later.
• Plan for contingencies and growth: Set aside a contingency budget for the unexpected. This could cover a situation where you need to suddenly buy a few VMware subscriptions for an urgent project you didn’t foresee, or perhaps to quickly license additional capacity if usage spikes (to stay compliant). Also consider that if your company grows (new projects, acquisitions, etc.), you may need more virtualization capacity – have a buffer in your budget for scaling either VMware or alternative infrastructure. And if you’re betting on an alternative that might underperform, have a reserve to address any “plan B” if things take longer or cost more than anticipated.
• Revisit and adjust quarterly: Treat the transition budget as a living plan. Every quarter, review actual spend vs. projections. If you’ve moved some workloads to the cloud, are you realizing the savings expected, or are costs higher? If you negotiated a subscription, are any unplanned charges cropping up (maybe using more licenses than thought)? Check if the distribution of systems across legacy vs. subscription vs. alternative is still optimal and adjust the next quarter or year’s plan accordingly. Regular check-ins will help avoid drift – you can catch it, say, if too many systems stayed legacy for too long and now represent a risk that needs funding to fix.
• Communicate early with finance: This shift often moves expenses from CapEx to OpEx, so loop in your finance team early. Explain the new model to them and how you plan to control costs. CFOs and budget owners hate surprises—showing them you have a multi-year view and a handle on the variables will give them confidence. If they see the long-range payoff, it may also help secure funds for the upfront investments (like those PoCs or needed upgrades).

Pro Tip: Predictable costs beat one-time discounts in the long run. It can be tempting to convert now if Broadcom offers a big one-time discount or if an alternative vendor offers a low year-1 price.

But look at years 2, 3, and beyond. It’s often better to accept a slightly higher known cost that stays stable than a rock-bottom first-year price that skyrockets later.

Aim for cost stability and transparency. This will make the plan easier to sell internally and avoid painful budget overruns.

Step-by-Step Action Plan (90 Days)

Time is of the essence once you know perpetual licenses are ending.

Here’s a 90-day action plan to jump-start your transition program and preserve your leverage:

• Days 0–14: Assess and Prioritize. In the first two weeks, inventory all your VMware deployments and licenses. Document what you have (versions, support status, criticality of each system). At the same time, each system should be classified by how critical and tolerant it is to changes. For example, label systems as “Mission-Critical – No Change Tolerance,” “Important – Some Change OK,” “Legacy – Could Migrate,” etc. This inventory and classification are the foundation for all decisions. Also, identify any renewal or contract deadlines soon – mark those on the calendar now.
• Days 15–45: Define Options and Engage Vendors. Using the data gathered, develop a plan for each group of systems (you can leverage the decision matrix here). For each category, decide: are we leaning towards legacy for now, converting, or exploring alternatives? Begin initial talks with Broadcom/VMware about conversion if that’s on the table – inquire about offers, mention you’re evaluating options, and ask about any conversion credits or incentives. Simultaneously, if you’re considering any alternative platform, contact those vendors or communities to get trial licenses or quotes. Launch a focused proof-of-concept for at least one alternative solution during this period – for example, set up a test host with an alternative hypervisor or migrate a non-critical application to the cloud to see how it performs. This window is also the time to engage third-party support providers if you plan that route: solicit proposals and understand their onboarding process.
• Days 46–90: Make Decisions and Initiate Changes. In the last half of the 90-day sprint, take all the input and finalize a go-forward plan for each system. Maybe you decide, “All production stays supported – system A and B will convert to subscription, and system C will go on third-party support for a year. Non-prod X and Y will remain legacy for six more months, and new project Z will pilot on Hyper-V.” Document these decisions and get buy-in from stakeholders (IT ops, security, application owners, etc., as needed). Next, negotiate and close the necessary deals. Finalize the Broadcom subscription contract for the ones you’re converting – push to get those pricing protections and terms in writing before signing. Sign contracts with third-party support for the systems you’ll keep legacy (and schedule the support handover). If migrating to alternatives, line up any required professional services or internal resources to start that migration. By Day 90, you want to have moved from analysis to execution: contracts signed, teams assigned to tasks, and maybe even a few conversions or migrations already kicked off. Also, implement an audit governance process now – designate that audit as a single point of contact, and ensure your license records are up to date post-changes. As you transition, you remain compliant and ready for any inquiries.

Throughout the 90 days, manage this as a formal project with check-ins and status updates. This keeps momentum and shows upper management that the team is actively controlling the situation (not being passively pushed by Broadcom’s timeline).

Pro Tip: Treat the 90-day plan as a sprint to secure leverage. Vendors often set deadlines (like “convert by the end of the quarter for a discount”).

By executing a coordinated plan quickly, you avoid last-minute scrambles and preserve your negotiating leverage (because you’re ahead of their timeline).

A well-structured sprint also means you can demonstrate progress to your executives, which helps maintain support for whatever tough decisions lie ahead.

Related articles

• VMware Subscription Migration and Cost Modeling Strategy
• Maximizing Value from Existing VMware Perpetual Licenses
• Legal Considerations of End-of-Life VMware Licensing

Five Pro Tips to Keep Control

Even after you’ve chosen a path, these five tips will help you maintain control over your VMware strategy and avoid common pitfalls:

1. Segment decisions by system, not by internal politics. Don’t let internal power dynamics force a one-size-fits-all solution. It’s okay if different departments take different paths (some convert, some don’t) if each decision is right for that system. Base decisions on technical and business needs, not on which VP shouts louder for their preference.
2. Use the value of your perpetual licenses as a pricing anchor. When negotiating, subtly remind Broadcom of the value you already own. It sets a psychological anchor that you’re not starting from zero. For instance, “Replacing our existing licenses with subscriptions needs to make financial sense given our prior investments.” This keeps discount conversations grounded.
3. Prove alternative viability before you talk about it. Internally, get your alternative solution working (even in a small test) before you use it as a negotiation chip externally. If Broadcom calls your bluff and asks, “Are you ready to move 100 VMs to Cloud X?”, you’ll know you’ve tried Cloud X and can say, “Yes, and here’s our plan.” It’s far more convincing and safer for you.
4. Pilot, measure, and scale — in that order. Roll out changes in controlled pilots first, whether it’s a new VMware subscription bundle or a new hypervisor. Measure the results and impact. Only then scale up wider. This approach catches issues early and provides data to justify further investments (or to pivot if the pilot underperforms).
5. Write protections into contracts, not just into emails. When Broadcom (or any vendor) makes a promise during negotiations – be it a price cap, a feature inclusion, a flexible term – get it in the contract language. An email from an account manager is not enforceable two years later. If it matters to you, it must be codified in legal terms. Likewise, remove any vague language that could bite you (like automatic renewals or unclear audit rights). Your contract is your safety net; make sure it reflects all the protections you negotiated.

Two Quick Checklists

Finally, here are two quick checklists to ensure you’ve covered the contractual and operational safeguards as you navigate this licensing transition:

Contract Protections Checklist (for any new agreements with Broadcom or others):

• Annual uplift cap is defined: The contract limits how much the price can increase year over year (or at renewal).
• Co-term alignment: All subscriptions/licenses renew on the same date and align with your planning cycle, avoiding scattered renewal dates.
• Exit and true-down rights: You can reduce scope or terminate parts of the agreement if needs change (especially important for subscriptions if you might decommission some systems or migrate away before term end).
• Data and migration assistance: If you leave the platform or end the contract, the vendor will provide your data/backups in a usable format and may even assist in transition (this is more relevant if considering SaaS components or cloud parts of VMware’s offerings). At a minimum, ensure there’s no lock-in of your own data.
• No forced bundling beyond use: The contract shouldn’t force you to pay for additional components you don’t intend to use. Push for clarity that if you’re only using subset X of a bundle, you aren’t be charged penalties for not using the rest, etc. Essentially, no hidden clauses that mandate you adopt more Broadcom products to fulfill the deal.

Operational Protections Checklist (to implement in your IT processes):

• Legacy hardening measures in place: For any systems you’re keeping on older versions, you have applied the security and isolation controls (as discussed) and documented them.
• Backup of keys and installers: You have offline backups of all VMware license keys, installer ISOs/binaries for the versions you use, and any important support knowledge articles or configuration notes. These are accessible even if vendor portals change.
• Single audit contact appointed: As noted, one person/team is designated to handle any license audit, and everyone internally knows to route inquiries to them.
• Quarterly TCO review scheduled: You have a recurring quarterly meeting on the calendar to review the total cost of ownership of your VMware environment (including alternative environments). This ensures you catch any cost drift and also re-evaluate strategy if necessary (for example, if an alternative becomes more viable or if Broadcom’s pricing changes).
• Pilot success metrics defined: Whenever you embark on a pilot – whether moving to subscription or testing an alternative – define what success looks like (e.g., “VM performance on Hypervisor Y within 5% of VMware” or “Operational issue resolution time under subscription support is <4 hours”). Measure against these. This prevents endless “analysis paralysis” and gives you concrete data to decide go/no-go on scaling a pilot.

Using these checklists, you cover your bases in the contracts you sign and the operations you run. This dual approach keeps you safe from surprises.

Read about our Broadcom Audit Defense Service.

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

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit