Plan B expires on 31 October: VMware with the licence included is ending in the cloud

There is a date on the calendar you did not set and it is going to shape your quarter: 31 October 2026. That day ends the Azure VMware Solution model in which the VMware licence came inside the node bill. From 1 November, to keep those nodes running you must supply a VMware Cloud Foundation key bought directly from Broadcom. On Google Cloud VMware Engine the same thing happened nine months ago. Today, 3 August, there are 89 days left. And the point is not the date: it is that for two years "I will just lift my vSphere into the hyperscaler" has been many people's favourite plan B for not deciding. That plan B was never a plan: it was an extension. And extensions expire.

The dates, undecorated

As Microsoft and Google publish them. Before any opinion, the calendar:

• 31 October 2026: end of Azure VMware Solution pay-as-you-go nodes with VCF included. Customers move to the BYOL SKUs and must provide a VCF licence key before 1 November 2026 to keep using the service.
• 16 October 2025: new pay-as-you-go nodes already use the BYOL SKUs and your own key. Anyone already on BYOL notices nothing. Which is to say: this does not start now, it has been running for nine months for anyone growing.
• 15 October 2025: anyone who bought reserved instances on or before that day keeps VCF included until their term ends. Microsoft put the reservation saving against pay-as-you-go at 30–50%. If that is you, your date is not 31 October: it is the last day of your reservation. Go and find it today.
• 1 November 2025: Google Cloud VMware Engine already made the same move. Its customers buy portable VCF subscriptions directly from Broadcom instead of the VCF-included service, and new committed use discounts after 15 October 2025 are signed with Broadcom.
• The wider frame: Broadcom has moved VCF on hyperscalers to a licence-portability-only operating model. The subscription is yours and covers hosts in your own data centre, hosts in the cloud, or a mix, and it moves with you as the estate shifts.

What changes is not the price: it is who you sign with

Until now, a VMware node in the cloud was one line on an invoice and one counterparty. The hyperscaler bought the software, folded it into the host price and billed it alongside storage and networking. From 1 November there are two contracts: infrastructure with Microsoft or Google, and software with Broadcom, with its own term, its own anniversary date and its own purchase minimums.

Portability, said without irony, is genuinely good: being able to move the same subscription between your own room and the cloud, in whatever split suits you each year, is exactly what people have been asking for since hybrid became a thing. Nobody should complain about that. What changes is not the quality of the mechanism, it is who sets the price and who you have to ask for an extension. You used to negotiate the whole thing with your cloud provider, who had an interest in keeping you. Now you negotiate the software with the vendor, whose interests are just as legitimate and considerably less aligned with yours.

And one nuance the headline swallows and that deserves saying out loud: Microsoft states that the Azure VMware Solution BYOL SKUs are priced below the ones with VCF included. The infrastructure side, therefore, goes down. So the honest question is not "are they raising my price?", it is whether the subscription you now buy from Broadcom costs more or less than that reduction. That subtraction is yours and can only be done with both quotes on the table. Nobody is going to settle it for you in a blog post, us included.

There is also an operational effect that slips under the radar: one more renewal date to watch, in a different place, owned by a different person. Projects rarely fall over on the big date, the one in the headlines. They fall over on the small one: the key somebody has to paste in on a Friday, the order that takes two weeks in the vendor's system, the anniversary that went by while someone was on holiday.

The myth: "I will move to the cloud and the problem goes away"

Moving an entire vSphere estate to Azure VMware Solution or Google Cloud VMware Engine is not a migration: it is a change of address. It takes the hypervisor, the operating model, the NSX and vSAN dependencies, the team's habits… and now the licence too, which travels with you in your pocket. That can be exactly the right call: there are rooms that have to close, leases that expire, cooling that has run out of headroom and hardware that will not take another year. Closing a data centre with a lift and shift is a textbook decision and sometimes the only one that fits the deadline.

What it is not is a way out of the licensing problem. The only way out of a licensing problem is changing product or negotiating the price with your eyes open. Everything else is postponement. Two weeks ago we wrote exactly this while looking back at the two years since VMware changed hands: the mass exodus never happened, most people stayed and paid. That is a perfectly defensible decision. What does not hold up is never having made it and calling "strategy" the fact that the date had not arrived yet.

Somebody else sets the calendar

31 October is not an isolated case, it is the tempo. In January 2026 Broadcom closed the VMware cloud service provider programme, with transactions to be completed by 31 March at the latest; from then on only a handful of authorised partners can sell those subscriptions. In March, the European cloud infrastructure providers' association filed a complaint with the European Commission asking for interim measures, claiming prices had risen tenfold since Broadcom took over VMware — their figure, not ours; Broadcom replied that it strongly disagrees and that the complaint misrepresents the market.

On 10 July 2026, five European user and provider associations — including the CIO bodies of France, Germany, Belgium and the Netherlands — signed a letter asking Brussels for those interim measures and a transition period of at least three years. That figure deserves the same caution as the previous one: it is a request from interested parties inside an open procedure, not an engineering estimate of how long moving an estate takes. But it says something about the order of magnitude the people negotiating this every day work with, and it contrasts with the deadline you have for a far smaller piece of paperwork. What is certainly not a strategy is planning on Brussels arriving in time: a competition case is not measured in months, and your date is.

The 72 cores that never were

In March 2025 a notice went round the distribution channel: from 10 April, the licensing minimum would go from 16 to 72 cores per order line, plus a 20% surcharge for anyone renewing off their anniversary date. That floor did not squeeze large estates — an order for a whole room clears 72 cores without breaking a sweat — it squeezed small ones: the standalone server, the branch office with two hosts, the lab. On that maths, licensing a server with one eight-core processor cost 72. There was a backlash, and the 72-core minimum was withdrawn; the one still in force is 16 cores per processor.

Nobody lied here and, in practice, it never came into force. Except for one detail: for a few weeks, the floor on a small purchase multiplied by four and a half on a spreadsheet, and then went back where it was. That is the lesson worth keeping. When you model the cost of staying, the number that matters is not today's price: it is the variance. What your CFO needs to know is how much it can change, in which direction and with how much notice. And meanwhile, the minimum that is in force already shows up on your bill: 16 cores per processor means a host with two eight-core CPUs licenses as 32. The floor is set by the vendor, not by your inventory.

The maths you can actually finish this week

You do not need to decide the future of your company's virtualisation in August. You need to reach September with six facts on the table, and none of the six requires a project: they require an afternoon and the right person in front of you.

• 1. Do you have pay-as-you-go nodes with the licence included? If yes, 31 October is yours. If you bought a reservation on or before 15 October 2025, write down the end date of your term: that day is your own private 31 October, and probably nobody has it written down.
• 2. Count cores the way the vendor counts them, not the way your inventory does: a minimum of 16 per processor. On estates with small CPUs, the gap between the two counts is half the budget.
• 3. The anniversary date of every subscription, with the full name of whoever watches it. If that person does not exist, you have already found something this afternoon.
• 4. What you actually use from the stack. NSX distributed firewalling, vSAN, site replication and recovery, live migration tooling. Each of these is either a legitimate reason to stay, or a specific piece of replacement work if you leave. What does not count is the brochure feature list: look at what is switched on.
• 5. How many terabytes move, and through what. Migrations get stuck on the window and on the link, hardly ever on the hypervisor. Available bandwidth between source and target sets the calendar long before any architectural decision does.
• 6. The uncomfortable question: if the next renewal went up another step, what would you do? If the answer is "pay", fine — that is an answer and you can budget for it. What costs money is silence.

When you should NOT move

The part that does not fit the headline: staying is usually the right answer in more cases than the industry admits. If you have a reservation with eighteen months left, you do not have an emergency: you have homework. If your operation depends on distributed firewalling, on a vSAN stretched across two rooms or on site recovery, changing hypervisor is not a long weekend: it is rewriting the recovery plan and testing it again, which is the part nobody budgets for. If the team is at capacity, if the critical application is being retired next year, or if the hardware refresh lands in three months, moving now adds risk in exchange for nothing.

VMware is not the expensive part. The expensive part is arriving at 20 October with an urgent purchase. In an urgent purchase you do not negotiate: you sign. And you sign the term you are offered, with the minimum you are offered, on the date you are offered.

How we look at it

We are not VMware resellers, nor Proxmox ones: we sell licences for neither, so there is no commission to defend here. We run Proxmox VE with Ceph in production, spread across several data centres, and we come from vSphere versions that no longer appear in compatibility tables. We have migrated companies from VMware to Proxmox and we have also recommended staying on VMware when the maths favoured staying. Before we move a single machine, we do the maths.

And it is only fair to say it just as plainly: the alternative has a calendar too. Proxmox VE 8 reaches end of support this August, and anyone who switched two years ago has their own upgrade pending right now. Changing vendor does not take the dates away: it changes who sets them, what being late costs and whether you get to choose the when. That is the whole difference, and it is not a small one.

When the conversation stops being about architecture and becomes about money — which is what happens almost every October — the honest comparison is not "cloud versus my room this month", it is the five-year maths, with hardware, power, hands and licences in the same table. Sometimes cloud wins; other times, colocation with your own iron wins. Sometimes staying exactly where you are and spending the effort elsewhere wins. Our job in infrastructure and cloud is to make sure that table exists before the deadline, not after it.

Nothing falls over on 31 October

Worth saying plainly, because the industry lives off scaring people and we do not: no virtual machine switches off by surprise that day and there is no apocalypse in the server room. What there is, is an administrative condition which, if unresolved, stops you doing what you needed to do exactly when you need it: grow, renew, move. Licensing disasters are not loud. They are an email saying the cluster cannot be expanded until a key arrives, in the week you needed to expand it.

So plan B was never lifting it into the cloud. Plan B is having the maths done before anyone asks you for the key. Eighty-nine days is plenty for that. For the other thing — deciding well, with the table in front of you and without rushing — it is just about enough.

Sources (verified on 3 August 2026): the Azure VMware Solution dates — end of pay-as-you-go with VCF included on 31 October 2026, licence key required before 1 November 2026, BYOL SKUs for new nodes since 16 October 2025, reservations bought on or before 15 October 2025 valid until end of term, the 30–50% estimated reservation saving against pay-as-you-go and the statement that the BYOL SKUs are priced below the VCF-included ones — come from Microsoft's advisories for customers and for partners on Microsoft Community Hub. The equivalent Google Cloud VMware Engine change on 1 November 2025 and the licence-portability-only model on hyperscalers, in SDxCentral (13 October 2025). The closure of the cloud service provider programme, the complaint filed with the European Commission in March 2026 (reported by The Register on 19 March), the tenfold price figure attributed to the complaining association and Broadcom's response, in The Register. The 10 July 2026 letter from five associations asking for interim measures and a transition period of at least three years, in the Reuters wire as carried on 15 July 2026. The notice of a 72-core minimum order from 10 April 2025 and the 20% surcharge for off-anniversary renewals, in The Register (28 March 2025); its subsequent withdrawal and the continuity of the 16-cores-per-processor minimum, in Born's Tech and Windows World (11 April 2025). Cover photo: "Data centers in Ashburn", by Theodore Christopher, CC0.