Third-Party VMware Support vs a Broadcom Subscription

Break-fix on the versions you already run, configuration and performance help, and the provider's own mitigations for published vulnerabilities. The good providers employ engineers who have run large vSphere estates and are faster to answer than a vendor queue. For an estate that is not changing, that is most of what support ever did.

What they cannot deliver is anything that requires Broadcom: a vendor patch, a new release, or an entitlement for a host the perpetual key does not cover. Those are not gaps in the provider; they are the definition of the model.

Three events end it. The estate grows past the key, which puts you out of licence with no way to buy in short of a full subscription. A vulnerability lands that needs a vendor patch, and the mitigation is a workaround your security team will not accept. Or an auditor, a customer or an insurer asks for a current entitlement, and there is none to show. Estates on third-party support should know which of those three is likeliest and how far away it is, because that distance is the real length of the arrangement.

Beyond patches and versions, it buys optionality: the right to add hosts, to change tier at renewal, and to be re-sized at each term end. It also buys the paperwork that regulated workloads and cyber-insurance questionnaires increasingly ask for. Against that sits the cost shape: per core, with a 16-core floor per CPU and 72 cores per order, so a very small estate pays for cores it does not have. That is the case where third-party support on a perpetual key is most defensible.

Most estates are not uniform. Some clusters run the workloads the business cannot lose; some are running out the clock on an application being retired. Subscribing the first group at the right tier and putting the second on third-party support with a fixed retirement date is a legitimate answer, and it is cheaper than subscribing everything. The mistakes are not writing the retirement date down, and letting a critical workload land on the legacy side because that is where it happened to be. Ask for the subscription quoted on the critical subset only, with the core count derived from those hosts, and compare that figure to the whole-estate number.

1. List every cluster with its workload, its growth expectation and its retirement date if it has one.
2. Anything with a compliance obligation, a growth expectation or no retirement date goes on the subscription side.
3. Price the subscription on that subset, at the right tier, on the one, three and five-year terms.
4. Price third-party support on the remainder, with a written end date.
5. If the remainder is empty, you have a subscription decision, not a support one. If the subscription side is empty, confirm with security and finance that the three exit events are genuinely distant.