Capacity-Based Licensing: Buyer's Guide
How capacity-based licensing works, where full-capacity assessment inflates the count, and the four moves that keep your entitlement efficient.
Capacity-based licensing charges by the compute resource your software can consume, cores, processor value units, or memory, rather than by named users, and on virtualized estates it can inflate required entitlements by 200% to 400% if sub-capacity rules are not applied correctly. The model rewards vendors when your infrastructure is large and your tracking is loose, which is exactly the gap that produces oversized audit claims and surprise true-up bills.
This guide explains how capacity-based licensing works, where the inflation comes from, how to control the exposure, and how to negotiate a friendlier metric at signing. It pairs with our software contract negotiation guide and the firm's licensing advisory practice.
How capacity-based licensing 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 virtualization 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. Miss the tracking requirement and you revert to full capacity, which is where the 200% to 400% inflation appears. The same dynamic underlies the per-core models in our contract terms discussion.
Where the inflation comes from
The table below shows how the licensing basis escalates from a named-user baseline to an untracked full-capacity claim. The jump from a tracked sub-capacity position to an untracked one is the entire risk.
| Scenario | Licensing basis | Relative cost |
|---|---|---|
| Named user | Per person | Baseline |
| Sub-capacity, tracked | Allocated virtual cores | Moderate |
| Full capacity on small VM | All physical host cores | High |
| Full capacity on cluster | Every core that could run it | Very high |
| Untracked sub-capacity claim | Defaults to full capacity | Very high |
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 virtualized estate that single distinction is the difference between a fair bill and a claim several multiples higher, which is why vendors examine virtualization and tracking first in any capacity-based audit.
Compliance warning: Sub-capacity eligibility usually depends on running the vendor's approved tracking tool and keeping its reports for a defined retention period. If the tool is not deployed, or reports are missing for any period, the vendor is entitled to assess that period at full capacity. Verify your tracking is current and complete before any audit notice arrives; reconstructing it after the fact rarely satisfies the vendor and never satisfies it cheaply.
How to control the exposure
Four moves contain capacity-based risk. Deploy and maintain the approved sub-capacity tracking tool so you qualify for the lower basis, and treat its reporting as a continuous obligation rather than an audit-time scramble. Pin workloads to defined hosts or clusters so the licensable footprint is bounded rather than the whole estate, since unrestricted live migration expands the theoretical capacity you must license.
Reconcile entitlements to deployment quarterly so drift is caught while it is small and cheap to fix, not at audit when it is large and expensive. And negotiate the licensing metric itself at contract time, since some capacity models are far more buyer-friendly than others. These moves connect to the events in our audit triggers guide; recognizing which trigger is likely to fire tells you where your tracking needs to be airtight.
Negotiating the metric
The most durable fix is to negotiate a favorable metric before signing. Where the vendor offers a choice, a named-user or tracked sub-capacity basis usually beats full capacity for virtualized workloads, and locking the metric in the contract prevents a mid-term switch that inflates the count. Ask explicitly for sub-capacity rights, for the tracking obligation to be defined and reasonable, and for a contractual cap on how far the licensable footprint can extend across a cluster.
For CIOs standardizing licensing across a portfolio, aligning metrics so the same workload is licensed the same way under every vendor is a recurring theme in our CIO negotiation guide, and benchmarking the unit price so the per-core or per-PVU rate is competitive is covered in price benchmarking. The metric you accept at signing governs every audit that follows, so it is worth more attention than the headline discount.
Cores, PVUs, and the units that drive the bill
Capacity models differ in the unit they count, and the unit changes both the bill and the defense. Simple core-based models count physical or virtual cores directly. Processor value unit models weight each core by processor type, so the same core count can carry different license requirements depending on the chip, which makes accurate hardware inventory essential. Memory-based and resource-based models tie the license to allocated capacity rather than cores. In every case the principle is the same: the license 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. Knowing which unit governs each contract tells you which records the vendor will demand and which gaps will hurt, so you can close them before an audit rather than during one.
Virtualization is where the claims are made
Virtualization 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.
The defenses are specific. Run the approved tracking tool continuously and retain its reports for the full required period. Restrict live migration so the workload cannot roam across the entire cluster, which bounds the theoretical capacity. And reconcile allocation to entitlement every quarter so any drift surfaces while it is small. These are operational habits, not one-time projects, and the estates that maintain them sail through capacity audits while the estates that neglect them fund large claims.
Capacity licensing in the cloud
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 unfavorable, 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. A migration that looks cost-neutral on infrastructure can be expensive on licensing if the capacity rules shift against you.
Building the governance that keeps you compliant
Capacity-based licensing rewards continuous governance and punishes one-time projects, because the count drifts every time a workload moves, a host is added, or a cluster is reconfigured. The estates that stay compliant treat tracking and reconciliation as standing operational responsibilities with named owners, defined cadences, and retained evidence, not as audit-time scrambles. A quarterly reconciliation of entitlement to deployment catches drift while it is small, and a clear ownership model ensures the approved tracking tool is actually running and its reports are actually kept.
Governance also means controlling the infrastructure changes that expand the licensable footprint. Unrestricted live migration, casual host additions, and cluster reconfigurations all change the capacity the vendor can assess, often without anyone in licensing knowing. Tying infrastructure change management to a licensing check, so that a proposed change is evaluated for its license impact before it happens, prevents the slow accumulation of exposure that produces large audit claims years later.
The payoff is twofold. A well-governed estate sails through capacity audits because the evidence is current and the footprint is bounded, and it spends less in steady state because the count reflects actual use rather than accumulated drift. The cost of the governance is modest against the size of the claims it prevents, which is why it is the foundation of every capacity-licensing defense our advisors build.
Turning the model to your advantage
Capacity-based licensing is not inherently unfavorable; it is unfavorable only when it is left ungoverned. A buyer that runs approved sub-capacity tracking continuously, bounds workload migration, reconciles entitlement to deployment quarterly, and negotiates a friendly metric at signing pays for the capacity it actually uses and nothing more. The same model that produces 200% to 400% overcharges for the unprepared produces a fair, predictable bill for the disciplined.
The work is operational rather than clever: continuous tracking, bounded infrastructure, quarterly reconciliation, and a metric negotiated with care. None of it is difficult in isolation; the discipline is in doing it consistently rather than treating compliance as an audit-time emergency. Our advisors build the governance and negotiate the metric so capacity-based licensing stays efficient across every vendor that uses it, which is most of the enterprise software estate.
Start with an accurate inventory
Every capacity-licensing defense 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 to build it pays off continuously. Without it, you cannot know whether your deployment matches your entitlement, which means you are exposed to drift you cannot see and a vendor who will see it for you at audit. With it, capacity-based licensing becomes a measurable, manageable cost rather than an open-ended liability, which is the whole objective of governing the model rather than merely paying its bills.
The bottom line
Capacity-based licensing turns your infrastructure size into your license bill, and the difference between sub-capacity and full capacity is the difference between a fair cost and a 200% to 400% overcharge. Deploy approved tracking, bound your workloads, reconcile quarterly, and negotiate the metric at signing. Buyers who do all four keep capacity-based licensing efficient; those who do none fund the next audit claim. Our advisors build and defend the position across every capacity-licensed vendor.