Capacity-based licensing: the buyer's guide.

01 Key findings

1. The model rewards large infrastructure and loose tracking. Capacity licensing counts the hardware software can run on, not the people using it — which is exactly the gap that produces oversized audit claims and surprise true-up bills.

2. Full capacity versus sub-capacity is the entire risk. Full capacity licenses every core in the host, and on a cluster potentially every core a workload could migrate to; sub-capacity licenses only allocated virtual resources but requires approved tracking to qualify.

3. Miss the tracking requirement and you revert to full capacity. If the approved tool is not deployed, or reports are missing for any period, the vendor is entitled to assess that period at full capacity — where the 200–400% inflation appears.

4. Virtualisation is where the claims are made. A workload using four virtual cores can sit on a 48-core host in a ten-host cluster; without bounded migration the vendor argues it is licensable against far more than four cores.

5. The metric you accept at signing governs every audit that follows. Negotiating a named-user or tracked sub-capacity basis, with a cluster cap, is worth more attention than the headline discount.

02 How the model works

Instead of counting people, capacity-based models count the hardware the software runs on, or could run on. The unit varies by vendor: physical or virtual cores, processor value units that weight cores by chip type, or allocated memory. The model made sense when software ran on dedicated physical servers, but virtualisation broke the simple mapping between hardware and usage, and that is where the cost risk now lives.

The critical distinction is full capacity versus sub-capacity. Full capacity licenses every core in the physical host, and on a cluster potentially every core the workload could ever migrate to, even if the software only uses a fraction. Sub-capacity licenses only the virtual resources actually allocated, but it requires approved tracking to qualify. This pairs with our software contract negotiation guide and the per-core models discussed in our contract terms analysis.

03 Metric types & rules

Capacity models differ in the unit they count, and the unit changes both the bill and the defence. The license always follows what the software can consume, so the discipline is to bound and document what it actually consumes.

The unit also determines where the audit risk concentrates. Core and PVU models reward precise tracking of virtual allocation and processor type; a missing report or an undocumented hardware change defaults you to a higher count. The escalation from a named-user baseline to an untracked full-capacity claim is stark:

04 The sub-capacity trap

A workload that should license a handful of allocated cores can, without the right tracking in place, be assessed against every core in a cluster it might theoretically migrate to. On a large virtualised estate that single distinction is the difference between a fair bill and a claim several multiples higher, which is why vendors examine virtualisation and tracking first in any capacity-based audit.

05 Virtualisation exposure

Virtualisation is the single largest source of capacity-based audit exposure, because it breaks the simple mapping between software and hardware that the model assumes. A workload that uses four virtual cores may sit on a host with 48 physical cores, in a cluster of ten such hosts. Without approved sub-capacity tracking and bounded migration, the vendor can argue the workload is licensable against far more than the four cores it uses, because the contract entitles full-capacity assessment wherever sub-capacity cannot be proven.

Moving capacity-licensed software to public cloud does not dissolve the model; it changes how the count is derived. Cloud instances expose vCPU counts that map to the vendor's licensing rules, and some vendors apply specific, sometimes unfavourable, conversion factors for their software running on competitors' clouds. Before lifting a capacity-licensed workload to cloud, confirm how the vendor counts cloud cores, whether bring-your-own-license terms apply, and whether the move changes your sub-capacity eligibility. The same dynamic drives the exposure covered in our container licensing rules guide.

06 Measurement & audit risk

Every capacity-licensing defence begins with knowing exactly what you run and how it is licensed, and most estates do not. An accurate inventory maps each capacity-licensed product to the hosts and clusters it runs on, the cores or units it consumes, the metric in its contract, and the tracking evidence that supports a sub-capacity position. Building that inventory often reveals immediate savings: products deployed more widely than entitled, workloads that could be consolidated onto fewer cores, and tracking gaps that need closing before they become audit findings.

The inventory is also the baseline against which quarterly reconciliation runs, so the one-time effort pays off continuously. These records connect directly to the events in our audit triggers guide and to building an effective license position; recognising which trigger is likely to fire tells you where your tracking needs to be airtight.

07 Optimisation framework

Four moves contain capacity-based risk. Weight them to your estate, but treat each as a standing operational responsibility rather than an audit-time scramble.

08 Our recommendation