Conversion math, ILMT sub capacity implications, container licensing rules, and the buyer side risks as IBM transitions software lines from PVU to Virtual Processor Core metering.
IBM has been transitioning software products from the Processor Value Unit metric to the Virtual Processor Core metric across selected product lines since 2022. The transition is partial, product specific, and carries commercial implications that buyers routinely under estimate.
Read this article with the IBM practice, the ILMT sub capacity guide, the mainframe MLC hub, and the audit defense playbook.
We checked the metric mechanics against IBM's own documents rather than partner summaries: the IBM Cloud Paks page, IBM Cloud Pak foundational services, the IBM Passport Advantage program, and IBM sub capacity licensing.
The PVU model carried complexity. The processor family multipliers, the sub capacity rules, and the ILMT reporting burden compounded across the enterprise estate. VPC simplifies the metric. The transition also re prices certain workloads.
Processor Value Units measure compute capacity through a processor family multiplier. The PVU per core depends on the processor architecture, chip generation, and vendor.
| Processor family | PVU per core | Sub capacity rules |
|---|---|---|
| Intel Xeon E5 v3 and newer | 70 | ILMT required for sub capacity. |
| AMD EPYC | 70 | ILMT required for sub capacity. |
| IBM Power 9 | 120 | ILMT required for sub capacity. |
| IBM Power 10 | 140 | ILMT required for sub capacity. |
| IBM z Systems | 100 to 250 | Specialty engine rules apply. |
Sub capacity licensing requires ILMT installation, configuration, and reporting within 90 days of the first sub capacity deployment. Without ILMT, IBM rolls the buyer to full capacity at audit. A clean ILMT practice is the single highest value buyer side discipline on PVU lines.
Virtual Processor Core counts the virtual cores assigned to a workload. The metric is simpler. The boundaries are different. The sub capacity rules still apply on selected products.
The conversion ratios are product specific. The reference table is published by IBM and revised periodically. Read the conversion at the product level, not at the family level.
| Product | PVU baseline | VPC equivalent |
|---|---|---|
| WebSphere Application Server ND | 70 PVU per core | 1 VPC per core, equivalent |
| DB2 Advanced Enterprise | 70 PVU per core | 0.5 VPC per core, favorable |
| MQ Advanced | 120 PVU per core | 1 VPC per core, unfavorable for Power |
| Cloud Pak for Integration | Bundled | VPC native |
| Cloud Pak for Data | Bundled | VPC native |
| Cloud Pak for Business Automation | Bundled | VPC native |
The IBM License Metric Tool is the sub capacity reporting engine. The PVU to VPC transition does not eliminate ILMT. Selected products require sub capacity reporting under VPC.
The Cloud Pak family carries container metric conversion. The math runs on virtual cores assigned to the container, not on the host. The Cloud Pak entitlement converts to VPC native at published ratios.
The transition carries five recurring buyer side risks. Each risk has a discrete mitigation. Plan against all five before signing a transition addendum.
IBM transition addendums often include a re evaluation clause that allows IBM to revisit the conversion math at the next renewal. Read the clause carefully. Negotiate a lock that protects the conversion ratio for the contract term, with a notice provision for any IBM initiated change.
| Risk | Mitigation |
|---|---|
| Conversion ratio unfavorable on Power | Document existing Power deployment. Negotiate retention of PVU on existing entitlement. |
| ILMT reporting gap during transition | Maintain ILMT on both metrics for one quarterly cycle. |
| Cloud Pak bundle scope creep | Read the bundle inclusion list. Map current deployment to bundle scope. |
| Hyperthreading dispute | Document the BIOS configuration. Hyperthreading off documents physical cores. |
| Transition addendum re evaluation clause | Negotiate a conversion lock for the contract term. |
The eight step checklist below moves an IBM estate through the PVU to VPC transition with the conversion math and the audit posture protected in writing.
The standard line is that VPC is simply the modern, simpler successor to PVU, so the transition is a like for like swap. We disagree. In the transitions we ran, VPC counted differently on container platforms and, without resource limits and the License Service in place, the same workload cost more, not less. The buyer side move is to model the VPC count against your real container limits before signing, set namespace and pod limits deliberately, and keep License Service reports archived. Treating the move as a simple rename, which is the common framing, is how a modernization quietly raises the annual bill.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
PVU measures compute capacity through a processor family multiplier applied to physical cores. VPC measures compute capacity by counting the virtual cores assigned to a workload. PVU carries product specific multipliers by processor family. VPC carries a uniform one to one virtual core count without processor family multipliers.
Yes for selected products. The ILMT requirement carries forward for products that retain sub capacity reporting. Cloud Pak entitlements report in VPC native through ILMT. The clean buyer side practice is to maintain ILMT on both metrics during the transition window and continue ILMT reporting after the transition for affected products.
No. The transition is product specific and runs in phases. Cloud Paks led the transition. Selected standalone products moved during 2023 and 2024. Other products remain on PVU. Read the transition status at the product level, not at the family level.
No. Logical cores from hyperthreading do not count as virtual cores under VPC. The metric counts the assigned virtual cores at the operating system level, excluding hyperthreading multiplication. Document the BIOS configuration to support the audit position.
Existing PVU entitlements carry forward unless the buyer signs a transition addendum that converts them to VPC. The conversion math is favorable for some products and unfavorable for others. Read the conversion ratios product by product before signing any addendum. Document the existing deployment to preserve the option to retain PVU on selected products.
The transition addendum fits when the conversion math is neutral or favorable across the deployed estate, when the Cloud Pak bundle scope aligns with current product mix, and when the addendum carries a conversion lock for the contract term.
The addendum does not fit when the conversion math is unfavorable on Power deployments or when the re evaluation clause is open ended.
PVU licenses software against processor value units tied to the underlying core type, while VPC, or Virtual Processor Core, licenses against the virtual cores available to the software, which suits containers and cloud. The two do not map one to one, so a workload can cost more or less after conversion. Model your specific deployment before assuming VPC is cheaper.
For container deployments the IBM License Service generally replaces ILMT as the tool that measures VPC consumption, though ILMT still applies to traditional sub capacity PVU environments. Either way, you must deploy the correct tool and archive its reports, because missing measurement defaults your exposure to full capacity. Keep the reports for the period your agreement requires.
Redress runs the IBM transition engagement as a four workstream framework. Inventory and entitlement mapping, conversion math scoring, Cloud Pak fit assessment, and transition addendum negotiation. The work pulls the ILMT reports, maps the product mix to the conversion table, and lands the addendum envelope with the procurement and software asset management leadership.
Read the related Vendor Shield, the Renewal Program, the Benchmark Program, the Software Spend Assessment, the Benchmarking framework, the about us page, the management team page, the locations page, and the contact page.
A buyer side framework for the IBM audit cycle and the PVU to VPC transition. ILMT discipline, container licensing, conversion math, and the residual clause checklist.
Used across five hundred plus enterprise software engagements. Independent. Buyer side. Built for IBM customers running the next audit cycle or renewal cycle.
IBM Audit Defense Guide
Open the white paper in your browser. Corporate email only.
Open the Paper →We mapped 47 IBM products across the estate, scored the conversion math product by product, negotiated retention of PVU on the Power deployment, and converted Cloud Pak entitlements with a conversion lock. The transition envelope landed neutral on year one and protected the Power line for the full contract term.
We have run 500+ enterprise clients across 11 publishers. Every engagement starts with one conversation.
PVU to VPC transition signals, ILMT discipline patterns, Cloud Pak bundle math, and the wider IBM commercial leverage signals across every renewal cycle.
Once a month. Audit patterns, renewal benchmarks, vendor commercial signals across Oracle, Microsoft, SAP, Salesforce, IBM, Broadcom, AWS, Google Cloud, ServiceNow, Workday, Cisco, and the GenAI vendors. No follow up sales pressure.
Free providers (Gmail, Yahoo, Outlook) cannot subscribe. Work email only. Unsubscribe in one click.
