Diversifying Virtualization to Reduce Risk
Virtualization is the backbone of modern enterprise infrastructure, and VMware has been the de facto standard in this space for a long time. However, recent changes in VMware’s ownership and licensing model have introduced new risks for organizations that rely solely on VMware.
Broadcom’s acquisition of VMware in late 2023 ushered in steep price hikes and a shift to subscription-only licensing, catching many customers off guard.
For example, some organizations reported VMware licensing cost increases of 150%, 300%, or even 500% after Broadcom’s changes. These abrupt shifts underscore the danger of vendor lock-in, when one supplier can unilaterally change terms to the customer’s detriment.
In this environment, CIOs are wise to re-evaluate their virtualization strategy. Diversifying virtualization platforms – essentially adopting a multi-hypervisor or hybrid cloud approach – can reduce dependency on any single vendor. By exploring alternatives to VMware and developing a credible “exit strategy,” CIOs create options for their business.
This playbook provides a strategic overview of why and how to diversify virtualization platforms in response to Broadcom’s changes to VMware licensing. It offers guidance on evaluating alternative hypervisors for specific use cases, piloting them in a low-risk manner, and leveraging an exit plan to strengthen negotiating power.
Finally, it addresses the risks of diversification (such as training, tools, and migration costs) so that IT leaders can make informed decisions. The goal is to help CIOs protect their organizations from unforeseen cost shocks and ensure flexibility for the future.
Broadcom’s VMware Licensing Shake-Up: Why Change is Needed
Broadcom’s takeover of VMware brought significant changes to VMware’s product packaging and pricing.
Key impacts of this licensing shake-up include:
- Soaring Costs: Broadcom introduced new VMware subscription bundles that dramatically increased costs for many customers. Industry reports cite increases of 150% to 500% in licensing fees for organizations renewing under Broadcom’s terms. In one extreme case, a large enterprise faced a 1,050% jump in its VMware bill and was told to accept it or leave. Such spikes can wreak havoc on IT budgets and long-term plans.
- End of Perpetual Licensing: VMware, under Broadcom, eliminated perpetual licenses, moving entirely to subscription-only models. This means customers can no longer buy a license once and use it indefinitely; they must pay ongoing subscription fees. While the industry is trending toward SaaS or subscription models, this change forces VMware customers to incur recurring costs and makes them vulnerable to future price increases or audits.
- Bundled Products (All-or-Nothing): Broadcom consolidated VMware’s 160+ products into a few bundles. Features like NSX (networking) or vSAN (storage) that were once optional are now only sold as part of larger suites. Customers often have to pay for capabilities they don’t need or upgrade to higher tiers just to access specific features. This reduces flexibility and can multiply costs for those who previously right-sized their VMware licensing.
- Channel and Support Changes: Broadcom also revamped VMware’s sales channels, focusing on direct sales and a limited set of resellers. Many customers had to establish new relationships for purchasing and support. Combined with stricter licensing terms, this created uncertainty and disruption in how customers engage with VMware.
These changes have alarmed VMware’s install base. Industry analysts report a surge in inquiries from IT leaders about alternatives to VMware. Gartner observed a 275% year-over-year increase in clients inquiring about VMware replacement options in early 2024 and predicts that half of VMware’s customers will initiate proofs of concept for alternative platforms within two years.
This trend reflects a broad recognition: staying 100% dependent on VMware now carries a higher risk. CIOs cannot assume the status quo will continue unfettered – pricing and terms might change again, and negotiating from a position of dependency is difficult.
In short, Broadcom’s strategy has shaken customer confidence, making diversification a prudent strategic consideration.
Benefits of Diversifying Your Virtualization Platforms
Adopting a diversified virtualization strategy means using a mix of on-premises and cloud platforms, rather than a single-vendor solution.
Key benefits of this approach include:
- Avoiding Vendor Lock-In: With multiple hypervisors in use, no single vendor can hold the organization hostage to extreme price increases or unfavorable terms. If VMware’s costs become unsustainable, having an alternative already running gives a viable escape route. This competitive pressure can also encourage VMware (Broadcom) to offer more reasonable pricing to retain your business.
- Negotiation Leverage: Even if you don’t fully abandon VMware, the credible threat of exit strengthens your hand in negotiations. Broadcom’s team will know you have options. Simply being able to say, “We have a pilot on Hyper-V/Azure/KVM and can shift workloads if needed,” changes the tone of renewal discussions. As one expert noted, the mere presence of a credible alternative often motivates a vendor to be more reasonable with prices and terms.
- Cost Optimization: Different platforms have different cost structures. By matching workloads to the most cost-effective platform, CIOs can optimize spending. For example, development or test workloads might run on a free or lower-cost hypervisor (or in the cloud) to save on VMware licensing for non-production systems. Over time, using the “right tool for the job” can lower the total cost of ownership.
- Flexibility and Innovation: Each platform has unique strengths. Diversifying allows IT teams to leverage the best features of each. Perhaps VMware is used for core enterprise apps that require its advanced features, while open-source KVM is used for lightweight container hosts, and public cloud VMs are used for elastic scaling. A multi-platform approach also aligns with modern hybrid cloud and multi-cloud strategies, giving the business the agility to deploy workloads in the environment that best suits them (on-premises, cloud, or at the edge).
- Risk Mitigation: Relying on a single platform is a risk of single point failure, both technically and commercially, as well as strategically. A bug or security issue in one hypervisor, or a licensing audit from that vendor, could impact all workloads. Diversification contains such risks by spreading workloads. It also prepares the organization for a smoother transition in case a full migration from the primary platform becomes necessary in the future; you won’t have to start from scratch under pressure.
In summary, diversification is a form of insurance. It provides options and leverage that purely homogeneous environments lack. CIOs who plan with alternative platforms are effectively hedging against the uncertainty introduced by Broadcom’s changes. Next, we examine the top alternative virtualization platforms and how to evaluate them for specific needs.
Alternative Virtualization Platforms to Consider
The good news is that VMware is not the only enterprise-grade virtualization solution. Several mature alternatives can run traditional workloads, often at lower cost or with different benefits.
Key platforms to consider include:
- Microsoft Hyper-V: A widely used hypervisor included with Windows Server. Hyper-V has grown into a capable platform for both Windows and Linux guests. It integrates tightly with Microsoft’s ecosystem (Active Directory, System Center, Azure Stack HCI) and is often already licensed in Windows environments. Hyper-V can be a natural fit for organizations with a heavy Windows footprint or Microsoft-centric operations. In branch offices or smaller deployments, Hyper-V can be used on existing Windows servers at a low extra cost. Its feature set (clustering, live migration, replication) is robust, though not identical to VMware’s. Be sure to evaluate the differences in management tools and the features supported for your workloads. On the plus side, many IT administrators have some familiarity with Hyper-V, and Microsoft offers competitive migration tools, such as Azure Migrate, which can convert VMware VMs to run on Hyper-V or Azure, to entice VMware customers.
- Open-Source KVM (Kernel-based Virtual Machine): KVM is an open-source hypervisor technology built into the Linux kernel. Various enterprise distributions, such as Red Hat Enterprise Virtualization, oVirt, Proxmox VE, and Nutanix AHV, leverage KVM under the hood. KVM’s appeal is its low cost (often free) and flexibility. Organizations with strong Linux expertise may find KVM-based solutions attractive for both data center and edge workloads. For example, a development or test environment could run on a KVM cluster using a free management toolset, thereby avoiding VMware fees for that segment. KVM’s ecosystem includes rich options: Red Hat’s KVM comes with commercial support, and Red Hat also has tools to import VMware VMs. Projects like Proxmox or OpenStack on KVM enable the creation of a private cloud with minimal licensing requirements. The trade-off is that KVM solutions might lack some of VMware’s polish or third-party integrations. Evaluate compatibility with your existing storage, networking, and backup tools. Ensure your team is ready to handle Linux-based management. If those boxes check out, KVM can dramatically lower virtualization costs.
- Public Cloud Virtual Machines: An increasingly viable alternative to expanding on-premises VMware is to move certain workloads to public cloud providers like AWS, Microsoft Azure, or Google Cloud. Cloud VM offerings, such as Amazon EC2 or Azure Virtual Machines, provide on-demand compute without requiring you to manage the hypervisor. Essentially, the cloud’s hypervisor becomes your alternate platform. This approach can be great for development, testing, or seasonal workloads – you pay only for what you use, avoiding the need for large upfront licenses. Cloud providers also offer credits or discounts to encourage migration from on-prem environments. However, keep in mind that moving to the cloud is a larger architectural decision; it may involve reworking applications or scripts. Also, while you escape VMware’s costs, you incur cloud costs, so be sure to do a careful comparison. The public cloud is especially useful for new workloads or those that can be easily isolated and managed. It might not suit every legacy system without refactoring. Some CIOs leverage the cloud only for specific scenarios (e.g., bursting during peak demand or disaster recovery) to augment their on-premises setup. Still, as part of a diversification strategy, cloud options can reduce reliance on a single on-prem vendor and offer unparalleled scalability.
- Other Niche or Emerging Options: Depending on your environment, there are other platforms worth mentioning. Nutanix AHV is a hypervisor that comes integrated with Nutanix’s hyperconverged infrastructure solutions (AHV is KVM-based and known for simplicity). Citrix Hypervisor (XenServer) is another established hypervisor, particularly for organizations already using Citrix for VDI. These alternatives often tout lower licensing costs and integrated management. While not as common as Hyper-V or KVM, they can be viable if they align with your company’s infrastructure strategy (for example, if you plan a hyperconverged deployment, Nutanix AHV could replace VMware in that context). The key is to match the platform to your use case and skill set. Any of these can potentially run your VMs – the decision will hinge on what fits best with your existing systems and staff expertise.
Use Cases: Picking the Right Platform for Each Workload
CIOs should evaluate alternatives on a per-workload or per-use case basis, rather than making a one-size-fits-all decision.
Different virtualization platforms may be optimal for different scenarios within the IT estate.
Below are examples of where diversification often makes sense, and how to approach each:
- Development and Test Environments: Non-production environments are ideal for testing alternative platforms. Dev/test workloads are typically lower risk – if a development VM has an issue on a new hypervisor, it doesn’t impact customers. Many organizations offload new development, QA, or lab environments to a different platform first. For instance, you could run your dev/test VMs on an open-source KVM cluster or use cloud-based VMs for testing new builds. This saves cost (no need to license VMware for transient or experimental workloads) and allows your developers and IT staff to get comfortable with the alternative. When evaluating options for development and testing, consider provisioning speed and automation. Public cloud VMs may offer quick spin-up and tear-down via API, whereas a KVM or Hyper-V environment may integrate with your on-premises automation tools. Success in the dev/test domain can build confidence to later broaden the usage of the alternate platform.
- Branch Offices and Edge Sites: Remote offices or edge deployments typically run a handful of virtual machines (VMs) to support local services, such as file servers, domain controllers (DCs), and point-of-sale systems. These sites may not justify a full VMware implementation with its licensing overhead. Instead, a lightweight alternative can serve well. For example, a Windows server at a branch can host a few Hyper-V VMs to meet local needs, leveraging licenses you already have. Or a small Linux server with KVM could run an isolated legacy app at the edge. Key considerations for branches and edges: simplicity and reliability. The solution should be something your regional IT staff or central team can manage without specialized skills. Hyper-V is a good option here if you have Windows knowledge. Also, consider management – if you have dozens of branches, how will you update and monitor these alternate hypervisors? Look for tools, such as Microsoft’s management consoles or open-source tools like Cockpit, that can remotely manage those instances. By diversifying at the edge, you contain the spread of VMware (maybe using VMware only in core data centers) and cut costs for peripheral workloads.
- Legacy System Isolation: Many enterprises maintain legacy applications or operating systems that require an isolated virtual machine (VM) environment for compatibility reasons. These might not need the latest and greatest VMware features. Keeping them on older VMware versions can be an issue if support is dropped. An alternative hypervisor can be a good home for such legacy systems. For example, if you have an old Linux or Windows 2003 server that needs to run in a VM for occasional use, you could host it on a KVM box or even on a free VMware ESXi (if still available) or other free tool, segregated from your main environment. The idea is to quarantine legacy workloads on a cost-effective platform, since you likely won’t invest in enhancing those legacy apps. When evaluating alternatives for legacy systems, ensure the target hypervisor supports the old OS and any required configurations. Older operating systems may require specific virtualization extensions. Open-source virtualization often has forums of other users running legacy OS, which can be a helpful resource. This use case allows you to gain experience with alternatives in a controlled way, and if successful, frees up expensive VMware capacity for newer workloads.
In all these cases, evaluate the workload’s needs (performance, uptime, special hardware or software dependencies) against the capabilities of the alternative platform. Some workloads may perform better on VMware, for example, if you heavily use vSphere-specific features like high-performance VM clustering or have third-party appliances certified only for VMware.
But plenty of workloads don’t require those unique VMware features and can run fine elsewhere. By systematically assessing each category of systems, CIOs can identify low-risk candidates to migrate or deploy on a new platform.
Piloting Alternatives in a Low-Risk Way
After identifying candidate workloads and platforms, the next step is to pilot the alternative in a controlled, low-risk manner. A pilot (or proof of concept) allows your team to validate the platform’s suitability and identify any challenges before a wider rollout.
Here’s how to execute a prudent pilot:
- Start Small and Isolated: Pick a small subset of workloads for the initial pilot – for example, 5-10 virtual machines (VMs) from your development environment or the systems of a single branch office. Set up the chosen alternative platform in a test environment or an isolated segment of your network. This could be on spare hardware, a new small cluster, or a partition of your cloud environment. Ensure this pilot environment does not impact your production VMware setup. The goal is to learn without risking core services.
- Set Success Criteria: Define what you want to observe and measure. Is it performance (compare VM performance on VMware vs. on Hyper-V)? Is it functional compatibility? (Does the application run smoothly on KVM?) Is it operational fit (can my team manage Azure VMs effectively)? Establish metrics or checkpoints – e.g., “Application X runs on Hyper-V with no issues for 1 month and backup/restore works” or “We can automate deployment of a test VM on KVM in under 5 minutes”. Having clear criteria will help determine if the pilot is successful and if the platform is viable.
- Leverage Vendor Resources and Tools: When piloting, take advantage of resources from the alternate platform’s provider or community. Microsoft and various vendors offer migration tools to convert VMware VMs to their format – use these in your pilot to evaluate how easily a VM can be ported over. Many cloud providers have free trial credits – use those to experiment with moving a workload to the cloud at minimal cost. Open-source communities, such as Proxmox forums or the Red Hat customer portal, can provide guidance on best practices for setting up KVM and resolving issues. Piloting is not just a technical trial, but also an exercise in tapping into a new support ecosystem.
- Train and Document During the Pilot: Use the pilot phase to begin training your IT staff on the new platform. Perhaps send engineers to a Hyper-V training session or have them complete a Red Hat KVM online course. Let team members rotate through managing the pilot environment so they gain experience. Document the configuration steps, any hiccups, and how they were resolved. This “playbook” for the new platform will be invaluable if you decide to expand your usage later. Early training and documentation also surface the learning curve involved, informing you of how much effort full adoption might require.
- Run Realistic Workloads and Scenarios: Don’t keep the pilot too theoretical. Run real workload scenarios through it – for example, simulate a failover when testing Hyper-V clustering, or perform routine patching and see how it performs. If using the cloud, simulate what an outage or network latency might do. The more realistically you exercise the alternative, the more confidence (or legitimate concerns) you’ll have. It’s better to discover an integration issue (say, your monitoring tool doesn’t support the new hypervisor) during a pilot than during a rushed migration later. Address any issues encountered; if some problems can’t be resolved, note them as limitations of that platform for your environment.
- Evaluate Results and Iterate: After a defined pilot period, evaluate your results against the success criteria. If the pilot meets expectations, you can plan next steps, such as expanding the pilot or permanently moving some workloads. If there are significant problems, assess whether they can be resolved by configuration or if they indicate that the platform may not be suitable for certain workloads. It’s possible that one alternative doesn’t meet your needs – that’s fine, better to know now. You could then pilot a different solution (e.g., if KVM didn’t work out for a particular app, perhaps try Hyper-V or vice versa). The pilot phase may involve a few iterations until you land on a comfortable mix of platforms.
Piloting in this careful way keeps the initiative low-risk and cost-effective. It avoids a big-bang switch. Instead, it provides tangible evidence of what an alternative can or cannot do in your environment.
Over time, these pilots create a credible fallback platform – essentially a parallel lane that you can expand if needed – which directly enhances negotiation leverage with VMware/Broadcom.
Gaining Negotiation Leverage with an Exit Strategy
One of the most strategic reasons to diversify is to improve your position in negotiations with Broadcom (for VMware licensing).
Having a real, tested exit strategy changes the balance of power. Here’s how CIOs can use that to their advantage:
- Develop a Credible Exit Plan: An exit strategy is more than just saying “we could leave if we want to.” It needs to be backed by evidence. Through the pilots and workload assessments, build a plan that shows which workloads can be moved to which alternative platform and on what timeline if VMware costs become unacceptable. For example, your plan might state: “Within 6 months, we can migrate 30% of workloads (dev/test, branch offices) to platform X, freeing Y number of VMware licenses.” Include cost estimates and resource requirements for this move. When you present such a plan, it signals to VMware’s vendor reps that you mean business and have done your homework.
- Demonstrate Initial Steps: You don’t necessarily need to migrate a large chunk before negotiations, but you should demonstrate progress toward the alternative. This might mean you’ve already migrated a few less-critical applications, or you have a parallel environment up and running. Concrete actions speak louder than words. Broadcom is more likely to negotiate if they see that you have invested time and money in setting up an alternative, because it indicates you are willing to go further if pushed. Internally, this also rallies your stakeholders by showing that IT is proactively safeguarding the organization’s interests.
- Leverage Alternative Quotes and TCO: In negotiations, you can bring data comparing VMware’s costs to those of alternatives. If Microsoft or another vendor has provided a quote or indicative pricing to run equivalent workloads on their platform, use that as a benchmark. For instance, if running your environment on Hyper-V would cost 30% less (when factoring in the licenses that come with Windows and existing agreements), politely point that out. Or if moving certain workloads to the cloud would save a certain amount, mention that. The idea is not necessarily to threaten outright migration, but to provide a factual basis for requesting better terms: “We’ve done due diligence and have options at $X lower cost; help us understand why sticking with VMware is worth the premium.” This puts the onus on Broadcom/VMware to either adjust pricing or risk losing your workloads.
- Engage Independent Advisors if Needed: Negotiating enterprise licenses can be complex, especially with new models and bundles. Consider engaging an independent licensing expert (third-party advisor) to help craft your negotiation strategy. Firms like Redress Compliance specialize in VMware and Broadcom licensing and can offer insights into contract terms, potential concessions, or audit pitfalls. They are not tied to VMware, so they can objectively validate your exit plan’s feasibility and even interface with the vendor on tricky points. Bringing in an outside expert can bolster your confidence and help you be aware of any Broadcom negotiation tactics you may have seen elsewhere. The key is that they remain independent – the goal is to strengthen your position, not simply to find another reseller.
- Be Ready to Execute if Necessary: Leverage is only real if you’re prepared to follow through. CIOs must get executive buy-in on the principle that if VMware’s offer is unreasonable, the company is willing to divert investment to the alternative. This might mean reallocating budget for new hardware, cloud capacity, or training to support migration. Ideally, the mere prospect will lead Broadcom to moderate its pricing. But if it doesn’t, you need the organization’s commitment that Plan B will go ahead. Often, just reaching this internal alignment is valuable – it means IT and business leadership have a shared understanding of how far they’re willing to go, which in itself prevents panic when facing vendor pressure.
Using an exit strategy in negotiations should be done in good faith and professionally. It’s not about issuing ultimatums; it’s about ensuring the vendor knows you have choices.
Many enterprises find that once the vendor realizes lock-in is not absolute, concessions follow, whether in the form of discounts, flexible terms, or added value. And if not, the organization is still in a better place because it has a head start on alternative solutions.
Weighing the Risks of a Multi-Platform Approach
While diversification offers clear benefits, CIOs must also consider the risks and trade-offs associated with it. Introducing new platforms alongside (or instead of) VMware can create challenges.
Being aware of these risks allows you to plan mitigations and avoid unwelcome surprises:
- Staff Skills and Training: Your IT staff may be highly skilled in VMware tools, such as vCenter and ESXi, after years of experience. Switching to or co-managing another hypervisor means a learning curve. Administrators will need training on new interfaces, such as Microsoft’s Hyper-V Manager or SCVMM, as well as open-source tools like KVM. Skills in networking and storage might need updating to handle differences in how Hyper-V or KVM integrates with those layers. There’s also the risk of mistakes in the interim as people adjust to new processes. To mitigate this, invest in training early, as mentioned during the pilots, and consider bringing in experts or hiring staff with experience on the target platform. Cross-train the VMware team so they gain confidence in both environments. It’s an upfront effort, but it will pay off by building operational resilience across platforms.
- Tooling and Integration Gaps: A mature VMware environment typically has a comprehensive ecosystem of tools, including backup software, monitoring systems, automation scripts, and disaster recovery solutions, all tailored to VMware. When you introduce a new platform, some of those tools might not work out of the box. For example, your backup solution might need a different plugin (or a new solution entirely) to back up Hyper-V VMs. Your infrastructure-as-code scripts may need modules for AWS or Azure. Managing two platforms might mean using separate toolsets for each, which can reduce the “single pane of glass” visibility that admins crave. It’s important to audit your tooling: identify what needs to change, or whether unified management tools (some vendors offer multi-hypervisor management) can cover both. Consider using management layers that abstract away the hypervisor differences (for instance, some cloud management platforms or container orchestration tools can help manage workloads independently). Expect to invest in new tools or make adjustments to existing ones as part of your diversification strategy.
- Migration Costs and Complexity: Moving workloads between hypervisors (or to the cloud) isn’t free or instant. There can be costs in terms of time, such as engineering hours to plan and execute migrations and testing after the move. Additionally, you may need temporary dual environments during the transition, which could require extra hardware. You may also require consulting services to assist. In the case of large enterprises, these costs can be significant; one company estimated that migrating fully off VMware could cost tens of millions in effort and new infrastructure. Even partial moves require thorough planning, including converting VM formats, ensuring data consistency, and scheduling downtime if needed. This is why having a phased approach, starting with low-risk systems, is essential. Also, look for tools that can automate parts of the migration (VM conversion tools, cloud migration services) to reduce manual work. It’s wise to do a pilot migration of a representative system to gauge the level of work involved and use that to more accurately estimate costs for larger scales.
- Operational Complexity: Running multiple platforms means you essentially have multiple environments to maintain. Patching, monitoring, and troubleshooting must be done in each environment. This can strain a small IT team if not addressed – you don’t want one environment to fall behind on updates because attention is on the other. There’s also complexity in processes: for example, your incident response playbook might need different steps depending on which platform a workload is on. This is manageable with good processes and possibly by delineating responsibilities; for example, one sub-team could focus on cloud operations, another on on-premises hypervisors, and so on. Some organizations mitigate complexity by limiting the number of platforms – e.g., perhaps two hypervisors at most – to avoid spreading too thin. Using familiar concepts (if your team is familiar with VMware, they may adapt to Hyper-V more quickly than to an entirely new concept) can also reduce complexity. Over time, as the team becomes proficient, the multi-platform operations will feel more routine, but expect an adjustment period.
- Performance and Support Considerations: While alternative platforms can meet general needs, there may be specific cases where VMware’s performance optimizations or vendor support are superior. For instance, certain high-performance database workloads may be finely tuned on vSphere, and moving them to another hypervisor could impact throughput until they are retuned. Or you might have a vendor that only officially supports their software on VMware, not on KVM. Running it on KVM could introduce support challenges. CIOs should catalog any such special cases. For those, it might be wise to keep them on VMware (at least until equivalent support exists on the new platform) to avoid jeopardizing SLAs or warranties. Additionally, ensure that any alternative platform you choose has a reliable support avenue – whether through a commercial vendor (like Red Hat for KVM, or Microsoft for Hyper-V) or a strong community – so that if issues arise, you’re not on your own.
- Internal Resistance and Change Management: Beyond technical factors, expect some cultural resistance to change. Teams that are comfortable with the status quo may resist adopting a new platform, especially if it’s perceived as less prestigious or introduces uncertainty. You may need to communicate the rationale (the risks of staying status quo and the benefits of having options) to get buy-in from stakeholders. Engage your architects, engineers, and even application owners early in the process – perhaps even during the pilot phase – to show them that this is an enhancement to the strategy, not just extra work. Celebrating wins, such as successfully running a pilot on KVM or saving costs with Hyper-V in a remote office, can build positive momentum. Treat diversification as a major IT initiative with executive sponsorship, so it receives the attention and resources it needs, and everyone understands that it is a strategic priority.
In assessing these risks, it’s clear that diversification is not a decision to be taken lightly or made haphazardly. It introduces change. But with proper planning, training, and phased execution, the risks can be managed.
Many organizations already operate in a heterogeneous IT world (multiple OS, multiple cloud providers, etc.), so multiple hypervisors is just another dimension of that diversity.
The key is to weigh the short-term effort against the long-term benefit: a bit more complexity now to avoid a far worse position later. Most CIOs conclude that some complexity is worth the price of freedom and negotiating power.
Recommendations for CIOs
For CIOs looking to implement a virtualization diversification strategy, here is a concise action plan:
- Assess Your VMware Footprint and Risks: Begin with a thorough review of your current VMware environment and contracts. Identify when your VMware licenses and support renewals are due and project the potential cost increases under Broadcom’s new model. Inventory your workloads and categorize them based on factors such as criticality and resource needs. This will highlight which workloads might be candidates for alternative platforms (e.g., low-risk development or testing, or remote site systems) and what the impact would be if VMware costs were to rise further.
- Research and Shortlist Alternative Platforms: Investigate top alternative virtualization solutions, including Microsoft Hyper-V, KVM-based platforms, and public cloud options, to determine which ones best align with your use cases. Consider your organization’s existing strengths: if you’re a heavy Microsoft shop, Hyper-V or Azure may integrate smoothly; if you have strong Linux talent, KVM or an open-source stack could be attractive; if your company has a cloud-first mandate, leveraging AWS or Azure VMs may be logical. Narrow down a list of 1-2 platforms to pilot by matching their strengths to the workload categories you identified. Engage vendors for information – for example, ask Microsoft or Red Hat for details on how they help VMware customers transition.
- Conduct Low-Risk Pilot Projects: Plan and execute pilot deployments for the shortlisted alternatives. Start with non-production or low-risk systems, such as a small development or test environment, or a branch office workload. Set clear objectives for each pilot (performance, management ease, compatibility checks) and a fixed timeline (e.g., a 3-month evaluation). Use this pilot to both validate the technology and train your team on the new platform. Document the results, including any issues and how they were resolved. If the pilot is successful, consider expanding it or migrating some targeted workloads directly to the new platform.
- Develop a Phased Diversification Roadmap: Based on what you learn from pilots, create a roadmap for rolling out the alternative platform more broadly. This doesn’t mean you will execute it fully, but it provides a blueprint to follow. For example, Phase 1: Migrate all test environments to Platform X by Q4. Phase 2: Move file/print and minor apps from branches to Platform X by Q1 next year. Phase 3: If needed, migrate part of the production workload Y to Platform X (later). Include prerequisites such as training, tool readiness, and a budget for hardware or licenses. This roadmap forms the core of your exit strategy. Share this plan with senior IT leadership and ensure it’s aligned with business continuity goals.
- Engage Vendor Negotiations with Evidence: As your VMware renewal or ELA (Enterprise License Agreement) discussions approach, enter those talks prepared. Use the data collected (current VMware costs vs. alternatives’ costs, pilot performance results, the roadmap of what you could move) to have an informed conversation with Broadcom/VMware representatives. Communicate that while you value VMware’s technology, you have done due diligence on alternatives. Emphasize that you prefer an amicable path forward but have the capability to reallocate workloads if necessary. Request pricing or contract adjustments that would make staying with VMware competitive against your alternatives. By showing your homework, you invite the vendor to respond in kind, ideally with concessions or creative solutions.
- Consider Third-Party Expertise: If navigating the new licensing terms or crafting an optimal negotiation strategy seems daunting, consider bringing in help. Retain an independent licensing consultant (for example, Redress Compliance or similar firms with VMware expertise) to audit your VMware usage and advise on contract negotiations. They can identify usage inefficiencies, recommend license optimizations, and provide insider knowledge on Broadcom’s tactics and flexibilities. Their guidance can ensure you’re not leaving money on the table or agreeing to terms you might regret. Importantly, choose an advisor who is not a reseller for VMware or any alternative – you want unbiased advice focused on your interests alone.
- Communicate and Manage Change: Finally, as you embark on diversification, keep the lines of communication open with all stakeholders. Explain to your IT teams and business units why this is being done (to protect the company from risk and excessive costs). Highlight the long-term benefits, such as improved negotiation leverage and cost savings, which can free up budget for innovation. Prepare a change management plan for the operational shifts that come with using multiple platforms. Update processes, run training sessions, and set new KPIs that reflect multi-platform operations, such as proficiency on new systems and cross-platform incident resolution times. By managing the human side of diversification, you ensure that the technology changes deliver value.
By following these steps, CIOs can methodically reduce over-reliance on VMware without causing disruption. The outcome should be a more resilient virtualization strategy where the organization is in control of its destiny – able to choose the best platform for each need and negotiate with vendors from a position of strength, not fear.
Diversifying does require effort and foresight, but it is rapidly becoming a best practice for infrastructure leaders who have witnessed the current upheaval in the virtualization market.
