VMware Users are Feeling Trapped by Vendor Lock-In

In the wake of VMware’s recent price hikes and contract changes, many customers are looking elsewhere for options – but find extensive switching challenges barring their way. At FluidCloud, we embrace multi-cloud and the freedom to innovate by efficiently moving the right workloads where you need them - whether that is another public or private cloud like Nutanix, OVH, OCI, Vultr, AWS, Azure or GCP - giving you the relief you need to make the best decisions for your business. 

VMware / Broadcom: Anatomy of a Lock-in Crisis

Since Broadcom’s 2023 acquisition of the virtualization giant, VMware/Broadcom has proceeded to change contract terms, including mandatory bundling of services, in ways that resulted in massive price hikes –  with reported price increases running as high as 1,500%. 

Forrester research has reported that “Many [VMware enterprise customers] are exhausted by significant price hikes, degrading support, and mandatory subscription to software bundles in which some modules such as NSX and Aria Suite/vRealize Suite end up as shelfware.” 

These changes are being felt by VMware customers of all kinds – and regardless of past loyalty. Indeed, AT&T faced a 1,050% VMware price increase – despite a shared history that AT&T EVP and GM Susan Johnson referred to as “a ten-plus year strategic relationship with Broadcom.” As recounted in The Register, the subreddit r/vmware has many more examples of customer ire.

In a more perfect world, VMware customers could escape bad contract terms by quickly standing up new cloud arrangements – and then migrating VMware workloads over to cloud environment alternatives. But the reality is not so simple. De-facto VMware lock-in appears to be the norm. 

Extensive Migration Challenge 

Simply put, moving off of VMware can prove a herculean task. One Gartner analysis estimates that, for a firm running at least 2,000 VMs on 100 servers, migrating away from VMware can require up to 48 months of work at up to $3,000 per virtual machine. 

More broadly, cloud migration in general is complex and expensive. For instance, my team has estimated that a typical cloud infrastructure migration scenario – 50 VMs, 75 Storage Volumes, 20 Virtual Networks, 30 Firewall Rules, and 12 Subnets from VMware to an alternative cloud provider - would entail: 

• $100,000 to $500,000 in total investment

• A 12 - 15 person team

• 3 to 4 Months of work.

We asked multiple senior IT executives at major firms for estimates of their own; the answers were consistently in line with these assessments. 

The good news is that more efficient cloud migration is possible. But first, customers need to overcome the cloud infrastructure barrier. 

The Standardization Hurdle to Migrating Clouds

A key reason why cloud migrations are so costly and slow is that cloud infrastructure is vastly unstandardized. Because each cloud platform approaches a host of similar concepts in different ways, translating underlying infrastructure definitions for compute, network, storage, data services, and identity has historically been very tedious, manual, and error-prone.  

The lack of standards arises both in the infrastructure environments themselves, and in the APIs and technologies used to interact with the platforms. These differences can slow cloud migration down by months, and raise costs by hundreds of thousands of dollars. 

For just a few examples of missing standardization:

• Workflow (IaC instructions): AWS recommends CloudFormation templates written in YAML/JSON, with its own resource naming and dependency syntax. By contrast, Azure prefers ARM templates or Bicep, which use different schema, parameters, and deployment scopes. Google generally recommends Terraform.
  
  

• Testing Protocols (CI/CD): Azure DevOps pipelines are YAML-based but use different trigger syntax, job runners, and integration methods for Azure resources. GCP Cloud Build uses a step-based JSON/YAML config with container images, and the testing stages are orchestrated differently.
  
  

• Security Architecture: AWS uses granular policies attached to roles/users for Identity and Access Management (IAM); Azure uses Role-Based Access Control (RBAC) with role assignments scoped to subscriptions, resource groups, or resources; and GCP has its own IAM bindings and permission hierarchy inside of Projects.

Meanwhile, depending on which cloud you’re migrating from, and which you’re migrating to, cloud APIs operate under vastly different rules. For a just a few examples here: 

• Concepts: AWS VPCs and Azure Virtual Networks are regional, whereas in GCP, VPCs are global. Firewall concepts are named and implemented differently in each. Assigning compute vCPUs and memory uses different names and approaches in each.

• Naming: AWS requires specifying an instance type and AMI ID when launching an EC2 instance, but Azure requires a VM image URN. Google Cloud, by contrast, requires a full image path. 

• Structure: AWS’s S3 uses terminology like 'buckets' and 'objects.'; Azure’s Blob Storage refers to 'containers' and 'blobs'; while Google Cloud’s Cloud Storage employs its own endpoints, also referring to 'buckets' and 'objects' but with different authentication methods, request structures, and feature differences.

Because of this lack of standardization, customers looking to migrate clouds have traditionally leaned on professional IT consultants and the reigning cloud migration automation offerings. As alluded to above, IT consultancies – while often masters at their work – are expensive and slow. As I’ll explain next, legacy automation has significant drawbacks as well. 

Legacy Automation Doesn’t Solve Key Problems

To be sure, fin-ops and observability tools like Kubecost or Datadog (to name just two) can be excellent at flagging cost issues and setup discrepancies. But as a whole, these tools do little to help teams actually take action based on their reports.  

Nor do the reigning AI tools help. Much of AI innovation is centered on large language models; but cloud infrastructure is a modeling problem, not a language problem – so LLMs are of limited use. In fact, in my team’s experience, even the leading models start hallucinating rapidly when faced with solving for infrastructure migration. 

Given the lack of solutions on the market, what’s needed is an entirely new migration technology: Cloud Cloning™. 

Fast Infrastructure Migration With FluidCloud Cloud Cloning™

Rather than rely on legacy methods, Cloud Cloning™ converts your cloud infrastructure into a standardized Terraform definition in near real-time—enabling seamless cloning, migration, and remapping across regions, accounts, and cloud providers. This provides customers with:

• Fast Portability: Built-in infrastructure mapping and automation to move workloads quickly across multiple clouds.

• Unified Governance: A real-time view of compliance, usage, cost efficiency, drift, and best practices across cloud environments.

• Built-in Resilience: Infrastructure also benefits from real-time back-ups allowing instant recovery or roll-back across accounts, regions or providers.   

As a result, teams can accurately recreate existing infrastructure and spin up new instances anywhere—compressing months of work into minutes while using a fraction of the usual resources and cost.

With technology supported by multiple patents, FluidCloud has recently emerged as the first Cloud Cloning™ provider on the market. And the impact of migration isn’t just incremental – it’s dramatic. 

For a sense of impact, look at the side-by-side comparison of estimates of FluidCloud’s impact vs. consultants in the question above.

Action Plan for Preventing VMWare Lock-In

Today, Broadcom / VMware has created deep-seated frustration within its customer base. If you’re a VMware customer today, you can take the following steps to protect yourself:  

• Review contracts thoroughly. Be sure you’re aware exactly when your contracts expire – so you can get ahead of a migration plan as ahead of time as possible. 

• Set up an alternative cloud provider ASAP. Since cloud migrations take time, you’ll want to work toward trying options and having your alternative complete well in advance of your VMware end-contract date – whether it’s in six months, or a few years. 

• Work with FluidCloud to migrate fast. Remember: The quicker you can migrate to a new cloud infrastructure, the more leverage you’ll have in the direction you take with VMware – or any cloud provider. FluidCloud can be a key asset in that effort.

__________________

James Bayer is Co-Founder and Chief Product Officer at FluidCloud