The renewal quote is not the migration plan.
European cloud providers are reporting severe pressure from VMware licensing and partner changes. A September 2026 CIO report, drawing on the European Cloud Competition Observatory, cites CISPE member claims of renewal increases of 10x or more and warns that re-engineering away from VMware can become a multi-year, multimillion-euro exercise. Those are stakeholder claims, not an audited market-wide benchmark. But the operating signal is real: the commercial clock can move faster than the infrastructure estate.
Broadcom describes the same market from the other side. It has moved VMware to subscription licensing and is deliberately concentrating its cloud-service-provider ecosystem around fewer partners with scale and deeper capability. Broadcom frames that as simplification and improved customer outcomes. Affected providers frame it as concentration and lock-in.
You do not need to settle that argument before acting. You need to know whether your workloads, contracts and operating team can move safely if the economics or service path stop working.
I have spent more than 20 years in hosting and infrastructure. The recurring lesson is simple: platform exits fail when leaders treat them as one heroic project. A project optimizes for a finish date. A migration factory optimizes for safe repetition.
Here’s what works: build a controlled production system that qualifies, prepares, moves, accepts and retires workloads through common gates. Then put a representative service through the full system in 30 days.
Why the project model breaks
The typical exit plan starts with a spreadsheet of virtual machines and a target platform. It ends with a Gantt chart, a migration tool and an aggressive percentage-complete number.
That misses the hard part.
A VM is not the unit of value. The unit of value is the accepted business service: application, data, dependencies, owner, recovery expectation, operating evidence and commercial obligation. Copying disks proves that data moved. It does not prove that the service works, that operations can support it, or that the old cost has disappeared.
Six failure modes appear repeatedly:
- The inventory does not reconcile across vCenter, CMDB, backup, monitoring, billing and contracts.
- Application owners are missing, so nobody can define business acceptance.
- Dependencies surface during cutover rather than during qualification.
- The destination lacks production-grade identity, backup, restore, monitoring or escalation paths.
- Every team writes a bespoke runbook, making the second migration as difficult as the first.
- The source remains online “temporarily,” so dual-run cost becomes the new normal.
The renewal date makes these weaknesses urgent. It does not solve them. Microsoft’s migration guidance makes the same operational point: large portfolios need workload prioritization, sequencing, dependency discovery and waves. Google’s guidance on large data transfers is equally blunt: preparation can take as much time as the transfer itself.
The hidden leverage is not a better comparison matrix. It is a factory that turns uncertainty into throughput and evidence.
The VMware Exit Factory
The PromptPartner VMware Exit Factory has four operating lanes and four gates. Every workload can take a different technical path—retain, rehost, replatform, refactor, replace or retire—but it must pass the same evidence gates.
Lane 1: Exit Control Tower
The control tower owns the commercial clock and portfolio truth.
For each business service, create an Exit Control Book record containing contract and support dates, provider status, current cost, proposed cost, service owner, criticality, RTO and RPO, data-location constraints, dependencies and the intended path.
Broadcom’s own 2023 licensing announcement told customers to inventory perpetual licenses and support-expiration dates. That is necessary, but it is not enough. Contract data must sit beside operational data. A renewal date without a workload owner and dependency map is merely a countdown.
The control tower maintains three things leadership can actually use:
- A renewal and support heat map.
- A prioritized wave backlog.
- An exception queue for missing owners, unclear dependencies and unresolved economics.
This lane prevents procurement, infrastructure and application teams from operating against different versions of reality.
Lane 2: Platform Foundry
The foundry makes the destination operational before production workloads arrive.
It defines a small number of approved target patterns by workload class. Each pattern includes compute, network, DNS, identity, privileged access, secrets, certificates, storage, backup, restore, monitoring, logging, security controls, patching, support ownership and capacity management.
This is where many exits quietly fail. Teams prove that a guest can boot on the new platform and call the destination ready. Then the first production service discovers that restore has never been tested, monitoring does not reach the service desk, certificate ownership is unclear, or the receiving team cannot troubleshoot without the migration engineers.
Rule: do not move production into a platform whose backup, monitoring, access and operating ownership are still “phase two.”
The foundry’s output is not a target-state slide. It is an accepted landing-zone slice, infrastructure-as-code where practical, architecture decisions and an escalation model that works at 02:00.
Lane 3: Migration Cells
Migration cells create throughput. Each cell uses the same pipeline:
- Accept a complete Workload Passport.
- Select the path: retain temporarily, rehost, replatform, refactor, replace or retire.
- Prepare and replicate or convert.
- Run technical and business tests.
- Rehearse cutover and rollback.
- Execute the approved change.
- Enter time-boxed hypercare.
Cells can run in parallel. Their tools may differ. Their gates do not.
The Workload Passport is the cell’s contract. It contains the owner, dependencies, data class, recovery requirement, destination pattern, test pack, cutover window, rollback point and acceptance criteria. If those fields are incomplete, the workload stays in the exception queue rather than consuming engineering capacity.
This is the shift from craft to production. The first workload teaches the system. The second proves whether the lesson became a reusable runbook. By the fifth, leadership should see lower flow time, fewer manual touches and a smaller exception rate. If not, the factory is only a renamed project team.
Lane 4: Assurance and Exit
The assurance lane proves that the service works and removes the old obligation.
A migration is complete only when the business owner accepts the service, performance is validated, backup and restore evidence exists, security controls are evidenced, operations accepts ownership, CMDB and monitoring are updated, and the source is retired under an approved disposal process.
The output is a signed Exit Evidence Pack.
That last step matters commercially. A copied VM is not a migrated workload. If hosts, licenses, provider capacity or support commitments remain in place, the cost base has not moved. You have added a destination rather than completed an exit.
Four gates stop optimism from entering production
The lanes create capacity. The gates protect quality.
Portfolio Gate: owner, renewal date, service criticality, dependencies, RTO/RPO and target decision are recorded.
Ready Gate: target capacity, network, identity, backup, monitoring, test plan, change window and rollback path are approved.
Cutover Gate: rehearsal passed, replication state is verified, acceptance criteria are agreed and communications are issued.
Exit Gate: the service is accepted, evidence is stored, operational records are updated, the source is retired and commercial retirement is confirmed.
A workload that fails a gate returns to the exception queue. It does not progress because the steering committee wants the dashboard to stay green.
Measure the factory, not the theatre
“VMs migrated” is a weak measure. A team can improve it while leaving difficult services, dual-running cost and support risk untouched.
Use six measures:
- Inventory coverage: services reconciled across technical and commercial systems.
- Ready backlog: services that have passed the Ready Gate.
- Factory throughput: services accepted and retired per week.
- Flow time: calendar time from accepted passport to Exit Gate.
- First-pass acceptance: services passing technical and business validation without rework.
- Exit economics: migration cost, dual-run cost, target run rate and retired source cost.
Add rollback events, blocked days, recovery-test results and critical dependency exceptions. These are not failure statistics. They are the factory’s learning signals.
When we scaled software from roughly €600,000 to €240 million ARR and worked through 15-plus acquisitions on the path to two €1.5 billion exits, operating leverage came from repeatable systems with visible exceptions—not from declaring every case unique. Infrastructure migrations follow the same logic. Standardize the common path. Make exceptions expensive and visible. Let evidence decide whether to scale.
The 30-day proof path
Thirty days will not complete a VMware exit. It should prove whether the exit mechanism works.
Days 1–5: establish portfolio truth
Reconcile vCenter, CMDB, backup, monitoring, billing and contract data. Build the Exit Control Book and identify renewal or support cliffs. Select three to five representative services, including one stateful service and one with meaningful dependencies. Do not use a tier-zero workload for the first proof.
Record the initial retain, move, replace or retire hypothesis for each candidate. The deliverables are a risk heat map, a proof cohort and an initial business case.
Days 6–10: build the thin destination
Implement only the platform capabilities required by the proof cohort. Validate identity, network, DNS, backup, restore, monitoring, security and support ownership. Complete the Workload Passports, runbooks, acceptance tests and rollback criteria before moving data.
The deliverable is an accepted landing-zone slice—not an unfinished platform with a promise to harden it later.
Days 11–15: run the first rehearsal
Replicate or convert non-production instances. Test connectivity, identity, application startup, data consistency, monitoring, backup and operator access. Measure elapsed time and manual effort. Record every undocumented dependency and exception.
The first rehearsal is supposed to expose weaknesses. Hiding them destroys the value of the proof.
Days 16–20: prove recovery and repeatability
Run a second rehearsal from the revised runbook. Exercise rollback or recovery in a safe environment. Ask the receiving operations team—not the migration engineers—to deploy, observe, restore and troubleshoot the service.
If the second run is not materially more predictable, stop adding workloads. Fix the mechanism.
Days 21–25: execute a controlled production proof
Move one suitable low- or medium-criticality service. Run technical and business acceptance. Measure outage, cutover time, defects, rework and hypercare demand. Keep the rollback path until the agreed stabilization point.
If governance does not permit production cutover, run a production-representative rehearsal and state clearly that operational risk remains unproven.
Days 26–30: make the scaling decision
Close the Exit Evidence Pack. Compare forecast and observed effort, downtime and cost. Calculate migration-cell capacity and identify the bottleneck. Build the next 90-day wave backlog.
Then decide: scale, redesign, pause or retain selected workloads.
The day-30 review should answer six questions:
- Can another team repeat the runbook?
- Can operations support the destination without the migration cell?
- Were restore and rollback actually tested?
- Is measured unit economics better than the current scenario?
- Can priority waves finish before contractual deadlines?
- Which workloads should deliberately remain on VMware?
Not every workload should leave
A factory is not an anti-VMware ideology. It is a decision and execution system.
Some workloads may remain temporarily because the migration economics do not work. Some may move to another VMware provider. Others may rehost on a different virtualization stack, replatform to managed services or containers, move to SaaS, or retire entirely.
Broadcom argues that a smaller provider ecosystem can improve scale and service quality. ECCO and CISPE argue that the changes create exclusion and lock-in. Your architecture should survive either interpretation. Preserve options, measure economics and avoid forcing every workload into one destination.
You do not need another six-month assessment that produces a target-state slide. Put one representative service through all four gates. Produce the evidence pack. Measure whether the process can repeat.
30 days to proof, not 6 months to recommendations.
Book a 30-minute strategy call
Sources
- CIO — European cloud watchdog on VMware licensing practices
- CISPE — Fourth European Cloud Competition Observatory Report
- Broadcom — VMware by Broadcom business transformation
- Broadcom — VMware Cloud Service Provider ecosystem
- Microsoft — Plan your cloud migration
- Google Cloud — Transferring large datasets
