- 01 Footprint assessment template
- 02 Cost modelling: stay vs. leave
- 03 Platform selection criteria
- 04 Migration sequencing
- 05 Team readiness checklist
Your VMware licensing
cost is about to change.
Broadcom's acquisition restructured VMware's licensing model. Teams that plan now move on their own terms. Teams that wait negotiate from a weak position at renewal time.
What changed after
the Broadcom acquisition
Broadcom's restructuring of VMware licensing has made the status quo expensive to maintain. For most enterprise customers, the renewal conversation looks materially different from what it did two years ago.
Per-core bundles replaced à-la-carte SKUs
Broadcom consolidated VMware's product portfolio into two subscription bundles. Customers who only need a subset of features now pay for the full stack.
Renewal quotes are materially higher
Enterprise customers are reporting cost increases of 3× to 10× versus their previous contracts. The magnitude depends on your current SKU mix and negotiating position.
Perpetual licenses have been discontinued
VMware no longer sells perpetual licences. All new and renewed contracts are annual subscriptions, changing the long-term capital and operating cost structure.
Exit planning comes before
vendor selection
Most VMware exit projects fail because teams start with "what are we replacing it with?" instead of "what do we actually have, and what does it cost us to stay?"
Map your current VMware footprint
A complete inventory: VMs, clusters, storage, networking, licensed SKUs, support contracts, and the teams that depend on each workload. Without this, every cost estimate is fiction.
Model the real cost of staying versus leaving
Renewal cost over three and five years, compared against migration cost plus the operational cost of the replacement platform. Factor in engineering time — it is usually the largest line item.
Design a migration path your team can execute
A wave plan that starts with the workloads carrying the least risk and builds operational confidence before touching the most complex, stateful systems. Phased, not a big-bang cutover.
A decision framework,
not a vendor pitch
Five structured tools for the people who have to plan and justify the exit — assessment templates, cost models, selection criteria, migration sequencing, and a team readiness checklist.
Footprint assessment template
A structured inventory of your VMware environment: clusters, hosts, licensed SKUs, support contracts, and total cost of ownership.
Cost modelling: stay vs. leave
Side-by-side projection of renewal cost versus migration cost, covering infrastructure, engineering time, and operational overhead.
Platform selection criteria
A scored evaluation matrix for Kubernetes distributions and VM orchestration platforms, weighted against your compliance and operational requirements.
Migration sequencing
A risk-ordered wave plan for moving workloads — starting with the safest candidates and ending with the most complex, stateful systems.
Team readiness checklist
Skills, headcount, and training gaps your team needs to close before the migration starts — with a build-vs-hire decision guide.
Written for the people
making the decision
The playbook covers four perspectives — from the executive sign-off to the engineer who runs the migration.
Facing a VMware renewal in the next 12 months and under pressure to justify the infrastructure budget to the board.
Evaluating whether Kubernetes-based alternatives can replace VMware without introducing unacceptable operational risk.
Responsible for designing and executing the migration while keeping production workloads running throughout.
Negotiating with Broadcom or sourcing alternatives — and needing a credible cost model to justify the project.
Where VMware exit
projects go wrong
The same patterns appear in projects that stall or fail. The playbook addresses each one directly.
- Selecting a replacement platform before completing a full workload inventory
- Underestimating the migration cost of stateful workloads and storage dependencies
- Planning a "big bang" cutover instead of a phased, wave-based migration
- Ignoring team skills gaps until the project is already in flight
- Treating the exit as a pure infrastructure project, not a platform strategy decision
- Accepting a Broadcom renewal without modelling the multi-year total cost of ownership
- Migrating to a new platform without establishing Day-2 operational processes first
Get the VMware Exit Playbook
Sent to your inbox immediately. No marketing list, no sales sequence — just the document.
Or Book a Call → to speak with an engineer directly.
Common questions
Is this playbook vendor-agnostic?
Yes. The assessment templates and decision frameworks work regardless of which platform you choose next. Our own Cloud Orchestrator is one option described, alongside OpenShift, Rancher, and bare-metal Kubernetes distributions.
How long does a typical VMware exit take?
Smaller environments (50–200 VMs) typically take 3–6 months when planned carefully. Larger environments with legacy stateful workloads can take 12–18 months. The playbook helps you scope this honestly before you commit.
What if we are mid-contract with VMware?
Mid-contract is the right time to start planning — not after renewal. The playbook includes a section on contract analysis and how to use the planning process to negotiate better terms or a structured exit.
Does Stakater run these migrations?
Yes. Beyond the playbook, we offer structured VMware exit engagements through Cloud Orchestrator and our platform engineering services. The playbook is the starting point; the call is where we scope the actual work.
What format is the playbook?
PDF, optimised for reading on screen and printing. You will receive it by email immediately after submitting the form.
Is the playbook actually free?
Yes. We ask for your name and work email so we can send it and follow up with any questions. We do not add you to a marketing list without your consent.
Ready to plan your exit?
Bring your VMware footprint — we'll map a realistic migration path on the call.