What the new licensing model actually means for VMware Cloud Foundation and vSphere Foundation, from an architect’s point of view.
Before I get into the technical details, I want to be honest about where I stand. I have been a consistent critic of Broadcom’s actions in the VMware ecosystem since the acquisition. The pricing structure, the bundling that forces customers into full stacks whether they need them or not, and the end of small packages that used to serve smaller customers perfectly well, all of that remains a genuine problem. I still believe a lot of what has happened is a mess, and I have said so publicly more than once.
But credit where it is due. Slowly, and not without pain, Broadcom is fixing some things. The new licensing model in VCF 9.0 is one of those corrections. It is not perfect, and I will address the concerns later in this post, but the direction is right and deserves acknowledgment.
If you have worked with VMware for any reasonable length of time, you already know the old drill. You purchase your entitlement, receive a 25-character license key, paste that key into vCenter, into NSX, into each product that needs it, and move on with your day. That workflow has been part of VMware operations for more than a decade, and it is burned into every runbook, every design document, and every admin’s muscle memory.
With VCF 9.0 and vSphere Foundation 9.0, it is no longer available. No more keys. No more per-product activation. No more spreadsheet of which key went to which cluster. The entire licensing model has been redesigned around a central concept, the VCF Operations instance, and a Broadcom-hosted portal called the VCF Business Services console.
Is this online registration model new? Not really. We have been doing exactly this with HCX for years. You activate against a Broadcom-hosted portal, you get an entitlement back, you run the product. The same pattern is now standard across most enterprise software vendors. Whether the underlying motivation is piracy prevention, stopping customers from using the same license across multiple deployments, giving the vendor better visibility into real consumption, or simply matching what the rest of the industry has been doing for the best part of a decade, the end result is the same. This is how licensing works now. You can agree with it or disagree with it, accept it or walk away, but it is not going back to the old way.
This is not a cosmetic change. It is a structural one that affects how you design your management domain, plan upgrades, and run Day 2 operations on your private cloud. In this post, I want to walk through what actually changed, what I think works well, where I have concerns, and what you should do before you start your first VCF 9.0 deployment.
What Actually Changed
The short version: VCF 9.0 replaces 25-character license keys with subscription-based license files managed through VCF Operations. You register VCF Operations against the Broadcom portal once, download a license file, and from that point forward, the licensing authority for your entire SDDC lives inside that Operations instance.
The longer version is more interesting. A few specific design decisions stand out:
- Core pooling instead of per-product keys. When you purchase a VCF subscription, all of your entitled cores land in a single default license allocation for that product inside your Broadcom Site ID. You no longer have one key for vSphere, another for NSX, another for vSAN. You have a pool of cores, and you draw from it.
- vCenter is the assignment point. You assign your primary license to a vCenter instance. From that moment, every ESXi host attached to that vCenter, every NSX component, every VCF Automation component, is automatically licensed. You do not touch any other product to license it. That is a genuine simplification.
- Primary and add-on licenses. VCF and vSphere Foundation are primary licenses. vSAN capacity (in TiB) and VMware Private AI Foundation with NVIDIA are add-on licenses. You must assign the primary license first before any add-on can take effect. This is a cleaner mental model than the old world, where every SKU felt independent.
- Connected or disconnected registration. If your VCF Operations instance can reach the internet, you use connected mode to get an activation code that automatically pulls the license file. If you are on a dark site or your security posture does not allow outbound connections from the management domain, use disconnected mode and manually upload and download files between your environment and the Broadcom portal.
- 180-day usage reporting. This is the part many people miss on a first read. Your license must be refreshed with a usage report at least every 180 days. Connected mode handles this automatically. Disconnected mode requires you to generate a usage file, upload it to the portal, and import the refreshed license back into VCF Operations. Miss the window, and you enter a 90-day expiration grace period.
That last point is not a small footnote. The old model was fire-and-forget until the subscription term ended. The new model expects you to participate in a reporting loop every six months; otherwise, the environment will start warning you and eventually limit what you can do.
The Workflow in Practice
When I walk through this with customers, I find it helps to describe the actual sequence of steps because the diagram-level explanation hides much of the practical detail.
First, you deploy VCF Operations. This is now a mandatory component, not an optional one. In VCF 5.x, you could skip Aria Operations in smaller deployments and license everything directly. That option no longer exists in 9.x. If you want to license your environment, you need VCF Operations running and your management domain sized to accommodate it.
Second, VCF Operations runs in evaluation mode for up to 90 days after deployment. During that window, you must complete registration on the Broadcom portal. The clock starts ticking the moment you finish the install, not the moment you remember to log into vcf.broadcom.com.
Third, you register. You log in to the VCF Business Services console, select the licenses you want to bind to this environment, and the portal either provides an activation code (connected) or a license file (disconnected). At this point, you decide how to split your core pool. If you run a single VCF Operations instance across all your sites, you use the default allocation as-is. If you run one Operations instance per site or per business unit, you split the pool and assign a portion to each instance.
Fourth, you bring your vCenter instances under VCF Operations management and assign the primary license to each. This is where the cascade happens. Once vCenter is licensed, everything downstream is licensed automatically.
Fifth, and this is the ongoing part, you report usage at least every 180 days. In connected mode, this is a button click. In disconnected mode, it is a file exchange.
Portal View: The VCF Business Services Console
Broadcom has published two images that illustrate the portal experience and the Operations license dashboard. The first shows where subscriptions and default license allocations live in the VCF Business Services console. The second shows how license capacity and assignments are displayed inside VCF Operations itself. I have embedded both below for reference. Credit for the images belongs to Broadcom; I am using them here under fair use to illustrate the product behavior being discussed.
The four-step registration flow, from VCF Operations deployment to vCenter license assignment. Source: Broadcom.
The detailed registration workflow, showing how connected and disconnected modes diverge between the VCF Business Services console and VCF Operations. Source: Broadcom.
What I Think Works Well
The vCenter-cascade model is genuinely cleaner
In the old world, when you added a new NSX Edge cluster or spun up an HCX Manager, you had to remember to attach the right license key to the right component. That sounds trivial until you audit a large environment and find three unlicensed components that have been quietly running in evaluation for 80 days because someone forgot. The new model removes that class of mistake entirely. You license vCenter, and everything that connects to that vCenter is licensed.
Core pooling matches how customers actually think
Nobody I work with thinks of their entitlement as “four keys worth 500 cores each.” They think of it as “2000 cores of VCF, spread across the estate.” The pooling model finally matches that mental model. When you add capacity mid-term with an additional subscription, it just gets added to the pool. You do not receive a new key to track.
The portal is the single source of truth
Broadcom now owns the authoritative record of what you purchased, what you are using, and where you have capacity to grow. For anyone who has ever had to reconcile a MyVMware account against actual deployed keys during a true-up exercise, this is a real improvement. The usage analytics view in both VCF Operations and the Business Services console shows you consumption against entitlement in one place.
Primary and add-on is a sensible split
Treating VCF and vSphere Foundation as primary, and things like vSAN TiB capacity and Private AI Foundation as add-ons, is a logical model. It forces you to license the platform first, then layer in the capacity-based and specialized entitlements. It also makes capacity planning conversations easier because the primary license is always the anchor.
Where I Have Concerns
VCF Operations is now a hard dependency
This is the change I think will catch the most people off guard. In VCF 5.x, Aria Operations was strongly recommended but not strictly required for licensing. In 9.x, you cannot license your environment without a running VCF Operations instance. That means every deployment, regardless of size, must now plan for the CPU, RAM, and storage footprint of VCF Operations in the management domain. For a small deployment, that is a meaningful percentage of the total management overhead. For a large deployment, it is a rounding error, but for edge sites, branch deployments, or lab environments, it genuinely changes the math.
The 180-day reporting loop needs to be operationalized
Connected-mode customers will not feel this. Disconnected-mode customers absolutely will. If you run an air-gapped management domain, and many enterprises and service providers do, you now have a recurring operational task to generate a usage file, carry it to a connected system, upload it to the portal, download the refreshed license, and import it back. This is exactly the kind of task that gets forgotten, because it happens twice a year. I would strongly recommend building a calendar reminder, a ticket template, and a documented procedure before your first 180-day window closes. The 90-day grace period after that is forgiving, but you do not want to be the architect explaining to a CIO why management operations are being blocked because a reporting task was missed.
The VCF 9 licensing lifecycle: 90 days of evaluation, steady state with a 180-day reporting cadence, and a 90-day grace period after expiration before the environment is seriously impacted.
Disconnected mode adds real friction
Related to the point above, but worth calling out separately. Connected mode is clearly the path Broadcom expects most customers to take. Disconnected mode works, but it adds friction at every stage: initial registration, usage reporting, license refresh, and recovery from expiration. If your security policy allows a narrow outbound allow-list from VCF Operations to the Broadcom portal, I would seriously consider using it. The operational savings over three years are substantial.
The grace period is a trap if you misread it
The documentation is clear, but it deserves emphasis. After a license expires, you have 90 days of degraded operation before things really break. During those 90 days, management operations start to be restricted, notifications appear everywhere, and new workload creation eventually stops. Existing workloads continue to run, which is good. But ESX hosts can disconnect from vCenter, and most host management operations are prevented. If you rely on the full 90 days as your safety net, you are planning for a bad week. Treat the 180-day reporting deadline as your real deadline.
Mixed-version environments are supported, but they are not simple
Broadcom has done the right thing and allowed pre-9.0 components to continue using their existing license keys while you migrate. That is necessary because nobody upgrades an entire estate overnight. But it does mean that for the duration of your upgrade program, you are running two parallel licensing models: old-style keys on 8.x components, and VCF Operations-managed files on 9.x components. The VCF Operations instance you use for license management must itself be updated to handle 9+ licenses. Plan for a transition period, and do not assume the migration will be instantaneous.
During the 5.x-to-9.x transition, two licensing models run in parallel: classic keys on legacy components, and the VCF Operations-managed file model on new 9.x components. The same VCF Operations instance can manage both, once it has been updated.
What You Should Do Before You Upgrade to 9.x
If you are planning a VCF 9.0 deployment or an upgrade from 5.x, I would work through the following checklist before you touch a single host.
- Confirm your entitlement. Log into vcf.broadcom.com with an account that has licensing permissions for your Site ID. Verify that the subscriptions you expect to see are present, and that the core counts match your purchase orders. This is a five-minute task that prevents hours of friction down the line.
- Decide whether connected or disconnected. This decision drives your entire operational model. If you can make connected work, make connected work. If your security team will not allow it, start building the disconnected procedure now, not on the day you register.
- Size VCF Operations into your management domain. If your current design does not include VCF Operations, add it. Check the sizing guidance for your expected environment scale and confirm you have the resources to host it. This is non-optional in 9.x.
- Plan your pool split. If you run multiple VCF Operations instances across sites or business units, think through how you want to split the default license allocation. You can change this later, but it is easier to get it right the first time.
- Build the 180-day reporting procedure. Document who is responsible, when the task runs, what the escalation path is if it fails, and how the refreshed license gets validated. Put it in your operational runbook.
- Plan the mixed-version period. If you are upgrading from 8.x, identify which components move first, which stay on the old licensing model, and when the transition is expected to complete. Map which components belong to which licensing regime at each phase.
- Test registration in a lab first. The registration flow is new to everyone. Run through it end-to-end in a non-production environment before you do it in production. This is especially important for disconnected mode.
Closing Thoughts
My honest view, and I want to be clear about this after opening the post the way I did: this specific change is one of the things Broadcom is getting right. It was overdue, it is directionally correct, and it will be painful for a subset of customers in the short term. The underlying model, pooled capacity with a single primary license and a clean cascade to downstream components, is simpler and better than what it replaces. That deserves acknowledgment.
None of that changes my broader view of what has happened to the VMware ecosystem since the acquisition. The pricing is still what it is. The forced bundling is still what it is. The loss of smaller packages that once served smaller customers remains a real problem. A good registration flow does not fix any of those things, and I am not going to pretend otherwise. But on this particular piece, credit where it is due.
The biggest shift in the new licensing model is cultural, not technical. For years, VMware licensing was something you did once per subscription term and then ignored. The new model asks you to treat licensing as an ongoing operational activity, with a twice-yearly reporting cadence and a mandatory management component. If you approach it that way from the start, it works well. If you approach it as a one-time setup task and walk away, you will eventually be reminded.
I will be running through the registration flow on my own lab in the coming weeks, including the disconnected path, and I plan to write a follow-up post covering the hands-on experience with screenshots from the portal and VCF Operations. If you are going through this transition and have questions, please leave a comment.
If you have any questions or want to discuss this design, leave a comment or reach out to me on social media.
Note on images: The two initial images referenced in this post are from the official Broadcom Knowledge Base article on VCF 9 licensing. Credit and copyright remain with Broadcom; they are included here strictly as illustrative reference material. For the full official documentation, see the VCF 9 Licensing Overview on techdocs.
Share this article if you think it is worth sharing. If you have any questions or comments, leave them here or contact me on Twitter (yes, for me it’s not X, but still Twitter) or LinkedIn, since I am getting off Twitter.
