IBM VPC licensing and the PVU to VPC transition. A simpler metric that is not always cheaper.

VPC drops the PVU processor multiplier and counts one unit per virtual core, but the conversion is product specific. Score each line, set container limits, keep Power on PVU where it loses value, and lock the ratios in the addendum.

How does IBM VPC licensing differ from PVU licensing?

PVU licensing charges Processor Value Units per core, at a value set by the processor family and server model. VPC licensing charges one Virtual Processor Core for each virtual core assigned to a workload, with no multiplier. The unit is simpler, but the cost depends on the product, the platform and your container settings.

Both metrics allow sub capacity licensing, so you pay only for the cores the software can use. Both also treat missing evidence the same way, and without the reports IBM charges full capacity.

How many PVUs does a core carry?

The IBM PVU table sets the value by processor and by the maximum number of sockets on the server. It is more granular than most summaries suggest, which matters for the conversion discussed below.

• Intel Xeon. 70 PVUs per core on two socket servers, 100 on four socket servers, 120 above four sockets.
• AMD EPYC. 70 PVUs per core in every configuration.
• POWER9 and POWER10. 70 on scale out servers such as the S922 and S1022, 100 on the E950 and E1050, 120 on the E980 and E1080.
• IBM Z. 100 or 120 per core, depending on the model.

Does hyperthreading count under IBM VPC licensing?

It depends on where the workload runs, and IBM applies a different rule in each setting.

• Physical server at full capacity. IBM counts physical cores and ignores threads.
• On premises virtual machine. Each vCPU counts as one core even when it is a thread, but the total for a host is capped at its physical cores.
• Eligible public cloud. 1 vCPU counts as 1 VPC or 70 PVUs, so every rented thread is billed and there is no host cap you can document.
• Containers. Two vCPUs per core count as one VPC when hyperthreading is on, and four or eight on SMT4 and SMT8 Power nodes. License Service applies this only once configured, and a cluster with mixed SMT levels gets the lowest factor.

Record your BIOS and SMT settings before anyone disputes what a core is.

Why is IBM moving customers from PVU to VPC?

IBM's stated reason is simplification, because multipliers, sub capacity rules and reporting add up across a large IBM footprint. The commercial effect is less neutral. The conversion terms protect IBM revenue on most products and reprice some workloads, led by the Cloud Paks, which are priced in VPC from the start.

The transition also runs product by product. WebSphere, DB2 and MQ each have their own conversion terms, and many products still sell on PVU alongside VPC. That gives you room to choose which lines convert and when.

Why we do not treat VPC as a like for like replacement

The usual line from IBM and many resellers is that VPC is the modern successor to PVU and the swap is like for like. We disagree, because in the transitions we worked the simpler unit rarely produced a smaller bill.

Value changed hands in the conversion itself: Power entitlements flattened, Cloud Pak scope went unused, and containers counted at node capacity. Score each product on its own and convert only the lines that come out neutral or better.

A simpler metric does not mean a cheaper one, and the conversion terms decide which of the two you get.

How does the PVU to VPC conversion work for each product?

Each product carries its own conversion, so the analysis runs line by line. Score every line as favorable, neutral or unfavorable against IBM's conversion terms for that product, and flag Power entitlements for PVU retention before anything is signed. The outcomes below are the terms we have seen in recent transitions.

The 2026 MQ pricing brief covers the metric decision on MQ, where the Power conversion costs most. The WebSphere licensing guide sets out the WebSphere editions and metrics.

Why do Power entitlements lose value in a core for core conversion?

A Power line bought at 100 or 120 PVUs per core becomes the same single VPC per core as an x86 line bought at 70. If the conversion maps licensed cores one for one, the premium you paid disappears. The hypothetical 16 core example below shows the size of the gap.

On the E1080, a one for one mapping leaves you 11 VPCs short of what 1,920 PVUs buy at IBM's container and public cloud rate. That is roughly 40 percent of an entitlement you already paid for. Ask IBM which basis applies, and keep the line on PVU if the answer is cores.

The Power Systems licensing guide covers AIX and LPAR counting.

How are IBM VPC licenses counted in containers?

In containers, IBM counts the CPU limits set on each pod. A pod's capacity is the sum of its containers' CPU limits, totaled per product across the cluster and rounded up. A pod containing any container with no CPU limit counts at the full capacity of its worker node.

• The unit is the assignment. The metric counts virtual cores assigned to the container, not the host cores underneath.
• A node is a ceiling. Within one worker node, a product never counts above that node's capacity.
• Bundles count per product. For a Cloud Pak, IBM counts each bundled product and applies its Cloud Pak ratio, or 1:1 where none is stated.
• License Service is mandatory. IBM License Service produces the container reports an audit requests, since ILMT does not cover them. Without it, IBM licenses every core in the Kubernetes cluster.

Worked example: one missing CPU limit

Say three MQ pods each run on their own 16 core worker node with hyperthreading on, so each node shows 32 vCPUs. With a 2 vCPU limit per pod, the product needs 6 vCPUs, reported as 3 VPCs once the hyperthreading adjustment is configured.

Remove the limits and each pod counts at its node's 32 vCPUs, or 48 VPCs after the adjustment. That is 16 times the licensed quantity for the same workload. Container resource limits are now a licensing control and belong in your deployment standards.

What does a Cloud Pak include, and what does it leave out?

A Cloud Pak covers the IBM products on its inclusion list, each at its own ratio. Most Paks also carry a restricted Red Hat OpenShift entitlement that may run only the Pak's own software. Cloud Pak for Applications differs: full licenses include OpenShift as a bundled product at a ratio, and reserved licenses include none.

Your own applications or third party agents on those worker cores need unrestricted OpenShift cores, and RHEL for other servers is a separate Red Hat purchase. The Cloud Pak licensing guide works through the bundle ratios and how to stretch an entitlement across the Pak families.

Is ILMT still required after moving to VPC?

Yes, on selected products. The transition changes the unit and adds License Service for containers, but virtual machines and physical servers still rely on ILMT, installed within 90 days of the first sub capacity deployment. The ILMT sub capacity guide covers that side.

The audit trail for both tools is reports generated at least quarterly and archived for two years. During the transition, run ILMT and License Service in parallel on both metrics for one full quarterly cycle, so no period lacks evidence.

How to check your own position before IBM does

• ILMT audit snapshot. Generate it for the last full quarter and confirm each server shows the right processor type and PVU value.
• License Service audit snapshot. Pull it from each cluster and confirm the archive covers every quarter since the first container went live. License Service Reporter can combine several clusters.
• Pods without CPU limits. List every pod running IBM software and flag containers with no limit.
• Hyperthreading and SMT settings. Record the level per node and confirm License Service applies the adjustment.
• Entitlements. Reconcile your Passport Advantage entitlement records against both snapshots before any conversion quote arrives.

What are the main risks in a PVU to VPC transition?

Five risks recur in PVU to VPC transitions, and each has a specific counter. Most are settled in the contract before any conversion is processed.

Common mistakes that raise the VPC count

• Converting a whole product family at once. Favorable DB2 lines and unfavorable Power MQ lines end up in one trade, and the Power loss usually outweighs the gain.
• Letting IBM supply the baseline. Without archived PVU consumption reports, the conversion is priced on IBM's assumption of what you run.
• Buying a Cloud Pak for a single product. The bundle price assumes you deploy several of its products.

What have we seen in recent IBM VPC transitions?

Morten Andersen worked roughly 25 to 35 IBM Cloud Pak and container transitions in 2024 and 2025. Most changed the bill in ways the customer had not modeled, through three recurring patterns.

• Unbounded containers. Where resource limits were never set, VPC counts came in 20 to 40 percent above the equivalent PVU footprint.
• Missing reports. Missing or unarchived License Service reports pushed exposure to full capacity in 1 in 3 environments we reviewed, the same cliff the ILMT 90 day rule enforces on PVU lines.
• Stranded Cloud Pak value. Conversions taken at list without a scope map left 15 to 30 percent of Cloud Pak entitlement value unused at the first anniversary.

We read the transition as a negotiation presented as a modernization. The conversion works in both directions, contracts can reopen the metric question, and IBM opened it because the terms protect its revenue. Treat it as a commercial event and plan it alongside your IBM ELA renewal and your audit defense preparation.

What should an IBM PVU to VPC transition addendum include?

The addendum should lock the ratios for the term, require notice of IBM initiated changes, keep PVU on Power and set a dual reporting quarter. It must also remove the re evaluation clause often found in IBM's transition paper. That clause allows IBM to revisit the conversion at the next renewal, which makes a one time negotiation recurring.

• A conversion lock for the full term. The agreed ratios hold until the contract ends and cannot be revisited at renewal without your consent.
• Notice of IBM initiated changes. Written notice before any change to metrics, ratios or counting rules that affects converted lines, with the right to keep the prior terms.
• PVU retention for Power. Existing Power entitlements stay on PVU, with the deployment documented in the addendum.
• A dual reporting quarter. One quarterly cycle in which PVU and VPC reports run in parallel and neither can be used to claim a shortfall.
• The hyperthreading record. BIOS and SMT settings attached as a schedule, so the definition of a core is agreed before any audit.
• An exit ramp. A defined route out of the converted terms at renewal, such as the right to reduce converted quantities, if the VPC count runs above the level modeled at signing.
• Cloud Pak swap rights. The right to move entitlement between bundled products as your deployment changes. The swap and substitution clause guide has sample wording.

What the IBM account team will say, and how to answer

What to do next

1. Build the baseline. Inventory your IBM deployments and pull the archived PVU reports, because the transition is priced from your consumption baseline or from IBM's assumption of it.
2. Score each product. Rate every line favorable, neutral or unfavorable against the conversion table, with Power entitlements flagged for PVU retention.
3. Set container limits. Put CPU limits on every pod running IBM software before any VPC count runs.
4. Stand up License Service. Deploy it, configure the hyperthreading adjustment, and archive the snapshot every quarter.
5. Map the Cloud Pak scope. Match the bundle's inclusion list to what you deploy before accepting a Cloud Pak at list.
6. Negotiate the addendum. Ask for the conversion lock, the notice provision and the dual reporting quarter. Our IBM practice can run the transition with you.

Frequently asked questions