IBM license models in 2026. How PVU, RVU and sub capacity set what you pay.

IBM prices most software by capacity. PVU counts cores times a chip rating, RVU counts a managed resource, and sub capacity pricing holds only while ILMT reports. Match each workload to the metric that fits its real consumption and most renewals shrink.

What are the main IBM license models?

IBM licenses most of its middleware by capacity, counting cores, servers or terabytes. Four metrics cover most of what enterprise buyers hold: Processor Value Unit (PVU), Resource Value Unit (RVU), Authorized User Single Install and Concurrent User.

The metric is set per product in its license information document, and many products can be bought on more than one. Which one costs less depends on how that product is consumed in your environment.

The contract mechanics behind all four metrics, from part numbers to support renewals, sit in our Passport Advantage guide. The rest of this page explains how each count works and where the money goes.

How is a PVU count calculated?

Take the activated processor cores available to the program, multiply by the PVU rating IBM assigns to that processor, and license the total. Headcount plays no part. A 16 core server at 70 PVU per core needs 1,120 PVU.

The rating is the variable buyers forget, and it changes the total more than the core count does. IBM rates a core by processor family and, for many families, by the maximum number of sockets the server model supports. The same 16 cores can therefore carry a different PVU total on different hardware.

Moving a product from a two socket Xeon host to a four socket one adds 480 PVU without adding a single core. Confirm the rating for each exact processor model against the current PVU table before you discuss the count. That check is usually worth more than negotiating the core count.

The hypervisor and partition design then decide how many of those cores are eligible. That is the sub capacity question covered below.

Why does an RVU bill grow without a purchase order?

RVU prices a resource the product manages or uses: a server, a user, a terabyte, or for some products the processor cores under management. Many RVU products convert the resource count into RVUs through a product specific tier table, so the price per resource falls as volume rises.

The risk is growth. As a monitoring, security or storage platform spreads, it picks up more servers and more terabytes, and the RVU requirement rises with them. No request passes through procurement, so track the managed resource each quarter the way you track headcount on a user metric. Our RVU licensing guide covers the product tables.

When do user metrics beat capacity metrics?

Authorized User Single Install counts each named person with access to one installation of the program. Concurrent User counts people using it at the same moment, and a person with several sessions open counts once. Both fit small, named populations and rarely suit large deployments, where the user count outruns what the same hardware would cost on PVU.

• A small, stable team on big hardware. A tool used by a handful of named engineers on a large shared server often costs less per user than per core.
• Occasional use by many people. A reporting or modeling tool that many staff open now and then, but few at once, suits Concurrent User.
• Capacity you cannot isolate. When the product shares a host sized for another workload and cannot be pinned to fewer cores, a user metric removes the hardware from the count.

Why does IBM sub capacity licensing need ILMT?

Sub capacity allows you to license only the cores assigned to a workload instead of every core in the box, and IBM grants it only while the IBM License Metric Tool (ILMT) is installed and reporting. New sub capacity customers must deploy ILMT within 90 days of their first eligible product going onto a virtualized server.

Without the reports, IBM is entitled to measure full physical capacity. On a large cluster that can be several times your real usage, which turns a routine renewal into a large true up. Sub capacity is the single largest cost control on a virtualized IBM environment, so run ILMT as a compliance system with an owner and a patch schedule.

What must the ILMT reports prove?

• Eligible cores. Which eligible virtual or physical cores ran each product, and when.
• Peak usage. Sub capacity is measured on the high water mark, so a brief spike during a migration or a failover test sets the count for the period.
• Continuity. Gaps in reporting allow IBM to fall back to full capacity for the gap period.
• Correct bundling. Each discovered component has to be assigned to the product you own in the Software Classification panel, or it can show up as a separate chargeable product.

IBM's terms treat a quarter as the longest interval allowed between reviewing and reconciling ILMT data, and busy virtual environments need monthly checks. IBM asks for the reports on request, which in practice means during an audit or just before a renewal.

The benefit is lost by paperwork rather than overuse. A lapsed agent, an unpatched server or a missed quarterly report converts a clean sub capacity position into a full capacity exposure.

How are containers counted?

Containers follow a separate rule. For Cloud Paks and other container deployments IBM accepts only the IBM License Service for tracking, counts one Virtual Processor Core (VPC) as one vCPU, and treats 70 PVU as equal to one vCPU. The eligibility detail is in our sub capacity and ILMT guide.

What does sub capacity save on a virtualized cluster?

Say you run IBM MQ in two virtual machines of 6 vCPUs each, on a VMware cluster of four hosts. Each host has two Intel Xeon sockets with 16 cores apiece, so the cluster holds 128 physical cores rated at 70 PVU each.

With ILMT reporting, you need 840 PVU. Without it, IBM can ask for 8,960, more than ten times as much. When the VMs move between hosts, ILMT follows them through its connection to vCenter, which is why that VM manager connection has to stay healthy. The audit exposure arithmetic for larger environments sits in our ELA and ILMT exposure report.

How do you check your own position?

• ILMT audit snapshot. Export one now and read it as an auditor would: products, PVU peaks and any periods with missing data.
• Dashboard warnings. Look for computers that have stopped reporting, outdated scanners and data condition warnings, and fix them before the quarter closes.
• VM manager connections. Confirm every vCenter or other hypervisor manager is connected and current, because ILMT needs host data to calculate sub capacity.
• Passport Advantage entitlements. Download your entitlement records from Passport Advantage Online and match each part to a live product in the snapshot.
• Decommissioning records. Pull change tickets or CMDB retirements for every host that carried IBM software, with dates.

Which IBM buy model is cheaper over five years?

For a stable, fully deployed workload, perpetual licenses plus support usually cost the least over five years, even though year one costs the most. Fixed term licenses are cheaper to enter and more expensive over five years, so they fit projects with a defined end date. Cloud Pak entitlements are flexible across products, and their conversion ratios decide the value.

The metric sets how many units you need, and the buy model sets how you pay for them. Price every path across a full five years before a discount on year one picks the model for you.

The example assumes a $100,000 perpetual license with the first year of support included and $20,000 a year of support after that, against a $45,000 annual term license. These are illustrative figures, not IBM prices. The lines cross in year four, so a workload you expect to retire within three years is cheaper on term.

Two details can change the answer. Perpetual support has to be renewed without a lapse, because reinstating lapsed support costs more than keeping it current. Term renewals are priced at the time of renewal unless you have a price hold in the quote.

Why we would not convert everything to Cloud Pak first

The standard IBM seller pitch is that moving everything to Cloud Pak entitlements simplifies licensing and saves money. We disagree. In roughly two thirds of the environments we benchmarked in 2024 and 2025, the platform move raised five year cost once the conversion ratio and the unused container capabilities were priced in full.

The better order is to map each workload to its cheapest metric, fix the sub capacity reporting, and only then test whether a Cloud Pak conversion beats the metric you already hold. A simpler contract structure has value, but only when the five year cost is lower as well. The container packaging detail sits in our Cloud Pak licensing guide.

What should you get from IBM before a Cloud Pak conversion?

• The ratio per component, in writing. IBM's container terms assume 1:1 where no ratio is stated, so get the figure for each product you would actually deploy.
• A deployment plan for two years. List which Cloud Pak capabilities you will run and which exist only on the proposal slide.
• The fate of your perpetual licenses. Confirm what happens to existing entitlements and their support if you convert, and whether you can return to them. Our note on protecting perpetual rights in a conversion has the clause wording.
• The VPC count on your hosts. Compare it with your current PVU count for the same workloads, using the PVU to VPC transition rules.

What have we seen in recent IBM license reviews?

Across roughly 35 to 45 IBM software reviews I led between 2024 and 2025, the most common finding was capacity still being paid for years after it was decommissioned. Three patterns came up again and again, and each carries a price.

• Stranded capacity. 20 to 40 percent of PVU entitlements covered cores that had been retired or virtualized away, with a median of 31 percent. Most of it was sized for a peak that never returned.
• Missing measurement. Customers running sub capacity without current ILMT reports faced full capacity true ups of 15 to 35 percent.
• Metric mismatch. 1 in 4 of the environments we reviewed ran a workload on a metric that cost more than an available alternative for the same usage.

Reconciling entitlements to live capacity, with an ILMT report in hand, reduced renewals by 24 percent on average.

The cheapest IBM license is the one that matches the metric to how the workload is actually consumed, not the one the account team quoted first.

How do you cut an IBM renewal with the right metric?

Bring three pieces of evidence to the renewal: a current ILMT report, a decommissioning log and a costed comparison of the metrics for each major product. IBM negotiates against evidence, and the renewal is where stranded capacity comes off the bill.

1. Reconcile entitlements to live cores and drop the difference from the renewal scope.
2. Prove sub capacity, so usage is measured at the sub capacity number.
3. Price each workload on every eligible metric and choose the lowest.
4. Align renewal dates across products, so you negotiate one larger renewal.

IBM often raises measurement questions in the quarter before a renewal. Keep ILMT current, keep deployment records and answer in writing, and a well documented sub capacity position turns that pressure into a routine renewal. Our guide to the IBM audit process covers the formal steps if it goes further.

What will the IBM account team say, and how should you answer?

What mistakes cost IBM buyers the most?

• Treating ILMT as a one time install. Agents lapse, scanners age and VM manager credentials expire. Each gap gives IBM a full capacity period to price.
• Renewing support on retired hardware. IBM's renewal quote lists every part you hold, so stranded entitlements keep costing support every year until you take them off the quote.
• Assuming 70 PVU per core everywhere. A four socket Xeon host is rated at 100 and larger servers at 120, so a hardware move can raise the requirement with no change in cores.
• Letting RVU counts drift. Without a quarterly count of the managed resource, the first time you see the growth is in IBM's audit findings.
• Answering audit questions on calls. Verbal answers get written into findings you did not review. Respond in writing, within scope.

What is the timeline before an IBM renewal?

What to do next

1. Pull the current ILMT report. Confirm it covers every product you license at sub capacity, because without continuous compliant reporting IBM measures full physical capacity.
2. List every PVU and RVU entitlement. Match each one to live, in use capacity and flag anything tied to decommissioned or virtualized away hardware as a drop candidate.
3. Confirm the PVU rating for each processor type. Check the exact model and socket count against IBM's table before you negotiate the count.
4. Price each major workload on every eligible metric. Record the cheapest, including user metrics where the population is small and stable.
5. Take the evidence into the renewal. Bring the reconciliation, the decommissioning log and the costed metric comparison as your opening position.
6. Test Cloud Pak last. Only once the metrics and the reporting are fixed, compare a conversion against what you already hold. The IBM practice runs the reconciliation with you.

Frequently asked questions