On an IBM estate the cheapest license matches the metric to real consumption
IBM measures most software by capacity, not by people. Processor Value Unit counts cores times a chip rating, Resource Value Unit counts a managed resource, and sub-capacity, the single largest cost control on a virtualized estate, only holds if the IBM License Metric Tool is installed and reporting. The recurring finding is estates paying for capacity they decommissioned years earlier, so the cheapest license is the one that matches the metric to how the workload is actually consumed, not the one the account team quoted first.
Prepared by Redress Compliance · August 9, 2026 · IBM advisory. Based on roughly 35 to 45 IBM software reviews run 2024 to 2025.
Executive summary
PVU counts cores times a chip rating, and the rating moves the number more than the core count does.
You take the core count, multiply by the PVU rating for that processor, and license the total, so a 16-core server at 70 PVU per core needs 1,120 PVU, and the rating is the variable buyers forget: the same core count carries a different PVU total on different hardware.
Headcount is irrelevant to a PVU license, the rating varies by chip so you must confirm the PVU per core for your exact processor, and the hypervisor and partition design change the eligible core count.
Confirming the PVU rating for the exact processor in use is usually worth more than negotiating the core count.
Sub-capacity is the single largest cost control on a virtualized estate, and it depends entirely on the IBM License Metric Tool.
Sub-capacity lets you license only the cores assigned to a workload rather than every core in the box, but IBM requires ILMT installed and producing quarterly reports.
And without those reports IBM is entitled to measure full physical capacity, which on a large cluster can be several times real usage.
The benefit is lost not by overuse but by paperwork: a lapsed agent, an unpatched server or a missed quarterly report converts a clean sub-capacity position into a full-capacity exposure, so treat ILMT as a compliance system, not an optional add-on.
Estates running sub-capacity without current ILMT faced full-capacity true-ups of 15 to 35 percent.
Most renewal quotes carry 20 to 40 percent shelfware, because capacity was sized for a peak that never returned.
The recurring finding across our reviews was estates paying for capacity they had decommissioned years earlier: 20 to 40 percent of PVU entitlements covered cores that had been retired or virtualized away, and the renewal is where you recover it, by bringing a current ILMT report.
A decommissioning log, and a costed metric comparison, because IBM negotiates against evidence, not assertions.
RVU adds a second trap: it prices by a resource the product manages, and the count can grow silently as the platform spreads, so an RVU bill climbs without any new purchase order unless you track the managed resource the way you track headcount on a user metric.
The metric sets the count and the buy model sets how you pay, so price every path across a full five years.
IBM offers perpetual plus support with the highest year-one and lowest five-year cost for stable estates, fixed term with lower entry and higher five-year cost for projects with an end date, and Cloud Pak entitlements where conversion ratios decide the value.
The standard seller pitch is that moving everything to Cloud Pak simplifies licensing and saves money; we disagree, because in two-thirds of the estates we benchmarked the platform move raised five-year cost once the conversion ratio and unused container capabilities were priced honestly.
Map each workload to its cheapest metric first, fix the sub-capacity reporting, and only then test whether a Cloud Pak conversion beats the metric you already hold. Simplicity on a slide is not a lower invoice.
The IBM license metrics at a glance
| Metric | Counts | Best fit | Audit risk |
|---|---|---|---|
| Processor Value Unit | Cores times chip rating | Middleware on dedicated hardware | High without ILMT |
| Resource Value Unit | A managed resource | Tools that scale by usage | Medium, the count creeps |
| Authorized User Single Install | Named person, one install | Small fixed populations | Low |
| Concurrent User | Simultaneous sessions | Shared, low-concurrency tools | Low |
PVU is a points value assigned to each processor core, and the points depend on the chip type, so the same core count can carry a different PVU total on different hardware.
RVU prices by a resource the product manages, a server, a user or a terabyte, and the catch is that the resource count can grow silently as the platform spreads, so an RVU bill climbs without any new purchase order unless you track the managed resource the way you track headcount on a user metric.
Authorized User Single Install and Concurrent User fit small, named populations and rarely suit large deployments, and 1 in 4 estates ran a workload on a metric that cost more than an available alternative for the same usage.
So the cheaper metric depends entirely on how the specific product is consumed.
The Passport Advantage machinery underneath sits in the Passport Advantage guide, and the sub-capacity rules in the sub-capacity and ILMT guide.
Why sub-capacity needs the License Metric Tool
- Sub-capacity is the rule that lets you license only the cores assigned to a workload rather than every core in the box, the single largest cost control on a virtualized IBM estate, and it depends entirely on tooling.
- ILMT must be installed and producing quarterly reports: without them IBM is entitled to measure full physical capacity, which on a large cluster can be several times your real usage and turns a routine renewal into a large true-up.
- The report has to prove three things: the eligible cores that ran the product and when, the peak usage because sub-capacity is measured on the high-water mark, and continuity, because gaps in reporting let IBM fall back to full capacity for the gap period.
- The benefit is lost by paperwork, not overuse: a lapsed agent, an unpatched server or a missed quarterly report converts a clean sub-capacity position into a full-capacity exposure, so treat ILMT as a compliance system.
- IBM often raises measurement questions in the quarter before a renewal: keep ILMT current, keep deployment records, and answer in writing, because a defensible sub-capacity position turns audit pressure into a routine renewal. The audit exposure math sits in the ELA and ILMT exposure report.
The IBM licensing and audit defense playbook
The metric map, the sub-capacity rules, the ILMT obligations, and the renewal levers that cut an over-provisioned IBM estate.
Get the white paper →Which buy model is cheaper over five years
The metric sets the count and the buy model sets how you pay for it, so price every path across a full five years before you let a discount on year one decide the model.
Perpetual plus support carries the highest year-one cost and the lowest five-year cost for stable, fully deployed estates; fixed term is cheaper to enter and more expensive over five years, so it fits projects with a defined end date.
And Cloud Pak entitlements are flexible across products, but the conversion ratios decide the value.
The standard IBM seller pitch is that moving everything to Cloud Pak entitlements simplifies licensing and saves money, and we disagree: in roughly two-thirds of the estates we benchmarked in 2024 and 2025.
The platform move raised five-year cost once the conversion ratio and the unused container capabilities were priced honestly.
The buyer-side move is to map each workload to its cheapest metric first, fix the sub-capacity reporting, and only then test whether a Cloud Pak conversion beats the metric you already hold, because simplicity on a slide is not the same as a lower invoice.
The renewal is where the stranded capacity is recovered, so bring a current ILMT report, a decommissioning log and a costed comparison of the metrics, reconcile entitlements to live cores and drop the difference, prove sub-capacity so usage is measured at the sub-capacity number.
Co-terminate renewal dates across products for volume leverage, and price the workload on every eligible metric and choose the lowest.
IBM negotiates against evidence, not assertions. The container packaging detail sits in the Cloud Pak licensing guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across IBM licensing engagements, 2024 to 2025
Across roughly 35 to 45 IBM software reviews Morten Andersen led between 2024 and 2025, the recurring finding was that estates paid for capacity they had decommissioned years earlier, and the common advice makes it worse.
The standard seller pitch is that moving everything to Cloud Pak entitlements simplifies licensing and saves money. We disagree:
Of entitlements covering cores that had been retired or virtualized away, recoverable at renewal with an ILMT report and a decommissioning log.
Estates where the platform move to Cloud Pak entitlements raised five-year cost once the conversion ratio and unused container capabilities were priced honestly.
Three patterns recurred: stranded capacity, with 20 to 40 percent of PVU entitlements covering cores that had been retired or virtualized away; missing measurement, with estates running sub-capacity without current ILMT facing full-capacity true-ups of 15 to 35 percent.
And metric mismatch, with 1 in 4 estates running a workload on a metric that cost more than an available alternative for the same usage.
On an IBM estate the cheapest license is the one that matches the metric to how the workload is actually consumed, not the one the account team quoted first, so the buyer-side sequence is to pull the current ILMT report and confirm it covers every product under sub-capacity.
List every PVU and RVU entitlement and match it to live in-use capacity, flag every entitlement tied to decommissioned or virtualized-away hardware as a drop candidate, confirm the PVU per core rating for each processor type, price each major workload on every eligible metric and record the cheapest.
Align renewal dates across products for volume leverage, and take the reconciliation and the costed metric comparison into the renewal as the opening position.
Confirming the PVU rating for the exact processor in use is usually worth more than negotiating the core count. The wider library sits in the IBM practice.
Your first five moves
- Pull the current ILMT report and confirm it covers every product under sub-capacity, because without continuous compliant reporting IBM measures full physical capacity, several times real usage.
- List every PVU and RVU entitlement and match it to live, in-use capacity, flagging everything tied to decommissioned or virtualized-away hardware as a drop candidate, the 20 to 40 percent shelfware.
- Confirm the PVU per core rating for each processor type, because the chip rating moves the number more than the core count, and it is usually worth more than negotiating the count.
- Price each major workload on every eligible metric and record the cheapest, because 1 in 4 estates ran a workload on a metric that cost more than an available alternative.
- Take the reconciliation and the costed metric comparison into the renewal with a decommissioning log, and only then test a Cloud Pak conversion. The IBM practice runs the position with you.
Frequently asked questions
How does IBM PVU licensing work?
PVU licensing multiplies the core count by a points rating set for the processor type, then licenses the total. Headcount is irrelevant, so the chip rating and the virtualization design drive the number more than anything else.
A 16-core server at 70 PVU per core needs 1,120 PVU, and the same core count carries a different total on different hardware, so confirming the PVU per core rating for your exact processor is the first and often most valuable check.
What is the difference between PVU and RVU?
PVU counts processor cores times a chip rating, so it scales with hardware.
RVU counts a managed resource such as servers, users or terabytes, so it scales with usage independently of hardware, and the resource count can grow silently as the platform spreads, climbing the bill without a new purchase order.
The two are not interchangeable, and the cheaper one depends on how the specific product is consumed, which is why 1 in 4 estates ran a workload on a costlier metric than an available alternative.
Do I need the IBM License Metric Tool?
Yes, if you license any product on a sub-capacity basis. Without current ILMT reports IBM is entitled to measure full physical capacity, which on a virtualized cluster can be several times your real usage and turns a routine renewal into a large true-up of 15 to 35 percent.
ILMT must be installed and producing quarterly reports that prove the eligible cores, the peak usage, and continuity, because gaps in reporting let IBM fall back to full capacity for the gap period.
What is IBM sub-capacity licensing?
Sub-capacity is the rule that lets you license only the cores assigned to a workload rather than every core in the server. It is the largest single cost control on a virtualized IBM estate, but it depends on continuous, compliant ILMT reporting to hold.
The benefit is lost not by overuse but by paperwork: a lapsed agent, an unpatched server or a missed quarterly report converts a clean sub-capacity position into a full-capacity exposure, so ILMT should be treated as a compliance system, not an optional add-on.
Is perpetual or term licensing cheaper for IBM software?
Perpetual plus support carries the highest year-one cost and the lowest five-year cost for stable, fully deployed estates. Fixed term is cheaper to enter and more expensive over five years, so it fits projects with a defined end date.
Cloud Pak entitlements are flexible but their conversion ratios decide the value. Always model every path across a full five years before letting a discount on year one decide the model, because simplicity on a slide is not a lower invoice.
How much shelfware is typical in an IBM estate?
In our 2024 to 2025 reviews, stranded capacity and unused entitlements ran 20 to 40 percent of the renewal value, with a median around 31 percent. Most of it came from capacity sized for a historical peak, or tied to hardware that had since been decommissioned or virtualized away.
It is recoverable at renewal by reconciling entitlements to live, in-use capacity and dropping the difference, provided you bring a current ILMT report and a decommissioning log as evidence.
How do you defend an IBM software audit?
Keep ILMT reports current, retain deployment and decommissioning records, and answer every measurement request in writing. A defensible sub-capacity position converts audit pressure into a routine renewal rather than a full-capacity true-up event.
IBM often raises measurement questions in the quarter before a renewal, so a current ILMT report, clean deployment records and a costed metric comparison turn that pressure into the buyer's opening position rather than the vendor's leverage.
