Convert IBM PVU to VPC without buying capacity twice

IBM is retiring Processor Value Unit pricing for Virtual Processor Core across Cloud Paks and modern offerings. The published 70 to 1 x86 ratio, a 90 day ILMT clock, and the dual metric audit window decide your 2026 bill.

Prepared by Redress Compliance · June 2026 · Representative IBM estate scenario (benchmark scenario, not a quote).

VPC counts cores. PVU weights them. That single change moves where your cost comes from and removes a lever you have relied on for years.

Under PVU, every core carries a rating tied to its processor family. An older Intel Xeon core is rated around 70 PVU, a current Xeon Platinum core around 100 PVU, an AMD EPYC core in the 80 to 110 band, and an IBM POWER core as high as 140 PVU. You licensed the weighted sum.

Under VPC, a core is a core. One allocated virtual core needs one VPC, whatever silicon it runs on. The processor family discount that quietly favored x86 over POWER disappears.

Where the per core weighting used to help you

On a 16 core x86 host at 100 PVU per core, full capacity was 1,600 PVU. The same 16 cores under VPC is simply 16 VPC. The translation looks clean until you price it, because the ratio and the capacity basis both change at once.

Figure 1. PVU rating varies by processor family. VPC is a flat count of one per allocated core. Source: IBM processor family ratings; gold bar shown at a notional height for comparison.

The same rule that governed PVU sub capacity now governs VPC, and it is enforced harder. To pay for the cores you allocate rather than every core on the host, you must run the IBM License Metric Tool.

IBM requires sub capacity VPC customers to install and configure a current ILMT within 90 days of the first sub capacity VPC deployment. Manual capacity counting is not accepted. Miss the window and the entitlement reverts to full physical capacity.

The three obligations that decide the bill

• Deploy on time: a current ILMT within 90 days of first VPC sub capacity install, or other IBM approved validated tool.
• Report quarterly: generate and retain the sub capacity report every quarter. A lapsed report period is treated as full capacity for that period.
• Retain the evidence: sub capacity terms require keeping the ILMT reports for at least two years, and an audit reaches back across them.

Containers sit in a carve out. Container licensing terms were not folded into the 90 day policy, yet you still license only the processor capacity made available to the container under the VPC model. Treat that as a clarification, not an exemption.

IBM publishes the ratios. You negotiate the inputs. The 70 to 1 x86 figure is the starting point, not the contract, because the ratio is set at the product level and the entitlement basis is open to discussion.

Read the conversion table at the product level, never the family level. Inside a Cloud Pak, the same entitlement converts into different amounts of capacity for different components, so the ratio table, not the headline, decides how far an entitlement stretches.

Benchmark scenario, not a quote. 14,000 / 70 = 200, 7,000 / 70 = 100, 4,200 / 70 = 60, totaling 25,200 PVU and 360 VPC.

Figure 2. The same 70 to 1 ratio yields very different VPC counts per product because the PVU holdings differ. Numbers match the conversion table above.

What you can actually move

• The capacity basis: right size the estate before conversion so you convert the cores you use, not the cores you happen to own.
• The trade up credit: negotiate the value of retired PVU entitlement against new VPC or Cloud Pak commitments.
• The ratio lock: fix the published ratio in the contract so a later IBM table revision cannot dilute your entitlement.

The risk peaks while you run both metrics at once. During the dual metric window your estate has PVU products, VPC products, and the ILMT configuration that proves sub capacity for both. A gap in any one defaults to full capacity.

Where the common advice on the PVU to VPC move is wrong

The standard reseller pitch is to convert the entire PVU estate to VPC at the first renewal to simplify the contract. We disagree.

In the IBM estates we have benchmarked, converting before the ILMT sub capacity baseline is clean locks the customer into capacity they are not using. The default without proven sub capacity is the full physical core count of every host.

The buyer side move is to prove sub capacity first, right size second, and convert third. Simplicity that doubles your effective core count is not a saving.

Sequence beats speed. The estate that converts flat or below its PVU baseline is the one that fixed the inputs before signing, not the one that converted fastest.

The cost of getting the sequence wrong is concrete. In the representative estate, the negotiated path lands 5 percent below the PVU baseline, while the full capacity default lands 57 percent above it.

Figure 3. Annual licensing cost across three transition outcomes. Benchmark scenario, not a quote. 567 - 360 = 207; 360 - 342 = 18.

The transition in three phases

The levers that hold the line

• Ratio lock: write the published conversion ratio into the contract so a later table revision cannot erode it.
• Sub capacity proof first: never convert a product whose sub capacity you cannot yet evidence in ILMT.
• Anniversary timing: align conversion to the renewal anniversary to avoid a mid term co term that triggers an uplift.
• No blanket Cloud Pak swap: price each component at its own ratio rather than accepting a single family level figure.

Convert the cores you use, not the cores you own. The metric changed. The discipline did not.

Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025.