PVU (Legacy)
Hardware-centric: each core assigned a PVU value based on processor type. POWER8 = 120 PVU/core, x86 = 70 PVU/core.
VPC (New Model)
Virtualisation-centric: 1 VPC = 1 virtual core regardless of CPU type. Simplified for cloud and hybrid deployments.
Cloud Paks
IBM’s container-based bundles on OpenShift driving VPC adoption. Bundle Red Hat entitlements with IBM middleware.
Compliance Tools
ILMT for VM sub-capacity, IBM Licence Service for containers. Both mandatory. Missing either triggers full-capacity assertion.
Table of Contents
1. Background: Why IBM Is Changing Metrics
From PVU to VPC, and IBM’s strategic motivation
The Legacy PVU Model
Processor Value Unit (PVU) licensing has been a cornerstone of IBM’s software pricing for years. Under PVU, each server core is assigned a PVU value based on processor type and performance. Powerful CPUs have higher PVU ratings per core, meaning more licence units (and cost) for the same software. For example, an IBM POWER8 core might be 120 PVUs versus 70 PVUs for an x86 core. PVU licensing supports “sub-capacity” licensing: with IBM’s ILMT tool, customers can licence only the cores allocated to VMs running IBM software rather than the entire server. For the complete PVU framework, see our IBM PVU licensing guide.
The New VPC Model
Virtual Processor Core (VPC) licensing is based on virtual CPU cores allocated to IBM software, regardless of the underlying physical processor type. One VPC generally corresponds to one vCPU (or one physical core if no virtualisation). If an application VM has four vCPUs, you need 4 VPC licences. The VPC count does not vary by hardware CPU type. Four vCPUs is 4 VPCs whether on Intel or POWER hardware, simplifying heterogeneous cloud environments.
IBM’s Strategic Motivation
After acquiring Red Hat in 2019, IBM pivoted toward hybrid cloud and containerisation. The flagship of this strategy is IBM Cloud Paks: containerised solution bundles on OpenShift that package traditional IBM middleware with cloud-native capabilities. IBM repackaged legacy software into Cloud Paks to drive container adoption, bundling Red Hat OpenShift entitlements and using VPC metrics for licensing. For the full Cloud Pak licensing framework, see our IBM Cloud Pak licensing playbook.
In 2020, IBM announced a drastic pricing revision for legacy PVU licences. IBM began removing volume discounts on traditional standalone licences (many of which use PVUs) and incentivising customers to move to Cloud Pak licensing. The highest volume discount tiers (previously up to approximately 20% off) were eliminated for many products if bought standalone, making Cloud Pak bundles (licensed by VPC) comparatively cheaper.
2. PVU vs. VPC: What’s the Difference?
Side-by-side comparison of the two licensing metrics
| Aspect | PVU (Processor Value Unit) | VPC (Virtual Processor Core) |
|---|---|---|
| Basis | Hardware-centric: each core assigned a PVU value based on processor type | Virtualisation-centric: 1 VPC = 1 virtual core allocated to IBM software |
| CPU Impact | Varies by chip: POWER8 = 120 PVU/core, x86 = 70 PVU/core | Same regardless of CPU type. 4 vCPUs = 4 VPCs on Intel or POWER |
| Calculation | Total PVUs = cores used × PVU per core (from IBM table) | Total VPCs = virtual cores allocated (or physical cores if bare metal) |
| Sub-Capacity | Supported via ILMT: licence only cores of VMs running IBM software | Supported via ILMT (VMs) and IBM Licence Service (containers) |
| Complexity | High: requires tracking hardware PVU tables, ILMT, processor-specific calculations | Lower: count vCPUs allocated, independent of hardware |
| Best For | Legacy on-premises deployments, existing perpetual licences | Cloud, containerised (OpenShift), and hybrid deployments |
| “Lower Of” Rule | N/A: PVU values are fixed per processor type | If virtual cores exceed physical cores on host, cap at physical core count |
| Availability | Being phased down; volume discounts removed for many products | IBM’s preferred model; available via Cloud Paks and direct VPC licences |
Why the change: PVU concerns the potential power of the processor; VPC concerns the actual computing allocated to the software. IBM is moving to VPC to align with cloud and container deployment models where resources are virtualised and elastic. VPC also makes IBM licensing more comparable to other vendors’ core-based licences and easier to manage when moving workloads between on-premises and cloud.
Dual availability: Many products are currently available under both PVU and VPC metrics. For example, IBM MQ, WebSphere, and DB2 can be purchased under old PVU metrics or via Cloud Paks (VPC). However, IBM’s pricing changes are nudging customers toward the latter, making the transition from PVU to VPC increasingly financially compelling.
3. Cost & Entitlement Implications
Licensing cost impact, conversion ratios, and Cloud Pak bundling
Licensing Cost Impact
The PVU-to-VPC transition can significantly alter costs. VPC metrics might save money in highly virtualised environments or on powerful hardware, as you pay by actual vCPUs used, not by a higher PVU value of an expensive server. Ten vCPUs allocated is ten VPCs regardless of hardware; under PVU, those same 10 vCPUs on a POWER server could equate to 1,200 PVUs versus 700 PVUs on x86.
However, IBM’s removal of PVU volume discounts makes sticking with the old model costly. Renewing or buying more PVU licences now often comes at 10 to 20% higher cost than before. Meanwhile, Cloud Pak VPC bundles are priced attractively, sometimes with additional discounts. One analysis showed an 8-core non-production environment for IBM MQ: Cloud Pak for Integration (VPC) cost approximately $30.8K versus MQ standalone with 560 PVUs at approximately $65.7K, over double.
Entitlements and Conversion
A key question: what to do with existing PVU entitlements? IBM’s official stance is you generally cannot mix PVU and VPC licensing for the same software instance. IBM provides trade-up (licence conversion) part numbers to convert PVU licences into VPC licences, often as part of Cloud Pak upgrades. A common conversion baseline is 70 PVUs = 1 VPC (reflecting the typical x86 PVU value). However, conversion ratios vary by product and situation.
Cloud Pak Bundling: Conversion Ratios
Moving to VPC via Cloud Paks unlocks a broader range of software capabilities under a unified entitlement. However, each included product has a specific conversion factor that dictates how many Cloud Pak VPCs are consumed when you use that product:
| Product (Cloud Pak for Integration) | VPCs per Core (Production) | VPCs per Core (Non-Production) |
|---|---|---|
| IBM MQ | 4 VPC per core | 8 VPC per core |
| IBM MQ Advanced | 2 VPC per core | 4 VPC per core |
These ratios reflect the relative value and weight of the components. The benefit of Cloud Pak is flexibility: you can switch VPCs to another included product as needed. The drawback is complexity in tracking consumption and ensuring you do not oversubscribe any component beyond your VPC pool.
Renewals and Contractual Changes
IBM reps strongly encourage moving to Cloud Pak or VPC metrics at renewal time, using carrots (special bundle pricing, extra software rights) and sticks (higher renewal costs for staying PVU). IBM is also increasingly promoting term licences and subscriptions over perpetual licences. A shift to VPC often coincides with a subscription model. While this aligns costs with usage, you must renew to continue usage rights, and third-party support options will not apply. For more on IBM Passport Advantage agreements, see our CIO playbook.
Need Help Modelling PVU-to-VPC Conversion Costs?
Our IBM licensing experts benchmark every scenario: staying on PVU versus converting to VPC/Cloud Pak, with conversion ratio verification and cost comparison. See our IBM licensing assessment service.
IBM Licensing Assessment →4. Cloud Paks & Container Licensing
IBM Licence Service, managing dual metrics, and container nuances
IBM’s VPC model truly comes into play in container environments orchestrated by Kubernetes and OpenShift. In such deployments, you typically run an IBM Licence Service in the cluster to track licence usage. It measures the vCPU limits of containers (pods) running IBM software.
Compliance Requirement: IBM Licence Service
IBM mandates using the IBM Licence Service for container sub-capacity eligibility. If you do not deploy it, IBM’s policy is to licence all CPU cores on all worker nodes where the software runs (worst-case full capacity). This is analogous to the ILMT requirement in VM environments. IBM provides a Licence Service Reporter that consolidates data from traditional ILMT (for VMs) and the container Licence Service, giving an enterprise-wide view of PVU and VPC consumption across hybrid environments.
Managing PVU and VPC Concurrently
During the transition, CIOs may oversee a mix of legacy and containerised deployments. For example, IBM WebSphere Application Server in VMs (tracked via ILMT, PVU metric) alongside newer Cloud Pak for Applications components in OpenShift (tracked via Licence Service, VPC metric). Ensuring both tools are deployed and reporting correctly is critical. IBM audits expect ILMT reports for PVU-licensed software and Licence Service reports for container-based software. For the full ILMT framework, see our IBM sub-capacity licensing and ILMT playbook.
Container Licensing Nuances
Peak Usage Counting
IBM typically counts a container’s highest assigned vCPU limit over a period to determine VPC consumption. If you temporarily burst a container’s CPU limit, your required licences increase accordingly, even if average usage is lower. Set resource quotas in line with licence entitlements.
Multi-Cluster Aggregation
If you run IBM workloads on multiple clusters (on-premises, cloud, and others), each cluster’s usage is counted separately unless you consolidate. IBM’s Licence Service Reporter can automate this consolidation across the estate.
Component-Level Tracking
In containerised Cloud Paks, each included product must be accounted for individually before converting to Cloud Pak VPCs. For example, in Cloud Pak for Business Automation, the Licence Service reports separate usage for Business Automation Workflow and Operational Decision Manager, which you then convert via their specified ratios.
5. Compliance Risks & Audit Considerations
Tooling requirements, mixed metrics, and audit defence
Any major licensing metric change brings compliance risk if not managed carefully. IBM software audits (typically conducted by IBM or Deloitte) will scrutinise deployments to ensure sufficient entitlements under the correct metric.
Tooling and Reporting Requirements
Running IBM’s official licence tracking tools is mandatory for sub-capacity compliance. For PVU and VPC on VMs: ILMT (or approved alternatives) must be deployed with regular reporting. For containers: IBM Licence Service must be active. Failure means IBM can assert full-capacity licensing, potentially a huge compliance gap. Treat ILMT and Licence Service operation as a compliance control.
Mixing Metrics
If you have the same product under different metrics (some instances under PVU, some under VPC in Cloud Pak), carefully segregate and document environments. You cannot “double cover” a single installation with PVU and VPC licences. In an audit, you must demonstrate which entitlements cover which deployments.
Conversion Documentation
If you executed PVU-to-VPC trade-ups, keep all documentation. New VPC entitlements may have unique identifiers. During an audit, if IBM’s records do not clearly show the conversion, you may be asked to prove entitlement under the new metric. Ensure old PVU entitlements are retired or reduced accordingly.
Over-Licensing vs Under-Licensing
Both are risks. Under-licensing exposes you to audit penalties and true-up costs. Over-licensing wastes budget. IBM auditors only care about compliance; they will not tell you if you are overspending. Strive for accurate licence positioning and reconcile ILMT and Licence Service reports with entitlements regularly.
Container Scaling
Temporarily bursting container CPU limits without accounting for the increased VPC requirement creates compliance exposure. IBM counts peak assigned vCPU limits, not average usage. Set and enforce resource quotas that align with your VPC entitlements.
IBM Audit on the Horizon?
IBM audits in the Cloud Pak era require both ILMT data and Licence Service outputs. Our specialists have defended hundreds of enterprises and know exactly where IBM’s methodology overstates exposure.
IBM Audit Defence Service →6. Managing the Transition Strategically
Five-step approach to realigning your IBM licensing
Take Inventory of IBM Software & Entitlements
Start with a clear picture of what IBM software you own and where it is deployed. Identify which licences are PVU-based, RVU-based, user-based, and which (if any) are already VPC or Cloud Pak based. Use ILMT output to see PVU consumption by product. Collect renewal dates and support costs to target which licences to convert first.
Map Products to Cloud Paks
Align current products to IBM’s Cloud Pak offerings (Integration, Business Automation, Data, Security, Application, and others). If a significant portion of your portfolio aligns with one Cloud Pak, that is a strong candidate for VPC migration. Also consider new capabilities: Cloud Pak bundles include products you might not own yet. If those are in your roadmap, bundling adds value.
Analyse Financial Impact
Perform a cost comparison of staying on PVU versus moving to VPC/Cloud Pak. Factor in: current support costs for PVU licences (and projected increases), licence cost of Cloud Pak equivalents, conversion offer terms from IBM. Include soft benefits: Cloud Pak flexibility to reallocate licences among products and non-production licensing efficiencies.
Plan Transition Timing
Consider a phased approach: move dev/test environments to containers and Cloud Pak first (for non-prod efficiencies), then production. Or move one product line (Analytics, Integration) to a Cloud Pak while keeping others on existing licences. Align Cloud Pak adoption with expiration of current licences to avoid double-paying. If migrating mid-term, negotiate bridge credits from IBM.
Strengthen Governance & Expertise
Update SAM processes to accommodate VPC metrics. Train IT asset managers on the new rules. Adding vCPUs to a VM directly increases licence needs; container scaling impacts VPC usage. Institute quarterly internal compliance audits comparing deployed vCPU counts to entitlements. Consider engaging independent IBM licensing advisors for periodic reviews and before major negotiations.
7. CIO Recommendations
Seven-point action plan for the PVU-to-VPC transition
Baseline Your IBM Environment
Inventory all IBM software deployments and licence entitlements. Determine which are on PVU metrics and identify the corresponding VPC/Cloud Pak option. This mapping highlights where metric changes apply and where you have exposure or duplication.
Evaluate Conversion vs. Status Quo
For each major IBM product, compare the cost of staying on PVU (considering IBM’s price increases) versus converting to VPC via Cloud Pak. Prioritise products that IBM has bundled into Cloud Paks, as legacy pricing will be less favourable for these.
Plan Your Migration Path
Develop a phased plan to trade up PVU licences to VPC. Leverage IBM programmes that allow PVU-to-VPC trade-ups but verify the conversion ratios carefully. Do not mix PVU and VPC coverage on the same instance. Plan cut-overs where old licences are retired as new ones take over.
Optimise Entitlements & Avoid Over-Licensing
Reconcile entitlements with actual usage. If moving to Cloud Paks, right-size the VPC count to match needs. Do not simply convert all PVUs if your deployment will not require that many VPCs. Conversely, ensure new VPC licences cover the PVU capacity of your hardware. Eliminate redundant licences.
Strengthen Compliance Monitoring
Deploy and update IBM’s licence tracking tools across all environments. ILMT must cover all PVU and VPC deployments on VMs; IBM Licence Service must be installed on all OpenShift/Kubernetes clusters. Monitor regularly for any usage over entitlement and retain historical reports for audit readiness.
Engage in Proactive Audit Defence
Keep documentation of all licence purchases, trade-ups, and IBM communications about PVU/VPC transition. Perform annual internal self-audits to catch issues early. If an audit comes, you should clearly show what was converted or decommissioned. For our full audit approach, see the IBM software audit process playbook.
Leverage Expertise & Negotiate
Engage IBM-focused licensing consultants to validate your strategy. When negotiating with IBM, use independent benchmarks to push for favourable conversion terms, preserving previous discount levels in Cloud Paks, getting credit for remaining support on old licences, and securing price locks.
The transition from PVU to VPC is significant. With diligence and the right strategy, it can be managed smoothly and turned into an opportunity to optimise costs and modernise your IBM software investment. The complexity of PVU-to-VPC conversions, Cloud Pak ratios, and evolving IBM terms means expert input can save substantial money and risk.— Fredrik Filipsson, Co-Founder, Redress Compliance
Frequently Asked Questions
Common questions about IBM’s PVU-to-VPC transition
PVU is hardware-centric: each processor core is assigned a PVU value based on its type and performance, so the same number of cores costs more on powerful hardware. VPC is virtualisation-centric: 1 VPC = 1 virtual core allocated to IBM software, regardless of the underlying CPU type. VPC simplifies licensing in hybrid and cloud environments because the count stays the same whether you are on Intel, AMD, or POWER hardware.
PVU licensing is still available for many products, but IBM is making it increasingly less attractive. IBM has removed volume discounts on many PVU-based standalone licences and is pricing Cloud Pak VPC bundles more competitively. You can stay on PVU for now, but expect higher renewal costs and stronger pressure to migrate at each renewal cycle.
A common baseline conversion is 70 PVUs = 1 VPC, reflecting the typical x86 PVU value. However, this ratio varies by product and situation. Some “Hybrid” or “Modernisation” bundles define specific trade ratios that differ from 70:1. Always verify the conversion ratio for your specific products before committing.
No. IBM’s official stance is you generally cannot mix PVU and VPC licensing for the same software instance. A given deployment must be covered entirely with one metric or the other. However, you can have the same product under different metrics in different environments.
Yes, but with additional tooling for containers. For VMs, ILMT is still required for sub-capacity eligibility on both PVU and VPC licences. For container environments, IBM requires the separate IBM Licence Service. Without these tools, IBM can assert full-capacity licensing.
Each product within a Cloud Pak has a specific conversion factor determining how many Cloud Pak VPCs are consumed when you use that product. For example, IBM MQ requires 4 VPCs per core (production) while MQ Advanced requires 2 VPCs per core. Non-production ratios are typically double. These ratios reflect the relative value of each component.
Key risks include: missing tooling (ILMT or IBM Licence Service not deployed), incorrect conversion ratios creating compliance gaps, mixed metrics without proper documentation, incomplete conversion records making it hard to prove entitlement during audit, and container scaling without accounting for increased VPC requirements.
For enterprises with significant IBM estates, independent advisors typically deliver ROI many times their fee. They bring current benchmark data from hundreds of IBM deals, can verify PVU-to-VPC conversion calculations, identify compliance gaps, and negotiate favourable terms with IBM.