IBM is shifting from legacy Processor Value Unit (PVU) licensing to Virtual Processor Core (VPC) metrics — driven by Cloud Paks, containerisation, and hybrid cloud strategy. This playbook covers the technical differences, cost implications, Cloud Pak bundling, compliance risks, and strategic recommendations for CIOs navigating this critical transition.
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.
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 — 4 vCPUs is 4 VPCs whether on Intel or POWER hardware, simplifying heterogeneous cloud environments.
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.
In 2020, IBM announced a drastic pricing revision for legacy PVU licences to stimulate demand for these new offerings. 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 ~20% off) were eliminated for many products if bought à la carte, making Cloud Pak bundles (licenced by VPC) comparatively cheaper.
Understanding the fundamental differences between these metrics is critical for cost modelling and compliance:
| Aspect | PVU (Processor Value Unit) | VPC (Virtual Processor Core) |
|---|---|---|
| Basis | Hardware-centric: each core assigned a PVU value based on processor type and performance | 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 deployment, 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 |
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.
The PVU-to-VPC transition can significantly alter costs. VPC metrics might save money in highly virtualised environments or on powerful hardware — 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–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 ~$30.8K versus MQ standalone with 560 PVUs at ~$65.7K — over double.
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. One IBM licensing expert noted that "One VPC licence of DataStage Enterprise modernisation = 70 PVUs — but if you have 100 or 120 PVU-rated cores, you need more than 1 VPC licence to cover it."
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/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 don't oversubscribe any component beyond your VPC pool. If you only need one specific product, a Cloud Pak might require more VPCs (and cost) than a standalone licence due to these conversion factors.
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/subscriptions over perpetual licences. A shift to VPC often coincides with a subscription model — Cloud Paks are available as S&S or term licences measured in VPC. While this aligns costs with usage, you must renew to continue usage rights, and third-party support options won't apply.
Need help modelling PVU-to-VPC conversion costs for your IBM estate? Our IBM licensing experts benchmark every scenario.
IBM Licensing Assessment →IBM's VPC model truly comes into play in container environments orchestrated by Kubernetes/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.
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.
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-licenced software and Licence Service reports for container-based software.
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.
If you run IBM workloads on multiple clusters (on-prem, cloud, etc.), each cluster's usage is counted separately unless you consolidate. IBM's Licence Service Reporter can automate this consolidation across the estate.
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 to overall Cloud Pak VPC consumption.
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.
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/Licence Service operation as a compliance control and get periodic internal reports.
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 — clear records of installations, clusters, and entitlement mapping are vital.
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 don't clearly show the conversion, you may be asked to prove entitlement under the new metric. Ensure old PVU entitlements are retired or reduced accordingly — compliance exposure arises if a conversion wasn't done properly.
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 won't tell you if you're overspending. Strive for accurate licence positioning. Reconcile ILMT/Licence Service reports with entitlements regularly to spot if you're significantly under or over. If over-licenced, that's an opportunity to reduce maintenance costs or negotiate credits toward VPC conversion.
IBM audits in the Cloud Pak era will ask for both ILMT data and Licence Service outputs. Maintain architectural diagrams showing where IBM software runs and how it's licenced. Stay current with IBM's latest licensing rules — Passport Advantage agreements and sub-capacity terms are periodically updated to incorporate containers and VPC changes.
IBM's metric change is a chance to realign and optimise how you consume IBM software. Here are strategic approaches:
Start with a clear picture of what IBM software you own and where it's deployed. Identify which licences are PVU-based, RVU-based, user-based, etc., and which (if any) are already VPC or Cloud Pak based. Use ILMT output to see PVU consumption by product — it shows what you're using versus entitlements. Collect renewal dates and support costs to target which licences to convert first.
Align current products to IBM's Cloud Pak offerings. IBM has Cloud Paks for Integration, Business Automation, Data, Security, Application, and others. Determine if the products you own are part of a Cloud Pak. If a significant portion of your portfolio aligns with one Cloud Pak, that's 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.
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 (which didn't exist under standalone PVU).
Consider a phased approach — move dev/test environments to containers/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.
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.
Clear actions for CIOs to manage IBM's PVU-to-VPC transition:
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.
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 — legacy pricing will be less favourable for these.
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.
Reconcile entitlements with actual usage. If moving to Cloud Paks, right-size the VPC count to match needs — don't simply convert all PVUs if your deployment won't require that many VPCs. Conversely, ensure new VPC licences cover the PVU capacity of your hardware (remembering 1 VPC may only equal 70 PVUs in many cases). Eliminate redundant licences.
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.
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.
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. IBM's shift is motivated by its strategic goals — use that as leverage to obtain concessions.
Approaching an IBM renewal or facing an audit? Get independent assessment and negotiation strategy.
IBM Negotiation Service →Whether you're facing a PVU-to-VPC conversion, an IBM audit, or an ELA renewal, Redress Compliance delivers vendor-independent advisory with a track record of saving Fortune 500 enterprises millions on IBM licensing.
Also managing Oracle, Microsoft, SAP, or Broadcom contracts? We cover all major vendors.
All Advisory Services →