IBM shifted its software estate to Virtual Processor Core and monthly subscription metrics, packaged inside Cloud Paks. The metric, not the brochure, sets your bill. Read how VPC counting works before you renew.
IBM now meters most software in Virtual Processor Cores inside Cloud Paks, which means the count, the container, and the term decide your bill.
The Virtual Processor Core, or VPC, is the count of processor cores available to the IBM software, not the full physical estate. On a virtualized host, that is the cores assigned to the virtual machine or container.
Conclusions first. Your VPC count is set by how you constrain the workload, so capping cores is a direct cost lever. IBM documents the subcapacity rules through Passport Advantage.
Subcapacity licensing lets you pay for the cores the software can use, not every core in the server. It requires the IBM License Metric Tool to report usage. Without it, IBM bills full capacity.
Cloud Paks are containerized bundles of IBM software that run on Red Hat OpenShift. You hold a pool of Cloud Pak VPCs, and each product consumes from the pool at a fixed conversion ratio.
The ratio is the point. A product that converts at a favorable ratio stretches your pool, while an unfavorable one drains it. IBM lists the Cloud Pak families, including Cloud Pak for Data, on its product pages.
Illustrative Cloud Pak VPC conversion logic
| Component | Conversion basis | Buyer side risk |
|---|---|---|
| Data product | 1 VPC per core used | Overcount if pods are unbounded |
| Integration product | Ratio per instance | Idle instances drain the pool |
| Automation product | VPC per worker node | Node sprawl inflates the count |
On OpenShift, IBM meters the cores allocated to the pods running the software. Kubernetes resource limits and quotas therefore become a licensing control, not just an operations setting.
A subscription is a term right to use, with support included, that stops at expiry. There is no residual perpetual entitlement, so the renewal is not optional if you keep running the software.
That reshapes leverage. The vendor knows you cannot simply stop paying support and keep the license, so you plan the renewal as a negotiation from day one.
The standard guidance is to renew the IBM subscription on the incumbent footprint to avoid disruption, then optimize later. We disagree. In the IBM estates we benchmarked across 2024 and 2025, deferring optimization meant buyers renewed 15 to 25 percent of VPCs that were already shelfware, and that inflated base then compounded at every uplift. The buyer side move is to right size the entitlement before the renewal, not after, because the renewal locks the base you pay against for the whole term. Optimization deferred is overpayment compounded.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
IBM stopped selling you a license and started selling you a meter. The buyer who manages the meter, the container limits, and the renewal date controls the bill. The buyer who only reads the brochure does not.
Start with evidence. A current ILMT deployment and clean reports turn an audit from a threat into a non event and prove you owe only what you used.
Then attack the count. Cap container cores, retire idle instances, and challenge the Cloud Pak conversion ratios in the contract. IBM frames its support and subscription terms through Passport Advantage support resources.
Treat VPC counting as continuous, not annual. Reconcile container limits and entitlement at each release so the metered peak never drifts ahead of what you planned to pay for.
White Paper · IBM
IBM is moving Processor Value Unit licensing to Virtual Processor Core. Read it free.
A Virtual Processor Core, or VPC, is a processor core made available to the IBM software, not the full physical server. On a virtual machine or container it is the cores assigned to that workload, which is why constraining cores controls the cost.
Yes. The IBM License Metric Tool remains required to claim subcapacity pricing. Without a current ILMT deployment and quarterly reports, IBM charges for the full physical capacity rather than the cores you actually used.
Each product draws from your Cloud Pak VPC pool at a fixed ratio. Favorable ratios stretch the pool and unfavorable ones drain it, so the conversion mix is a primary buyer side lever you should review before signing.
Yes. On Red Hat OpenShift, IBM meters the cores allocated to the pods running the software. Kubernetes resource limits and quotas therefore act as a licensing control, not only an operations setting.
The right to use stops. A subscription is a term entitlement with no residual perpetual license, so if you keep running the software you must renew. That is why the renewal date is a negotiation event you plan for early.
In the estates we benchmarked, uncapped renewals commonly arrived at 8 to 12 percent. Modeling that uplift in advance and negotiating a written cap is the difference between a planned renewal and a forced one.
In Cloud Pak VPCs tied to products that are no longer run and in subcapacity overcounts from missing ILMT data. Both are recoverable, but only if reclaimed before the renewal locks the base.
Before the subscription renews, while the footprint and ratios are still open. Independent buyer side review of VPC counts, Cloud Pak ratios, and ILMT evidence routinely finds avoidable cost the renewal would otherwise lock in.
We baseline your VPC consumption, test the Cloud Pak ratios, and build the buyer side counter before your subscription renews.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
