For many organizations, a VMware renewal is no longer a routine procurement event. It is a portfolio decision involving licensing, infrastructure capacity, hardware lifecycle, operational skills, application dependencies, resilience, and the cost of change.
The mistake is treating the decision as binary: renew or leave. Most organizations have five credible paths, and the right answer may combine several of them across different workload groups.
The Nettelix position: do not select the replacement platform first. Establish the requirements, constraints, workload segments, and five-year economics first. Architecture first. OEM second.
First, establish the fact base
Before comparing products or accepting a renewal proposal, build a verified baseline:
- Physical cores, hosts, clusters, sockets, and storage capacity actually in scope.
- VM inventory, resource use, growth, criticality, recovery objectives, and technical dependencies.
- Current license rights, support dates, hardware warranties, and contractual deadlines.
- Operational tooling, automation, backup, disaster recovery, networking, and security integrations.
- A full cost baseline that includes people, facilities, support, migration, retraining, and parallel operations.
Broadcom’s current VCF and VMware vSphere Foundation 9 licensing uses subscription license files managed through VCF Operations and the Business Services console. Core capacity and, where applicable, vSAN capacity should be validated rather than estimated from invoice history alone.
The five viable paths
1. Renew and standardize
Renew the current estate and deliberately use the broader platform capabilities available to you.
Best fit: the environment has deep VMware dependencies, operational maturity is high, business risk favors continuity, and the economics are acceptable when the full platform is used.
Watch: paying for a platform bundle while continuing to operate only a narrow subset of its capabilities.
2. Renew—but optimize the footprint
Retain VMware while reducing the licensed and supported footprint through workload cleanup, cluster redesign, hardware consolidation, storage review, and more disciplined capacity placement.
Best fit: the platform remains strategically useful but the estate contains over-allocation, low-density clusters, stranded capacity, or workloads that no longer belong there.
Watch: optimizing solely for license quantity while creating unacceptable failure domains, performance constraints, or operational complexity.
3. Selectively replatform workloads
Keep VMware for workloads that benefit from it while moving suitable applications to managed services, public cloud, SaaS, containers, bare metal, or other existing enterprise platforms.
Best fit: the portfolio is diverse and some workloads have clear landing zones with manageable transition risk.
Watch: moving cost without removing the fixed cost of the remaining VMware estate. Savings appear only when workload moves allow real capacity or contract reductions.
4. Move to another virtualization or private-cloud platform
Adopt an alternate platform for a significant portion of the virtual-machine estate. Credible destinations now include multiple on-premises and hybrid operating models; each changes the management, networking, storage, backup, support, and skills equation.
Best fit: the organization has sufficient time, executive sponsorship, migration capacity, and a target platform aligned to its broader operating model.
Watch: evaluating only whether a VM boots. Production readiness also requires lifecycle management, observability, recovery, security, automation, and support processes.
5. Redesign the infrastructure operating model
Use the renewal as a trigger to simplify the portfolio: retire applications, consolidate sites, change recovery patterns, separate workload tiers, adopt consumption services, or redesign how infrastructure is sourced and operated.
Best fit: the current estate reflects years of incremental decisions and the organization needs a durable model rather than a product substitution.
Watch: combining too many transformation goals into one deadline-driven program. Sequence decisions so the renewal date does not become an unsafe migration date.
How to choose among them
| Decision factor | What to test |
|---|---|
| Time | How much runway exists before commercial or support deadlines? |
| Dependency | Which workloads, tools, and operational practices are genuinely VMware-specific? |
| Economics | What changes in three- and five-year cost after transition, coexistence, and staffing are included? |
| Risk | What is the acceptable outage, rollback, security, and delivery risk by workload tier? |
| Operating model | Which platform best matches the organization’s skills, automation, governance, and support model? |
| Exit value | Does the change reduce durable cost or risk, or merely move it elsewhere? |
A practical 90-day decision process
Days 0–15: verify the baseline
Confirm commercial deadlines, entitlements, capacity, workload inventory, dependencies, lifecycle exposure, and current cost.
Days 15–35: model the options
Define two or three credible target architectures and a stay-the-course baseline. Apply the same requirements and economic assumptions to each.
Days 35–60: validate the hard parts
Run targeted technical validation, migration testing, operational workshops, and commercial market checks. Test the riskiest assumptions—not the easiest demo.
Days 60–90: decide and sequence
Select the portfolio path, negotiate from a defensible fact base, define decision gates, and publish a phased roadmap with owners, costs, dependencies, and rollback conditions.
The goal is not to “exit VMware.” The goal is to establish the right platform mix for the organization and retain leverage over the next decision cycle.
Source notes
- Broadcom: Getting started with VCF or VVF 9 licensing
- Broadcom: Counting cores and vSAN capacity
- Microsoft: VMware migration to Azure Local overview
- Red Hat: Migration Toolkit for Virtualization
This article is general informational content and does not replace analysis of your contracts, workloads, architecture, or risk requirements.