If Broadcom did not renew your hosting provider's VCSP contract, a move is the likely outcome. How to pick a destination that avoids a second forced move.
If Broadcom did not renew your hosting provider's VMware Cloud Service Provider (VCSP) contract, expect to change providers or platforms when that provider's commitment term with Broadcom ends. A move is the likely outcome, so we think you should pick a destination that does not depend on one vendor keeping your provider on its partner list.
This post is for IT and infrastructure leads, and CTOs, whose VMs run on a hosting provider's VMware cloud. The timing matters because your provider's contract with Broadcom sets a date your service can end. If you learn that date late, you either move on someone else's schedule, possibly with less time than a migration needs, or sign another term under a partner program you do not control. The sections below cover what to ask your provider, how a transfer compares with leaving VMware, and when to sign.
Our view comes from how Broadcom has run the VCSP program. In 2025, it sent non-renewal notices to providers it did not invite into its new program. On January 26, 2026, it told another group of partners, many of them in Europe, that it would not renew "any of your VCSP partner contracts."
What Broadcom changed for providers
A provider that Broadcom did not renew can keep serving its existing customers until its current commitment term with Broadcom ends. It cannot renew that commitment. Under the January 2026 notices, any new customer contract must also end when that commitment ends. So your service can run until the term ends, if your provider chooses to keep it running.
Broadcom tells these providers to work with retained VCSP partners to move their customers across. It also ended its white label model for partners. One more route is worth checking before you plan a move: Broadcom's 2025 transition guidance lets a provider manage VMware licenses you own for a dedicated service, under conditions in Broadcom's agreement.
Your provider's term end is the deadline
Your plan runs to the end of that commitment term. The date is in your provider's contract with Broadcom, and your own agreement with the provider may end earlier or later.
Ask your provider for that end date in writing, along with its plan for that day. An excluded provider can hand its customers to a retained VCSP, as Broadcom recommends, or move its own platform off VMware. At least one European provider has said it is building that alternative.
Both plans change something under your workloads. Unless the retained provider takes over your current provider's hardware, a transfer still copies your VMs from one provider's hosts to another's, with a cutover window for each.
A transfer to a retained VCSP
A transfer keeps you on VMware. Your team's hypervisor skills and most of its runbooks carry over. Console access, backup jobs and integrations depend on the new provider, so check each one in the transfer offer.
The price of the next term is the weak point. Gartner clients report that per-core subscription licensing "has resulted in significant cost increases." If your retained provider's own VMware costs go up, expect to see that on its next price list.
A transfer also leaves your hosting tied to the partner program that just pushed your provider out. Broadcom has changed its VMware partner terms in 2024, in 2025 and again in January 2026. Broader lock-in costs, from negotiating power to skills, follow the same pattern.
Leaving VMware in the same move
Leaving VMware at the same time as you leave your provider makes the move bigger. Each VM is converted to a different hypervisor, and networks, storage and backup jobs are rebuilt on the new platform. In return, Broadcom's partner decisions no longer control your next renewal. Three destinations are worth pricing:
- A hyperscaler. It suits workloads you are ready to refactor onto native services. If you move VMs onto native instances without refactoring, they become subject to the hyperscaler's instance and data transfer pricing.
- Your own hardware, run by your team. Running upstream OpenStack on hosts you own gives you the platform outright. It also hands your team the upgrades, monitoring and on-call that your hosting provider used to carry. OpenStack is the wrong fit for a team with no one to own that work.
- A hosted OpenStack private cloud. You keep buying the platform as a service, with a provider running it for you. Because it is OpenStack, you can later move to another OpenStack cloud, or to your own team, using the same APIs.
Our VMware to OpenStack migration guide shows how networks and storage map across.
Your outgoing provider holds the keys
Whether you transfer, export or use a sync tool, you start from the VMware environment your provider runs. List the access you already have as a tenant and the access your provider has to grant.
For moves to OpenStack, we build MigrateKit, an open-source migration tool under the Apache 2.0 license. It syncs a VM's disks while the VM keeps running, so the VM only goes offline for a short cutover. It reads those disks through your current provider's VMware environment.
MigrateKit needs three things to read disks. First, a VMware endpoint that exposes the API, either an ESXi host or a vCenter server. Second, an account on that endpoint; for vCenter, the README lists the privileges, including disk access, change tracking, snapshots and powering off the VM. Third, VMware's Virtual Disk Development Kit (VDDK), which MigrateKit does not ship. Its README tells users to download VDDK 8.0.2 with a Broadcom developer account and accept the EULA.
That third item is now harder to get, because Broadcom no longer offers VDDK as a free public download. On a hosted service, ask your provider whether it holds a licensed VDDK copy and who will supply it.
Put the endpoint, the account and the VDDK question in the same written request as the term end date. Our professional services team builds the dependency view your migration order is based on and validates that order. Building it early means your request goes out while the provider still has time to answer it.
Three cases that change the answer
Moving once makes less sense in these cases:
- A long term with a provider that is leaving VMware itself. If your provider has years left on its term and is rebuilding on another platform, it may run the migration for you. Judge its new platform by the same test: does its next renewal depend on one vendor's partner program?
- Deep VMware dependencies and no spare team. If you cannot redesign those workloads before the term ends, one more term through a transfer can be the cheaper choice. Use that term to plan the exit.
- Workloads already refactoring toward public cloud services. A hyperscaler is the obvious place to land them, and stopping on OpenStack first adds a move.
If you also hold your own vSphere 8 licenses outside the hosted service, our vSphere 8 end of support post covers that separate date.
Signing the transfer offer
Sooner or later your provider will put a transfer in front of you: a retained VCSP's name, a next-term length and a price. That document is the decision point, because signing it sets how long you stay on VMware hosting and under whose partner status.
Measure the offer against a migration schedule built from your own estate: the pilot wave, every later wave, application validation and a rollback window for each. If that whole schedule fits inside your provider's remaining term, decline the transfer and move once. If it does not, sign for the shortest term the retained provider will accept, and start the pilot on the day you sign.
When the provider exit becomes a platform choice
Your provider's contract with Broadcom sets a date your service can end, so the exit runs on a clock whatever you decide. For exits that involve moving VMs, plan the inventory, cutovers and validation, whichever destination you choose. Moving from VMware to OpenStack can add conversion and network and storage reconfiguration on top of that work, and in exchange it takes your destination outside Broadcom's VCSP partner program.
Atmosphere, the OpenStack platform we build, is one such destination. It comes in Cloud, Hosted and On-Premise editions, so your estate can stay in a hosted model or come back to hardware you own while keeping the same OpenStack APIs. You can run it yourself, use our expert support or hand us full remote operations. MigrateKit moves the VMs across on the path described above. If you want an expert's read on your estate and your provider's dates before the offer arrives, you can talk it through with someone on our team.
