Licensing for Multi-Cloud and Cross-Cloud Scenarios with Broadcom & VMware
Introduction – Why Multi-Cloud Licensing Is Tricky
VMware now runs across AWS, Azure, Google Cloud, Oracle Cloud, and on-premises. However, VMware multi-cloud licensing can be tricky to navigate.
The way licenses are provided or charged varies by platform – some bundles include VMware licenses in the cloud provider’s service, while others require separate licensing.
If you don’t structure these arrangements carefully, it’s easy to overpay or run into compliance gaps.
Broadcom’s acquisition of VMware adds another layer, as enterprise agreements and “cross-cloud rights” must be aligned to avoid duplication and surprises. Read our complete guide to Broadcom Cloud & Hybrid Licensing Strategies: Optimizing On-Prem and Cloud Investments.
Short version: In a multi-cloud architecture, licensing can be embedded, separate, or hybrid. Without a strategy, you risk paying twice for the same VMware software or failing an audit due to misaligned terms.
Below, we outline how to manage Broadcom/VMware licensing across cloud providers, how to avoid double payment, and what clauses to negotiate for flexibility and protection.
Paths to Run VMware in Public Cloud
There are a few paths to deploy VMware environments in the public cloud, each with different licensing implications:
- Provider-Hosted VMware Stacks: Services such as Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE), Oracle Cloud VMware Solution (OCVS), and others offer a fully managed VMware stack on their respective infrastructure. Historically, these cloud provider offerings bundle the VMware software licenses into the hourly or monthly service fee. You pay the cloud provider for a VMware-capable host, and that price includes the necessary VMware licenses (vSphere, vSAN, NSX, etc.).
- VMware Cloud on AWS (VMC on AWS): VMware’s own service (now via Broadcom) runs on AWS infrastructure. This can be purchased directly from Broadcom/VMware or via the AWS Marketplace. If you buy via VMware/Broadcom, it typically falls under your VMware contract. If you buy via the AWS Marketplace or through AWS, you might leverage your AWS spending commitments, but you’re essentially still paying for VMware’s service (often bundled with licenses).
- Special BYOL Programs: With Broadcom’s recent changes, some cloud VMware services now support a “bring your own license” (BYOL) or portable license model. For example, Azure and Google Cloud have introduced options to integrate a VMware Cloud Foundation subscription purchased from Broadcom into their VMware solutions. In those cases, the cloud provider can charge you a lower rate for the bare-metal resource, and you cover the VMware software cost through your Broadcom license subscription.
Given these paths, determine a primary contracting route to maintain coherent terms. This means if you have a large Broadcom/VMware enterprise agreement (EA), you might lean toward BYOL so everything is under Broadcom’s umbrella.
Alternatively, if you want simplicity through a cloud provider’s contract, stick to the provider’s bundled service for VMware and manage it as part of that cloud agreement.
Mixing too many different purchasing paths can lead to fragmented discounts, multiple bills, and inconsistent term dates.
Does Your Broadcom ELA Cover Provider Clouds?
Suppose your organization has a Broadcom/VMware Enterprise License Agreement (ELA) or similar volume contract.
In that case, it’s critical to clarify whether usage of VMware in public cloud services is in-scope or out-of-scope of that agreement:
- In-Scope: A few customers negotiated ELAs that explicitly allow usage on certified cloud partners. If your ELA already states it covers partner-hosted VMware (or now offers portable VMware Cloud Foundation subscriptions), then your cloud usage might count toward your existing license entitlements. In this case, work with Broadcom to understand how metering and true-ups will work for cloud nodes. Ensure the ELA has a mechanism to track cloud host usage (for example, via reports from the cloud provider) so you stay compliant without incurring duplicate payments.
- Out-of-Scope: In many cases, older VMware ELAs did not anticipate these cloud services, treating them as separate. If that’s the case, your use of AVS, GCVE, OCVS, etc. would be outside your ELA (since the provider was licensing VMware on your behalf). For out-of-scope scenarios, negotiate spend linkage with Broadcom. This means if you spend money on a provider’s VMware service, that spend should be recognized or linked to your Broadcom contract for discount tier calculations. For instance, if you spend $1M on AVS through Azure, perhaps that $1M can count toward reaching a higher discount tier in your Broadcom ELA, even if it’s not directly purchased from Broadcom. Additionally, align renewal co-term dates: if your Broadcom ELA ends in 2026. Still, your Azure VMware service runs till 2027; you have the leverage to adjust one of them so that renewals and true-ups happen together, giving you a unified negotiating point.
In summary, confirm the scope of your enterprise agreement. If cloud usage isn’t covered, address it via contract addenda or pricing arrangements so you’re not left with an expensive gap or unrecognized investment.
Optimizing cloud deployments, Reserved vs On-Demand VMware Cloud Capacity: Cost Strategy Under Broadcom.
License Inclusion vs BYOL Considerations
Many provider-hosted VMware cloud solutions have historically been “license-included” – you simply pay the provider for the service, and no separate VMware license purchase is required from Broadcom. In such cases, you should not be paying Broadcom again for those licenses.
However, with Broadcom’s new direction, things are evolving:
- Embedded Licensing (License-Included): If you use a VMware service where the license is bundled (for example, the traditional model of AVS/GCVE/OCVS before BYOL options), you pay only your cloud provider. Ensure that any VMware software running in that environment is excluded from your on-premises license counts. In other words, avoid holding duplicate entitlements. If you have 100 CPUs of vSphere licensed on-premises and you move 20 of them into a cloud service that includes vSphere, you should ideally be able to drop or reallocate those 20 on-prem licenses. At minimum, ensure Broadcom isn’t charging you maintenance on those if they are not being used on-prem (perhaps via suspension or repurpose of those entitlements).
- Bring Your Own License (BYOL): Some platforms now allow or require BYOL. Where BYOL is supported, you must define how usage is counted and verified. Work with the provider to understand how many licenses a cloud host consumes (often one host corresponds to a certain bundle of vSphere/vSAN/NSX licenses). Then, establish a process with Broadcom to show proof of usage in the cloud – for example, quarterly usage reports from the cloud provider – so that you remain compliant with your license limits. It’s wise to set concurrency caps: for instance, if you have 50 portable licenses, you can run up to 50 hosts across on-prem and cloud combined. If you temporarily exceed during a migration, have that explicitly allowed for a short duration (see the DR section). Include contract language specifying the duration of overlapping usage and the notice required to true up if it becomes permanent.
- If BYOL Isn’t Possible: Not all services supported BYOL historically (Oracle’s VMware Solution didn’t support BYOL for a long time, for example). If you’re forced into license-included only (at least for now), then negotiate credits or offsets for any “stranded” licenses on-prem. Broadcom might not volunteer this, but you can request that any existing VMware licenses you own that become unused due to moving workloads to the cloud be credited toward future purchases or support extensions. Another approach is negotiating reduced maintenance fees on those idle licenses during the migration period. The goal is to avoid paying for VMware software twice during your transition.
Bottom line: Use the BYOL model where it benefits you (and if you have an ELA to leverage), but when using embedded licenses, coordinate to eliminate parallel costs.
Always document the arrangement so that both Broadcom and the cloud provider acknowledge who is covering the VMware licensing in each scenario.
Cross-Cloud Mobility and Disaster Recovery (DR)
One big promise of a multi-cloud strategy is the ability to move and protect workloads across environments – but licensing terms must support that mobility.
You’ll want to explicitly define your rights to move workloads among on-prem and various clouds and to handle DR scenarios without incurring unexpected charges:
- Workload Mobility: Ensure your agreements allow you to reassign VMware licenses across approved environments. For example, you might want to move a set of VMs from your data center to AVS in Azure, or later from Azure to Google Cloud’s VMware engine. If you purchased portable licenses (VCF subscriptions from Broadcom), confirm that these licenses are valid across all “Certified Cloud” environments and on-premises. Contractually, include a clause that no new license fees apply when moving workloads to another environment, as long as you’re not exceeding the licensed quantities in use at any one time.
- Temporary Dual-Run (Migration Periods): When migrating workloads or conducting data center failover testing, you may need to run the same workload in two locations briefly (for example, keep the on-premises VM running until the cloud VM is confirmed to be working). Negotiate a provision that allows temporary concurrent use of licenses for the same workload during migrations or testing. Typically, you might get 30-90 days of dual-use rights for migration purposes, so you can overlap without having to buy extra licenses. Define how many days and under what conditions (e.g., up to the licensed quantity, and notify Broadcom if extended) this dual-run is permitted.
- DR and Failover Usage: For disaster recovery, distinguish between cold, warm, and hot DR from a licensing perspective. If you have a DR site (or DR cloud) where VMware is running but the VMs are powered off (cold standby) or only lightly running (warm standby for replication), you should not pay full license cost for that environment. Negotiate a standby pricing model: for example, you might license only one CPU for every four in standby if they are not actively running VMs, or receive a 50% reduced rate for DR hosts until a failover occurs. Clarify that if a DR event occurs and you activate those instances, you can do so for up to 72 hours without incurring additional charges, beyond which it counts as production use. The contract should state that failover instances under X hours or days are covered under your existing licenses (or incur only a minimal fee), ensuring you’re not effectively paying twice during an emergency.
In short, make license portability and mobility a first-class right in your contracts. The ability to move or duplicate workloads temporarily is a key benefit of multi-cloud – your licensing terms should enhance rather than hinder that flexibility.
Non-VMware Broadcom Software in the Cloud
Broadcom’s portfolio includes more than VMware. You might be using Symantec security software, CA monitoring tools, or other Broadcom-owned software.
When shifting workloads to cloud infrastructure (IaaS), examine how those software licenses apply in the cloud:
- On-Prem Metrics vs. Cloud Deployment: Verify if deploying a Broadcom software product on a public cloud VM is permitted under your current license. Many traditional licenses count physical cores, sockets, or have specific hardware limitations. When running on a cloud VM, the definitions of “processor” and “server” must be crystal clear. Ideally, Broadcom would confirm in writing that running the software on IaaS (Infrastructure-as-a-Service) VMs is considered equivalent to on-premises for licensing purposes. If the vendor offers a SaaS version of the product, they might try to steer you toward it instead – negotiate the choice. For example, if you have Symantec Data Loss Prevention licensed for on-prem, you should be allowed to install it on a VM in AWS or Azure if you lift-and-shift that system, rather than being told to buy a new cloud service license.
- Metric and Instance Counting: Define how you will count usage in the cloud. If your license is based on CPU and you run on AWS, do you count vCPUs or the underlying host cores? If it’s by user or device, that might remain the same. Some Broadcom tools might have special rules for cloud (e.g., requiring license mobility rights). Get clarity to avoid an audit issue where the vendor says, “You deployed our software in a public cloud without the right license model.” Often, license mobility clauses (similar to Microsoft’s model) can be negotiated, granting you the right to use your licenses in third-party clouds.
- Audit and Tracking: Plan how you will demonstrate compliance. In a multi-cloud environment, you may tag cloud instances with the software name or maintain a centralized inventory (CMDB) that tracks the deployment of each license. Agree with Broadcom on what evidence is acceptable – for example, exports from your cloud provider listing instances running their software, or your internal logs. Include language in the contract that usage in the cloud will be measured via agreed-upon reports or tools, and that this data will be accepted as authoritative for license true-ups. This prevents disputes later if Broadcom’s auditing team has different expectations.
Data Residency & Sovereignty
Multi-cloud deployments can span multiple regions and countries, raising concerns about data residency and compliance – especially in regulated sectors (finance, healthcare, government).
When dealing with Broadcom/VMware licensing across clouds, ensure your contracts and architecture respect sovereignty requirements:
- Regional Restrictions: If your organization requires data to stay in certain jurisdictions, make sure any cloud-based VMware service you use is available in those approved regions and that both the cloud provider and VMware (Broadcom) commit to keeping data (including backups, telemetry, etc.) within those boundaries. For example, if using GCVE in Europe for sensitive workloads, ensure that VMware’s support data or vCenter telemetry isn’t being transferred to a US data center without consent. You may need a clause stating, “All customer data and metadata for the service will remain in [specified region] except as approved in writing.”
- Sovereign Cloud Offerings: Some cloud providers offer special “sovereign cloud” versions of VMware stacks or isolate the control plane. If that’s relevant, confirm if the licensing differs. There might be government restrictions on outsourcing or foreign access. Work with Broadcom to verify that they can support those deployments under your license (e.g., will support engineers with the required clearance be available, will there be any additional cost for compliant zones, etc.)?
- Export Controls and Encryption: Broadcom’s contract should align with the cloud provider’s responsibilities for encryption and export control. In multi-cloud deals, specify that vendors must comply with applicable export laws and provide assistance with any licensing documentation if software is moved across borders in the cloud. It’s also wise to have audit trails in place – contract for audit logs from the provider’s VMware environment that show admin actions and data location, which can help prove compliance during regulatory audits.
By locking down data residency and sovereignty commitments in writing, you avoid the scenario of a multi-cloud setup inadvertently violating local regulations or internal policies.
It’s better to over-communicate these requirements to both your cloud provider and Broadcom up front.
Support & SLA Across Clouds
When something breaks in a cross-cloud VMware environment, support responsibility can become a hot potato. You don’t want Broadcom and a cloud provider pointing fingers at each other while you suffer downtime.
Ensure support and Service Level Agreements (SLAs) are aligned across all parties:
- Defined L1, L2, L3 Roles: Clarify who provides each level of support. For a provider-managed VMware service (such as AVS/GCVE), the cloud provider typically handles L1 (basic monitoring and instance management) and L2 (infrastructure troubleshooting) support, and escalates to VMware (Broadcom) for L3 software issues or bugs. Make sure this arrangement is documented. As the customer, you should have a single point of contact for any issue – you open a ticket with the cloud provider, and they route it appropriately. However, also negotiate back-to-back support agreements: for example, if you have a premium support contract with Broadcom, ensure that critical issues with your cloud VMware stack receive the same level of urgency as they would on-premises. This may involve the cloud provider involving Broadcom support under an established process.
- Unified Escalation Path: Stipulate an integrated escalation process in your contracts or support plan. This might be an exhibit or SLA document that states, for instance, that if a severity-1 issue occurs (such as a VMware outage impacting production), the cloud provider will immediately involve Broadcom support. Both parties will make a continuous effort until the issue is resolved. You want the two teams working together, not waiting on each other. Joint triage calls, shared ticketing info, and clear ownership are key. The contract should grant you the right to hold Broadcom accountable if the issue is identified as a VMware software defect, even if you discovered it through the cloud service.
- Consistent SLAs: Align the uptime and response time SLAs. If the cloud service promises 99.9% uptime for the VMware environment, but Broadcom’s software support SLA allows up to a day for a response, that’s a mismatch. Push for tighter support response times for critical issues in the cloud context. Additionally, coordinate maintenance windows – for example, the cloud provider may periodically schedule upgrades or patches to VMware. You want those schedules communicated well in advance and ideally aligned with your internal change windows. Ensure the provider’s SLA and Broadcom’s obligations don’t conflict (for instance, if an upgrade by the provider introduces a bug, Broadcom should treat it with the highest priority since you had no control over the timing).
By mapping out support roles and SLAs in a multi-cloud scenario, you maintain a seamless support experience and reduce the risk of “it’s not our problem” responses. Always test these processes with non-critical issues first, so you know the escalation process works before a major incident occurs.
Commercial Constructs to Negotiate
Negotiating the commercial terms is where you can often save millions and avoid waste. In multi-cloud and cross-cloud scenarios, focus on a few key commercial constructs:
- No Double Payment: It cannot be stressed enough – avoid paying for VMware licenses twice during migrations or hybrid use. If you’re transitioning to a cloud service with embedded licenses, negotiate a grace period where you’re not paying for on-prem licenses that you aren’t actively using. Conversely, if you’re using BYOL in the cloud, ensure the cloud provider isn’t also charging you a bundled rate by mistake. Some contracts allow you to put on-prem licenses in “storage” while migrating, or Broadcom might provide short-term licenses at no cost to bridge a move. Ensure that every VMware instance you run is paid for only once.
- Portability and Credit Mechanisms: Given that your footprint may shift among on-prem and various clouds, build in portability of spend. For example, if you pre-paid for 100 VMware licenses on-premises but end up moving 20% of your workloads to a cloud service, you could negotiate a credit or conversion: perhaps convert 20 of those licenses into a cloud subscription or receive a service credit from Broadcom that you can apply to the new environment. Similarly, if you commit to a certain spend with Broadcom, they might offer credit if you decide later to use a partner cloud service instead of buying more on-prem licenses. These mechanisms provide financial flexibility as you adjust your architecture.
- Combined Discount Tiers: If you maintain an on-prem environment and use cloud VMware services, try to aggregate the spend to hit higher discount brackets. Broadcom typically offers better pricing at higher spend volumes. Your argument should be that the total spend on VMware technology (whether through Broadcom directly or via a cloud provider) represents your commitment. Some customers negotiate a “Most Favored” pricing clause, whereby if the combined spend would have qualified for a larger discount, Broadcom will retroactively or prospectively apply it. At a minimum, if you have an ELA and also do significant business on, say, AVS, push Broadcom to acknowledge that combined value in renewal negotiations.
- Reserved vs. On-Demand Flexibility: Cloud VMware offerings often feature Reserved Instances (RIs) with 1-3 year commitments at lower rates, versus on-demand hourly pricing for greater flexibility. Work out a strategy that matches your usage pattern – and negotiate commitment adjustments if possible. For instance, maybe you commit to 10 hosts for a year on AVS, but want the ability to reduce to 8 or burst to 12 at certain times. Try to get terms like an annual adjustment window (perhaps you can decrease your reserved count by 10% without penalty at renewal time) or a right of first refusal to extend reserved terms at the same price. Additionally, consider seeking commitment discounts across providers if you use more than one cloud VMware service. While Azure, Google, etc., may not coordinate with each other, Broadcom might offer a better deal on portable licenses if you commit to a certain total across all platforms.
In essence, structure your contracts so that money spent on VMware technology is fungible across environments and you’re rewarded (not penalized) for diversifying your cloud approach.
The goal is to achieve a predictable and optimized spend, whether workloads run on-premises or in any approved cloud.
Checklist – Multi-Cloud Licensing Must-Haves
Use this checklist to ensure you’ve covered the critical bases in your multi-cloud VMware licensing strategy:
- Scope & Coverage: Verify your Broadcom ELA or license agreement explicitly covers (or excludes) each cloud provider’s VMware service. If not covered, include an addendum or linkage to encompass those environments, or at least reference them for spend aggregation.
- No Double Payment: Put it in writing that any workload running in a provider’s VMware service with included licensing does not require a duplicate Broadcom license. If using BYOL, ensure the cloud service fee is reduced accordingly. Confirm a policy for suspending or reallocating on-prem licenses as you migrate.
- Portability & Dual-Use Allowances: Ensure you have the right to move licenses between environments and to run concurrently during permitted periods. Include clauses for migration grace periods and DR dual-run so you won’t be out of compliance in those scenarios.
- Co-Termination of Agreements: Align the end dates of your major contracts. If your on-prem VMware ELA ends in December 2026 but your Azure contract for AVS runs to 2027, try to adjust so they co-term. Unified renewal negotiations give you leverage and prevent you from being locked into an awkward situation.
- Unified SLA & Support: Obtain a combined support plan or, at the very least, a documented process that bridges Broadcom and the cloud provider. Make sure SLAs (uptime, response) are consistent, and you know exactly who to call for any part of the stack.
- Data Residency & Compliance: Double-check that all contracts (Broadcom and cloud) reflect your data residency requirements. Every cloud VMware deployment should have designated regions and compliance provisions matching your needs, to avoid regulatory surprises.
Keeping this checklist in mind will help you cover the essential elements when planning a multi-cloud deployment involving VMware and Broadcom licensing.
Sample Clause Snippets (Plain Language)
When negotiating with vendors, it helps to propose clear contract language.
Here are some sample clause snippets in plain English that capture the protections you might need:
- Multi-Cloud Portability: “Customer may move licensed workloads among approved VMware partner cloud services and on-premises environments without requiring new or additional VMware license purchases from Broadcom, provided total concurrent usage does not exceed the quantities licensed.”
- No Double Payment: “For any VMware software bundled within a third-party cloud service consumed by Customer, Customer is not required to maintain separate Broadcom licenses for the same usage. Broadcom will not count such cloud-embedded usage against Customer’s on-premises entitlements.”
- DR Rights: “Customer may utilize up to [X] VMware hosts as disaster recovery standby capacity. Such hosts, if not running production workloads except during testing or an actual disaster event, shall be excluded from license counts or billed at a nominal standby rate. Any failover use under 72 hours shall not incur additional licensing fees.”
- Spend Linkage: “Any spend on VMware technology via cloud provider services (e.g., Azure VMware Solution, Google Cloud VMware Engine) by Customer shall be aggregated with direct Broadcom/VMware spend for volume discount calculations and commitment credits in Customer’s agreement.”
- Co-Term and Renewal Alignment: “Subscriptions or services for VMware software provided via third parties will be aligned to co-terminate with Customer’s Broadcom Enterprise Agreement on [date]. Future renewals shall be negotiated concurrently to ensure consistent terms and pricing across environments.”
- Audit Evidence: “The Parties agree that usage data and reports provided by approved cloud providers, combined with Customer’s internal records, are sufficient to evidence VMware software usage for compliance verification. Broadcom will accept such documentation instead of on-premises audit processes for cloud-hosted environments.”
Each of these clauses can be adjusted to fit legal wording, but the key is that they clearly state the customer’s rights and protections in a multi-cloud scenario. Including them (or similar language) in your contracts helps prevent ambiguity later.
FAQs
Q: Do I still need Broadcom licenses when using Azure VMware Solution, Google Cloud VMware Engine, or Oracle Cloud VMware Solution?
A: If you use these provider-managed VMware services with the license included, you generally do not need to buy separate VMware licenses from Broadcom for that usage. The cloud provider is effectively selling you a VMware-embedded service. However, with Broadcom’s recent policy changes, new deployments on those services may require you to bring your own VMware Cloud Foundation subscription from Broadcom (a BYOL model). In that case, yes, you would purchase portable licenses from Broadcom to use in the cloud, but then the cloud provider should give you a lower price on the infrastructure (since they’re not providing the VMware license). To avoid any doubt, coordinate with both Broadcom and the cloud provider so you’re not double-purchasing licenses. Existing environments with bundled licenses can typically continue under their original terms until the renewal date or a specified transition date.
Q: Can I move workloads between clouds (or cloud and on-prem) without re-licensing?
A: Workload mobility is possible, but you need the right licensing in place. If you have portable licenses via Broadcom’s VMware Cloud Foundation subscription, you can move those licenses between environments (on-prem ↔ cloud) as needed – that’s a key benefit of BYOL. You just need to ensure you don’t exceed your licensed quantity at any given time. If you’re using provider-included licensing, you can migrate a VM from on-prem to, say, AVS, but at that point the on-prem VM should be powered down (or its resources freed) so you could potentially re-use that on-prem license elsewhere. The best practice is to include a contractual clause that allows for the reassignment of licenses across environments. Practically, short-term overlaps for migration are usually tolerated (or should be negotiated as such). The key is that, in the long term, a workload shouldn’t consume a VMware license in two places. Yes, you can move without buying new licenses if you’ve planned correctly – just make sure to document the move, update your inventory, or notify Broadcom if required.
Q: How are DR tests and failovers treated from a licensing perspective?
A: Disaster Recovery (DR) scenarios should be handled with special licensing considerations. For periodic DR tests, you spin up systems in a secondary site or cloud, run them briefly, then shut them down – this should not force you to permanently license that secondary capacity at full cost. Most customers negotiate either an allowance (e.g., up to 30 days of DR testing per year is included) or a reduced metric (such as counting only 1/4 of the resources if they’re only for standby). In an actual failover (a real disaster), you’re obviously going to run production in two places for a while. A fair approach is that Broadcom only charges for one site at a time. Perhaps after 72 hours of concurrent use, you’d inform Broadcom which site is now active in production. Always clarify this in the contract. In summary, DR tests are typically exempt from full licensing or allowed on a short-term basis, and emergency failover usage is either free for a short window or comes out of a pre-agreed pool of “DR licenses” you’ve arranged. Don’t wait for an audit to discuss this – bake it into the agreement so you can confidently execute DR drills.
Q: How do I align cloud service renewals with my Broadcom ELA?
A: Aligning renewal timelines is crucial for a holistic negotiation. If your Broadcom ELA is up for renewal at a different time than your cloud contracts (Azure, Google, etc.), you lose leverage because you’re dealing with them separately. To fix this, you have a couple of options: (1) Adjust the term of one contract to sync with the other (for instance, extend your Broadcom ELA to match the cloud service term, or vice versa). Broadcom might allow a short extension or a custom term length to facilitate this. (2) If adjusting the term isn’t possible immediately, negotiate a coterminous addendum – an agreement that even though, say, your cloud service might technically renew later, Broadcom will treat your spend holistically and perhaps provide pricing protections until everything aligns. Also, use linkage clauses as mentioned: e.g., “the discount level achieved in the Broadcom ELA will apply to any renewal of the cloud VMware service for the same term.” The aim is that by the next cycle, you will bring all deals to the table together. This way, you can view your entire VMware estate (on-premises and cloud) and optimize licenses and costs in one go with Broadcom and any cloud marketplace vendors.
5 Actionable Recommendations
To wrap up, here are five concrete steps and negotiation tips to help you master multi-cloud licensing for VMware under Broadcom’s regime:
- Choose a Primary Contracting Path: Determine who will be your primary point of contact for VMware licensing – Broadcom or the cloud provider. Then align others via linkage clauses. For example, if Broadcom is the primary (ELA with portable licenses), use BYOL for the cloud and ensure the cloud provider offers BYOL pricing. If the cloud provider is your primary choice (you prefer their billing), ensure Broadcom is aware of that spend. This prevents you from getting pulled in different directions and leverages your total spend.
- Lock in No Double Payment & Portability: In your contracts, explicitly prohibit double payment for licenses. Ensure migration and DR clauses allow portability of licenses and temporary dual use. Don’t assume the vendor will “do the right thing” informally – put the terms in writing so that whenever you shift a workload, you’re confident you won’t be billed twice or blocked by a license technicality.
- Tie Cloud Usage into Enterprise Discounts: Link your cloud VMware spend into your Broadcom ELA for volume discounts and co-term dates. If you have a large VMware Cloud on AWS deployment or use AVS, bring that data to Broadcom – negotiate as if it were all one big account. This can elevate you to higher discount tiers and ensure any pricing protections or caps in your ELA also benefit your cloud usage. Also, plan renewals together so you can make trade-offs (perhaps you reduce some on-premises licenses but increase cloud subscriptions, with the net spend remaining the same – the deal should accommodate that).
- Define Unified Support & SLAs: Push for a single support model across Broadcom and your cloud providers. It may require additional effort to obtain a joint support addendum, but it’s worth it. Clearly document escalation paths in one place. In an exhibit or SLA document, list the following information: contact details, response times, and responsibilities for each scenario (e.g., on-premises issue, cloud infrastructure issue, VMware software bug, etc.). Require the vendors to communicate and not leave you stuck in the middle.
- Bake in Data Residency and Audit Provisions: As you move to a multi-cloud environment, compliance is key. Include data residency commitments for each environment and ensure Broadcom’s and the provider’s contracts don’t conflict on this. Also, agree on audit provisions for cloud usage now – e.g., that a quarterly usage report will satisfy audit requirements. By doing so, you prevent future headaches, such as scrambling for data or facing compliance disputes across jurisdictions.
Following these recommendations will set a strong foundation for your multi-cloud and cross-cloud VMware strategy.
With careful planning and the right contractual terms, you can enjoy the flexibility of multiple clouds without the cost overruns or compliance nightmares that often come with licensing missteps.
Take a strategic, proactive stance – and don’t hesitate to negotiate hard for the terms you need. Your multi-cloud future should be powered by technology advantages, not tripped up by licensing pitfalls.
Read about our Broadcom Licensing Consulting.
