IBM licenses most of its software by Processor Value Unit (PVU), counting 70 PVUs per core on common x86 chips at a list price near $200 per PVU, which puts a single licensed core of middleware around $14,000 before discount and before any sub-capacity reduction. That metric, and the rules that decide when you may count virtual cores instead of physical ones, sit at the center of almost every IBM cost and every IBM audit. This guide sets out how IBM licensing works in 2026: the Passport Advantage program, the PVU and VPC metrics, sub-capacity and ILMT, Cloud Paks, Enterprise License Agreements, where audits start, and how to reduce both license and support cost.
Inside This Guide
How IBM licenses software
IBM does not use one metric. It uses a family of them, and the metric attached to a given product decides everything about its cost. The most common is the Processor Value Unit, a capacity-based unit that prices software against the processing power it runs on rather than the number of users. Alongside PVU, IBM uses Virtual Processor Core (VPC) for containerized and Cloud Pak products, Resource Value Unit (RVU) for products priced on a managed resource such as users or devices, and Authorized User or Floating User for seat-based tools. A single IBM estate routinely carries three or four metrics at once, which is why a clean entitlement position is harder to hold than with a single-metric vendor.
The practical consequence is that you cannot reason about IBM cost from a license count alone. You have to know the metric, the conversion rule from hardware to units, and whether you are entitled to count a sub-capacity figure or are stuck at full capacity. Get any of those wrong and the same deployment can be priced at five times its correct cost. This page is the pillar for our IBM coverage. The firm-side help sits in our IBM vendor practice, with deep dives in the clusters linked throughout.
IBM licensing is harder to manage than most because the rules were built up over three decades of acquisitions, each of which brought its own metric and its own part numbers. Lotus, Tivoli, Rational, Cognos, SPSS, and Red Hat all arrived with their own conventions, and IBM has only partially harmonized them. The result is an entitlement estate where one product is counted in PVUs, the next in authorized users, and a third in resource value units, often inside the same Passport Advantage site. A buyer who treats IBM as a single contract, rather than a portfolio of metrics each with its own counting rule, will misjudge both the compliance position and the cost.
Passport Advantage and the catalog
Passport Advantage is the contractual program through which most IBM software is bought, renewed, and supported. It holds your entitlements, your Subscription and Support (S&S) renewals, and the volume tier that sets your discount band. Almost every audit and every renewal traces back to what Passport Advantage records as your entitlement versus what IBM License Metric Tool measures as your deployment. Understanding the program is the prerequisite for controlling the cost, and the detail is in our IBM Passport Advantage guide.
Passport Advantage uses Relationship Suggested Volume Pricing, which sets your discount level by the cumulative volume you have transacted, expressed in points. The more you buy, the better the band, but the band is sticky and IBM rarely volunteers an improvement at renewal. Buyers who let the program run on autopilot pay the renewal uplift every year and never test whether their band, their S&S, or their product mix still fits. The table shows the headline elements that govern cost inside the program.
| Passport Advantage element | What it controls | Where the cost leaks |
|---|---|---|
| Relationship SVP band | Your discount level | Stale band never renegotiated |
| Subscription and Support (S&S) | Updates and support, ~20% of license/yr | Paid on shelfware you no longer run |
| Entitlement record | What you are licensed for | Mismatch with ILMT measurement |
| Anniversary and renewal date | When S&S re-prices | Auto-renewal with uplift, no review |
| Part numbers and metrics | How each product is counted | Wrong metric assumed in true-up |
PVU and processor licensing
The Processor Value Unit is the metric most likely to drive an unexpected IBM bill. IBM assigns a PVU rating to each processor type from its published table, and you license the total PVUs of the cores the software runs on. Common x86 cores rate at 70 PVUs each, while some IBM Power cores rate at 100 or 120, so the same software costs more per core on Power than on Intel. A product priced at roughly $200 per PVU therefore costs about $14,000 for one 70-PVU x86 core, multiplied across every core in scope.
The number that hurts is the core count, not the PVU rate, because virtualization can put a small piece of software on a large physical host. Without the right to count sub-capacity, you license every physical core in the server, or in some virtualization scenarios every core in the cluster the workload can move to. That is how a two-core Db2 instance becomes a sixty-four-core license. The remedy is sub-capacity licensing, covered below, and the full mechanics are in our IBM PVU licensing guide.
A worked example shows the scale. Take WebSphere Application Server running on a four-host VMware cluster, each host carrying two 16-core x86 processors, so 128 physical cores at 70 PVUs each, or 8,960 PVUs. At roughly $200 per PVU the full-capacity license is about $1.79M before discount. If the WebSphere virtual machines actually consume eight virtual cores, a valid sub-capacity position licenses 560 PVUs, near $112,000 before discount. Same software, same hosts, a sixteen-fold difference decided entirely by whether ILMT proves the sub-capacity figure. That gap is the prize in every IBM PVU review.
The core-count trap: Under PVU, cost tracks the cores the software can run on, not the cores it actually uses. A lightly used product placed on a large host, or free to migrate across a big cluster, can be licensed at the full physical core count unless you qualify for sub-capacity and prove it with ILMT. The metric, not the usage, sets the bill.
VPC and container licensing
IBM introduced the Virtual Processor Core metric to price software that runs in containers and on Cloud Paks. A VPC is, in effect, a virtual core made available to the software, and you license the peak number of VPCs the product consumes. For containerized workloads on OpenShift, this lets you license the cores allocated to the container rather than the whole host, which is closer to actual use than full-capacity PVU. The conversion and the measurement rules differ from PVU, and a buyer moving from traditional middleware to Cloud Paks has to relearn the counting, which is detailed in our IBM VPC licensing guide.
The catch is that VPC entitlements are often bundled inside a Cloud Pak, so the per-VPC price looks attractive while the bundle pushes you to buy capacity for components you do not use. The discipline is the same as with any IBM metric: measure the real consumption, license to it, and refuse to buy bundle capacity that sits idle.
Sub-capacity and ILMT
Sub-capacity licensing is the single most valuable right an IBM buyer holds, and it is conditional. It lets you license the virtual cores a product actually uses rather than every physical core in the host or cluster, which on a virtualized estate routinely cuts the licensable PVUs by 60 to 80 percent. The condition is that you deploy, configure, and maintain the IBM License Metric Tool (ILMT), run it correctly, and keep the quarterly reports it produces. Miss the condition and IBM is entitled to bill you at full capacity, regardless of what you actually ran.
This is where most IBM audit money is found. ILMT that is not installed, not covering every server, or not generating clean quarterly reports converts a sub-capacity entitlement back into a full-capacity liability. The reports are the proof; without them the entitlement is theoretical. The setup and reporting discipline are covered in our IBM ILMT guide and the wider rules in our IBM sub-capacity licensing guide.
| Sub-capacity requirement | If met | If not met |
|---|---|---|
| ILMT deployed within 90 days | License virtual cores used | Full physical capacity billed |
| All eligible servers covered | Sub-capacity applies estate-wide | Gaps billed at full capacity |
| Quarterly reports retained 2 years | Audit-ready proof of use | No defense, full-capacity claim |
| Reports reconciled to entitlement | Clean compliance position | True-up at IBM measurement |
Cloud Paks and bundling
Cloud Paks are IBM containerized software bundles that run on Red Hat OpenShift and are licensed in VPCs. Each pack groups several products under one entitlement, so a single VPC of Cloud Pak for Data can be traded across the data products it contains. The flexibility is real, but the packaging is also a way to sell capacity you do not need, because the headline per-VPC price is set against the full bundle while most buyers use a fraction of the components. The detail is in our IBM Cloud Paks licensing guide.
The bundling trap recurs across IBM. A renewal that folds standalone products into a Cloud Pak can look like a discount while increasing total VPC commitment, and the unused components become next year baseline. Treat every Cloud Pak proposal as a capacity-planning exercise: model the real VPC consumption of the components you will actually run before accepting a bundle sized to the whole pack. The common patterns are catalogued in our IBM bundling traps guide.
Enterprise License Agreements
An IBM Enterprise License Agreement (ELA) trades a fixed payment for broad deployment rights over a defined term, usually three years. For a fast-growing estate it can cap cost and remove the friction of per-deployment true-ups. For a flat or shrinking estate it can lock you into capacity you will not use and a renewal baseline you cannot easily reduce. The ELA is a commitment, not a discount, and its value depends entirely on whether your real consumption over the term exceeds what you would have paid transactionally.
The most expensive ELA mistake is treating the renewal as a formality. IBM prices the next ELA from your current consumption, so an over-bought first ELA becomes the floor for the second. The discipline is to measure actual deployment continuously, enter the renewal with that data, and be willing to drop back to transactional Passport Advantage for products you have stopped using. The strategy is in our IBM ELA guide and the firm-side help in our IBM ELA advisory.
An ELA is a floor, not a ceiling: IBM sets your next ELA price from your current consumption. Over-buy once and that figure anchors every future renewal. Size the ELA to measured demand, not to a vendor growth assumption, and keep the option to return unused products to transactional licensing at renewal.
Product-specific notes
The metric and the traps vary by product. The table summarizes how the most-audited IBM products are licensed in 2026 and where the cost concentrates, with deeper treatment in the linked clusters.
| Product | Primary metric | Where cost concentrates |
|---|---|---|
| WebSphere Application Server | PVU | Full-capacity exposure on large hosts |
| Db2 | PVU or VPC | Advanced editions, sub-capacity proof |
| MQ | PVU or VPC | High-availability nodes double-counted |
| Cognos Analytics | RVU or Authorized User | User true-ups on growth |
| Maximo | Authorized User or App Points | Application Points bundle sizing |
| watsonx | VPC | Cloud Pak capacity bought ahead of use |
WebSphere and MQ are the classic PVU audit targets because they often run on virtualized infrastructure where sub-capacity proof is weak. Db2 spans both PVU and VPC depending on edition and deployment, so the first question in any Db2 review is which metric actually applies. The detail for the data and integration products sits in our Db2, MQ, WebSphere, Cognos, Maximo, and watsonx guides.
IBM audits and how they start
IBM audits are run through its License Compliance team and, in many regions, third-party firms acting on the vendor behalf. They rarely start at random. The most common trigger is broken or missing ILMT, because it converts a sub-capacity entitlement into a full-capacity claim with no defense. Other triggers include a lapsed S&S that signals shelf-ware, a merger or divestiture that changes the entity, rapid virtualization growth, and a long gap since the last review. The patterns are set out in our IBM audit triggers guide.
The audit itself follows a predictable shape. IBM issues a formal notice citing the Passport Advantage audit clause, nominates a measurement period, and asks you to run its scripts or share ILMT output across the estate. The data you return becomes the basis of the findings, so the quality of your own measurement decides the outcome before any negotiation starts. Buyers who hand over raw tooling output without reconciling it first routinely see a full-capacity claim built on servers that were in scope for sub-capacity all along.
The defining feature of an IBM audit is that the metric does the work for IBM. If you cannot prove sub-capacity with clean ILMT reports, the claim defaults to full physical capacity, which is where the large numbers come from. The correct response is to control the measurement first: validate ILMT coverage, reconcile deployment to entitlement, and never accept the vendor tooling output as the agreed baseline without independent review. The process is in our IBM audit defense guide and the engagement in our IBM audit defense practice.
Support fee reduction
Subscription and Support typically runs around 20 percent of license value a year, and it is the most overlooked saving in the IBM estate because it renews quietly. The two largest reductions are removing S&S from products you no longer run, which requires the discipline to track real deployment, and consolidating renewals onto one anniversary so nothing renews on autopilot at an uplift. Where a product is stable and no longer needs IBM updates, dropping S&S or moving to a third-party support provider can cut the line item by half or more. The detail is in our IBM support fee reduction guide.
The caution is that re-instating IBM S&S after a lapse carries a back-payment penalty, so a support decision has to be deliberate and documented, not a gap left by accident. For optimization across both license and support, see our IBM license optimization practice.
Negotiation strategy
The IBM opening renewal number is a starting bid set against your current consumption and your stale discount band. The levers that move it are the same ones that move any capacity-based deal: prove your real deployment, dispute any full-capacity assumption with ILMT, time the deal to the IBM quarter and year end, and hold a credible alternative such as third-party support or a competing platform. The strongest position pairs a clean compliance picture with a willingness to walk from products you do not need.
Discount benchmarks are the other piece buyers rarely hold. IBM discount depth varies widely by product, volume, and quarter, and the vendor relies on the fact that most buyers cannot see what comparable organizations paid. A renewal that looks like a generous discount off list can still sit well above the market rate for the same product at the same volume. Entering the conversation with benchmark data, even directional, changes the anchor and is often worth more than any single contractual concession. The reference points are in our IBM discount benchmarks guide.
Timing matters because IBM, like most enterprise vendors, concentrates flexibility at period close. A renewal worked against the IBM fiscal year end, with measured deployment data in hand, consistently settles below one rushed at the buyer convenience. The firm-side help is our IBM negotiation practice and the broader software licensing advisory service.
The 2026 action plan
For any organization running IBM software in 2026, the sequence is the same. Confirm ILMT is deployed, complete, and producing clean quarterly reports, because that one control decides whether your sub-capacity rights are real. Reconcile what Passport Advantage says you own against what ILMT says you run, and resolve the gaps before IBM finds them. Strip S&S from shelf-ware and consolidate renewal dates. Model every Cloud Pak and ELA proposal against measured demand, not a vendor growth assumption. And enter every renewal with deployment data and a credible alternative in hand.
Done together, these steps move an IBM estate from a series of reactive true-ups to a controlled cost. Start with the clusters most relevant to your estate: ILMT, sub-capacity, Passport Advantage, and audit defense. For engagement help, our IBM practice covers audit defense, negotiation, ELA, and optimization end to end.