PVU to VPC, simpler math and different boundaries
PVU measures capacity through processor family multipliers with sub capacity via ILMT; VPC counts virtual cores directly. The transition is product specific, Cloud Paks lead it, and the standard line, that VPC is simply the modern successor and the swap is like for like, is exactly where the transition contracts trap buyers: simpler does not mean cheaper, and the conversion math protects IBM revenue on most products.
Prepared by Redress Compliance · August 7, 2026 · IBM advisory. Based on 25 to 35 Cloud Pak and container transitions worked 2024 to 2025.
Executive summary
Unbounded containers inflate the VPC count.
VPC runs on the virtual cores assigned to the workload, and on container platforms without resource limits set, VPC counts came in 20 to 40 percent above the equivalent PVU footprint: the metric bills the assignment, and an unlimited assignment bills the node.
Setting container resource limits is now a licensing control, not a platform hygiene item.
The reporting obligation moved and the penalty did not. The License Service replaced ILMT for containers, and missing or unarchived reports defaulted exposure to full capacity on 1 in 3 estates, the same cliff the ILMT 90 day rule enforces on PVU lines.
Sub capacity still applies under VPC on selected products, the audit trail is quarterly archived reports for two years, and the transition quarter runs both metrics in parallel or gambles the gap.
The conversion is product specific, and reading it at family level loses money.
WebSphere ND converts at parity, DB2 Advanced converts favorably at half a VPC per core.
And MQ Advanced converts unfavorably for Power estates, whose 120 to 140 PVU per core entitlements deserve retention rather than conversion. Cloud Pak bundles converted at list left 15 to 30 percent of entitlement value unused at the first anniversary, because the bundle scope was never mapped to the deployed products.
The transition addendum carries the traps. IBM's paper often includes a re evaluation clause letting IBM revisit the conversion math at the next renewal, which converts a one time negotiation into a recurring one on IBM's terms.
The counter set is contractual: a conversion lock for the term, notice provisions on any IBM initiated change, PVU retention documented for Power deployments, and the BIOS hyperthreading configuration recorded before anyone disputes what a core is.
The two metrics, decoded
| Element | PVU | VPC |
|---|---|---|
| The unit | Processor Value Units: a per core multiplier by processor family | One VPC per virtual core assigned, no family multiplier |
| The multipliers | Intel and AMD at 70, Power 9 at 120, Power 10 at 140, z Systems 100 to 250 | None: the simplification, and the repricing |
| Hyperthreading | Not separately counted | Logical cores from hyperthreading do not count: document the BIOS state |
| Sub capacity | ILMT required within 90 days of first sub capacity deployment | Still applies on selected products; the License Service covers containers |
| The failure mode | No ILMT: full capacity licensing of the server | No archived reports: the same cliff, on 1 in 3 estates we saw |
Read the conversion at product level, never family level. The published table runs product by product: WebSphere Application Server ND at parity, DB2 Advanced favorable at 0.5 VPC per core, MQ Advanced unfavorable for Power, and the Cloud Paks native in VPC.
Scoring each product favorable, neutral, or unfavorable against the table is the whole analysis, and skipping it is how Power estates convert 140 PVU cores at ratios built for x86.
Containers, where the new metric actually bites
The container rules are specific: the metric runs on virtual cores assigned to the container, not host cores; Kubernetes pods sharing CPU count once at the container level; Cloud Pak bundles cover their included products with OpenShift and RHEL entitlements separate, never bundled in.
And the License Service, not ILMT, produces the container reports the audit will request.
The two expensive failures follow directly: containers without resource limits billing the node instead of the workload, the 20 to 40 percent inflation, and reports that were never archived, the full capacity default.
The bundle mechanics and the entitlement stretching across the Cloud Pak families are worked in the Cloud Pak licensing guide, and the ILMT discipline that still governs the non container estate in the ILMT sub capacity guide.
The IBM Cloud Pak strategy brief
The transition worked end to end: the conversion tables, the bundle scope mapping, the container rules, and the addendum clauses that lock the math.
Get the white paper →The five transition risks, each with its mitigation
| Risk | The mitigation |
|---|---|
| Unfavorable conversion on Power | Document the deployment and negotiate retention of PVU on existing entitlements |
| Reporting gap during the transition | Run ILMT and the License Service on both metrics for one full quarterly cycle |
| Cloud Pak bundle scope creep | Read the inclusion list and map the current deployment to the bundle scope before converting |
| A hyperthreading dispute | Document the BIOS configuration: hyperthreading off evidences physical cores |
| The re evaluation clause | Negotiate a conversion lock for the contract term, with notice on any IBM initiated change |
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across transitions, 2024 to 2025
Across roughly 25 to 35 IBM Cloud Pak and container transitions Morten Andersen worked between 2024 and 2025, the move changed the bill in ways buyers did not model:
VPC counts above the PVU footprint wherever container resource limits were never set.
Entitlement unused at the first anniversary after conversions taken at list without a scope map.
The organizing insight is that the transition is a negotiation wearing a modernization costume: the conversion is bidirectional, contracts can reopen the metric question, and IBM opened it because the math protects IBM revenue on most products.
The buyer sequence answers in kind, inventory, current PVU consumption from the archived reports, the product level conversion scoring, the Cloud Pak fit analysis.
And the addendum negotiated with the lock and the exit ramp, with the estate placed in the portfolio context the ELA analysis and the audit defense guide frame.
The MQ pricing brief carries the metric decision on the line where the Power conversion bites hardest.
Your first five moves
- Inventory the estate and pull the archived PVU reports, because the transition negotiates from your consumption baseline or from IBM's assumption of it.
- Score the conversion product by product against the published table: favorable, neutral, unfavorable, with Power entitlements flagged for PVU retention.
- Set container resource limits before any VPC count runs, the 20 to 40 percent that bills the assignment instead of the node.
- Deploy the License Service and archive quarterly, because missing reports default to full capacity on the same cliff ILMT always had.
- Negotiate the addendum, not just the ratios: the conversion lock, the notice provision, and the dual reporting quarter. The IBM practice runs the transition with you.
Frequently asked questions
What is the difference between IBM PVU and VPC licensing?
PVU measures capacity through per core multipliers by processor family, 70 on Intel and AMD, 120 to 140 on Power, with sub capacity requiring ILMT. VPC counts virtual cores assigned to the workload directly, one VPC per core, no multiplier, with hyperthreading logical cores not counted.
Simpler math, different boundaries, and a product specific conversion between them.
Why is IBM moving from PVU to VPC?
The stated reason is simplification: the multipliers, sub capacity rules, and reporting burden compounded across estates. The commercial reality is that the conversion math protects IBM revenue on most products and reprices certain workloads, led by the Cloud Paks.
Simpler does not mean cheaper, which is why the product level conversion scoring is the analysis that matters.
Do containers change IBM licensing costs?
Materially: VPC runs on virtual cores assigned to containers, and where resource limits were not set, counts came in 20 to 40 percent above the equivalent PVU footprint because the metric bills the assignment.
Setting container limits is now a licensing control, and the License Service reports, archived quarterly, are the sub capacity evidence.
Is ILMT still required under VPC?
Yes, on selected products: the transition does not eliminate sub capacity reporting, it changes the unit and adds the License Service for containers.
The audit trail remains quarterly archived reports for two years, and missing or unarchived reports defaulted exposure to full capacity on 1 in 3 estates we reviewed, the same cliff the 90 day ILMT rule always enforced.
What is the conversion ratio from PVU to VPC?
Product specific, never family level: WebSphere ND converts at parity, DB2 Advanced favorably at 0.5 VPC per core, MQ Advanced unfavorably for Power estates, and the Cloud Paks are VPC native.
Score every product against the published table, and negotiate PVU retention on Power deployments where the conversion runs against you.
What should be negotiated in an IBM transition addendum?
The conversion lock for the contract term with notice on any IBM initiated change, because the standard re evaluation clause lets IBM revisit the math at renewal; PVU retention for documented Power deployments; the Cloud Pak bundle scope mapped before converting at list.
And one quarterly cycle of dual PVU and VPC reporting so the transition never opens a reporting gap.
