Broadcom’s VMware: A CTO’s Decision Framework for 2026

I’ve spent the last eighteen months in conversations with infrastructure architects who all started the same way: “We need to talk about our VMware renewal.” The follow-up sentence varies. Sometimes it’s a number — 4x, 6x, in one memorable case 11x. Sometimes it’s a deadline. Increasingly it’s both.

None of those conversations have been about whether to leave VMware. They’ve been about where to go, how fast, and what the consequences look like if the project slips past the renewal date. The strategic question was settled by Broadcom in 2024. What’s left is execution.

This piece is for the people running that execution. It’s not a vendor pitch — Storware happens to play in this space, but the framework below applies regardless of which backup or migration tools you end up with. I’ve tried to write the document I wished existed when our customers first started asking us these questions.

What actually changed, in plain language

Most coverage of the Broadcom changes reaches for adjectives — “seismic,” “disruptive,” “unprecedented.” The reality is more boring and more permanent. Four specific things happened:

• Perpetual licensing ended in early 2024. Every customer is on subscription, on one, three, or five-year terms.
• The product catalogue collapsed from over 160 SKUs to four primary bundles — VCF, VVF, vSphere Standard, vSphere Enterprise Plus. Standalone vSAN, NSX, and Aria are no longer sold as individual products.
• From April 10, 2025, the minimum licence purchase moved from 16 cores to 72 cores per product line. For shops running small or edge servers, you are now buying capacity that doesn’t physically exist.
• Late renewals carry a 20% penalty. Miss your anniversary date and the first-year subscription price is applied with that uplift, retroactively.

Aggregate price impact varies. The published numbers range from 150% to over 1,000%, with the worst hit landing on mid-market shops that previously ran vSphere Essentials Plus — discontinued, replaced by bundles that include features they never asked for. AT&T’s reported renewal proposal of 1,050% is the headline number, but it’s not the median.

The median, in my experience, is roughly 3x to 6x. That’s enough to fund a serious migration project. It is not enough to fund a five-year wait-and-see.

The strategic question was settled by Broadcom in 2024. What’s left is execution.

The mistake I see CTOs making most often

The most common error in these conversations isn’t choosing the wrong target platform. It’s choosing the target platform first.

Vendors love this framing, because it lets them lead with their product. “Migrate to Nutanix.” “Migrate to OpenStack.” “Migrate to Proxmox.” Each of those is a coherent destination for the right workload — but “the right workload” is the part that gets skipped.

Four questions need to be answered before the target platform conversation has any meaning. None of them are about the target platform.

Question 1: What is the workload profile?

A general-purpose Linux web tier, a stateful Oracle database with multi-pathed FC storage, a legacy Windows monolith from 2014 that nobody wants to touch, and an HPC cluster with GPU passthrough all want different target platforms. A migration plan that treats them as interchangeable VMs will succeed at the easy ones and fail at the hard ones — usually in production, usually loudly.

The discipline here is to bucket every VM into one of three categories before any vendor demo happens:

• Lift-and-shift candidates. Most general-purpose Linux and Windows workloads. The migration is mechanical — disk format conversion, driver injection, network re-mapping. These are the bulk of the estate.
• Refactor candidates. Applications close enough to end-of-life or container-suitable that the migration is a good moment to change architecture. This is a smaller bucket than people initially think.
• Special-handling cases. Hardware passthrough, vGPU, NSX-specific networking, vSAN-only storage features, latency-sensitive transactional workloads. These need individual treatment. Sometimes they don’t migrate at all — they wait for a hardware refresh or get re-architected.

In most estates I’ve seen, the ratio is roughly 70/15/15. The 70% drives your platform decision. The other 30% drives your special-handling budget.

Question 2: What does your operations team already know?

The cheapest target platform on paper is rarely the cheapest after you factor in re-skilling, hiring, and the productivity cost of a steep learning curve. This is the cost that vendor pitches don’t include, because vendors don’t pay it. Rough rule of thumb from my own observations:

If your team is small and your VMware estate isn’t, the platform with the lowest licence cost is almost certainly not the platform with the lowest total cost of ownership over three years.

Question 3: Where is your data legally allowed to live?

This is the question that’s most often skipped by US-headquartered vendors, because it doesn’t usually have a clean answer for them.

For European organisations, three threads matter. GDPR is the floor — personal data needs to be processed under EU jurisdiction or under an equivalent regime. NIS2, in force across EU member states from October 2024, raises the bar on incident reporting and supply-chain security and applies to a much broader set of organisations than its predecessor. DORA, applicable from January 2025, imposes specific operational resilience requirements on financial services entities and gives competent authorities direct oversight of critical ICT third-party providers — including data protection vendors.

Layered on top of all three is the CLOUD Act, which gives US authorities legal grounds to compel US-based vendors to produce data held anywhere in the world. This creates a documented conflict with GDPR Article 48 that EU regulators have been increasingly explicit about.

In practical terms: if your VMware exit is also a moment to reassess your US-vendor dependencies more broadly, the data protection vendor running alongside the new platform is part of that decision. If sovereignty doesn’t matter to your organisation, ignore this section. If it does, this is not a soft factor — it’s a constraint.

If your team is small and your VMware estate isn’t, the platform with the lowest licence cost is almost certainly not the platform with the lowest total cost of ownership over three years.

Question 4: When does your renewal hit?

The 20% late-renewal penalty changes the project-planning math. Your migration timeline is not dictated by your project plan. It is dictated by your renewal anniversary.

Three positions exist. You renew (with a price uplift). You migrate before the renewal (which means the project is on a hard deadline). Or you renew and migrate during the next subscription window (which is the path most large enterprises end up choosing, because the alternative is unrealistic given inventory complexity).

Whichever position you take, decide it deliberately. The worst outcome is missing the renewal date by accident and paying the penalty on top of a subscription you didn’t want.

Three migration approaches, and which one suits which estate

Once the four questions above are answered, the technical conversation becomes tractable. Three architectural patterns dominate VMware-to-anywhere migration. The trade-offs are real.

Cold migration is the simplest and most universal: power down the VM, export the disk image, convert the format if needed, import to the target. Tools like virt-v2v and qemu-img handle the work. The downtime per workload is hours, not minutes. Suitable for the long tail of low-criticality workloads, not for anything customer-facing.

Warm migration uses VMware’s Changed Block Tracking to do most of the data transfer while the source is running, then a short cutover for the delta. Most standalone commercial migration tools sit here — Coriolis, Hystax, vendor-specific toolkits. The downside is that you’re buying and operating a separate product for the duration of the migration window, then either discontinuing it or maintaining it as another stack component.

Backup-as-migration is the architectural approach my own company takes, which I’ll declare openly before describing it. The same data protection engine that already backs up the VMware environment can restore those backups onto a different hypervisor type. The backup is the migration source. The catalogue is unchanged. The product you needed for backup is the product you also use for migration — there’s no second SKU.

This third approach has three structural advantages that get under-discussed. First, your protection coverage is uninterrupted before, during, and after the move — there’s no gap during the project window. Second, the rollback path is intrinsic to the architecture: if a migrated workload misbehaves on the target, the original backup is still there in the catalogue and restores back to VMware mechanically identically. Third, the operational model after migration is the same one you had before — same WebUI, same policies, same RBAC, same team. The platform you’re protecting changes; the protection layer doesn’t.

The catch — and this is real — is that backup-as-migration only works if your data protection vendor actually supports both source and target as first-class platforms with feature parity. Most don’t. That’s a vendor selection question, not an architectural one.

Two mistakes worth naming explicitly

The two failure patterns I see most often:

Mistake one: treating the migration project as separate from the protection strategy. Teams choose a target platform, then choose a migration tool, then later realise their existing backup vendor doesn’t support the new platform, and end up with two replacement projects running in parallel. The second project is invariably worse-scoped than the first because budget and attention were already spent.

Mistake two: optimising the architecture for the migration window rather than the steady state. The migration is a phase. The steady state is years. A platform combination that’s slightly easier to migrate to but materially harder to operate after the project is the wrong choice. Make the steady-state decision first; let it constrain the migration approach, not the other way around.

What I’d actually do if I were sitting in that chair

Treat the four questions above as the work product of week one. Inventory bucketed into three categories. Honest assessment of operational maturity. Sovereignty constraints documented. Renewal date on the wall.

Then run a scoped proof of concept on the most representative workload in the lift-and-shift bucket — not the easiest, not the hardest, the most representative. Measure how long it actually takes, what manual intervention was required, what broke. That number, multiplied by the estate size with a realistic batching assumption, is your project duration. It’s almost always longer than the initial vendor estimate.

Decide your protection strategy and your migration strategy as one decision, not two. If they have to be different tools, accept that and budget for it. If they can be the same tool, that’s a structural simplification worth optimising for.

And then start. The hardest part of these projects isn’t technical. It’s overcoming the inertia of an environment that worked well enough for fifteen years.

If you’d like to discuss any of the above against your own environment, Storware tech team is reachable through storware.eu/book-meeting/