VPC quotes were sized on allocated virtual cores rather than the cores the workload actually used, inflating the count by 20 to 35 percent
Allocated is a provisioning decision. Used is a measurement. A conversion quote priced on the first will always be larger than one priced on the second, and only one of them describes your workload.
Prepared by Redress Compliance · August 17, 2026 · IBM advisory. 30 to 40 IBM re licensing engagements benchmarked, 2024 to 2025.
Executive summary
VPC quotes were sized on allocated virtual cores, not the cores actually used by the workload. Inflating the count by 20 to 35 percent, because allocation is a provisioning habit and consumption is a measurement.
The first conversion quote ran 15 to 30 percent above the count the buyer could defend. Across the re licensing engagements benchmarked, which makes the opening figure a starting position rather than an arithmetic result.
Sub capacity savings of 25 to 45 percent were available but went unclaimed. Because the measurement tool was not configured, so the entitlement existed and the evidence for it did not.
Conversion ratios moved 10 to 20 percent once real core density was modelled. The ratio is negotiable, and it is treated as a published constant by most buyers going through the transition.
What changes between the two metrics
The two metrics count different things, and the difference is where the conversion arithmetic is decided.
| Element | PVU | VPC |
|---|---|---|
| Unit counted | Physical cores | Virtual cores |
| Weighting | Per core weighting by processor type | Flat rate, no processor weighting |
| What inflates it | Processor type on the weighting table | Allocated rather than used cores |
| Who drives the move | Legacy footprint | Cloud Paks and container products are sold in VPC |
The last row explains why this is not an optional exercise. Cloud Paks and most container based IBM products are sold in VPC rather than PVU, which means the transition is driven by the product roadmap rather than by a buyer decision. You will arrive at a conversion conversation whether or not you planned one, and the only variable you control is whether you arrive with a modelled count or accept the one presented to you.
Allocated is a habit. Used is a measurement
Across roughly 30 to 40 IBM re licensing engagements benchmarked between 2024 and 2025, the first conversion quote IBM presented ran 15 to 30 percent above the count the buyer could defend. The largest single contributor is straightforward once stated: VPC quotes were sized on allocated virtual cores, not the cores actually used by the workload, which inflated the count by 20 to 35 percent on its own.
Allocation and consumption diverge for reasons that have nothing to do with licensing. Virtual cores are allocated generously because provisioning generously is operationally sensible, headroom is cheap inside a cluster, and nobody sizing a workload was thinking about a future licence metric. That habit is harmless until the allocation becomes the billing unit, at which point the accumulated headroom of an entire estate is priced. A count built on allocation is therefore not wrong in any technical sense; it is simply measuring the wrong thing, and the difference is 20 to 35 percent.
Two further levers sit alongside it and both are commonly left unused. Sub capacity savings of 25 to 45 percent were available but went unclaimed because the measurement tool was not configured, which is the recurring IBM pattern: the entitlement exists, the rules permit it, and the evidence required to claim it was never generated. The other is the conversion ratio itself, which moved 10 to 20 percent once the buyer modelled real core density against the IBM proposal. Most buyers treat the ratio as a published constant. It behaves like a negotiable term when it is met with a model.
The practical sequence follows from the fact that the transition is not optional. Because Cloud Paks and container based products are sold in VPC, you will face this conversation on the vendor's roadmap timing rather than your own. Build the used core measurement before the quote arrives, configure the measurement tool so the sub capacity position is evidenced rather than merely true, and model core density so the conversion ratio can be argued rather than accepted. The audit posture sits in the audit defence playbook, the sub capacity rules in sub capacity compliance, and the library in the IBM practice.
- Your agreements decoded into plain English before the auditor interprets them for you
- Entitlements, caps, and protections verified across your whole contract portfolio
- A defensible position paper generated in minutes, not weeks
The IBM audit defence playbook
The notice to settlement sequence: ILMT remediation, the evidence standards, the finding challenges, and the settlement structure.
Get the brief →How to run the conversion
- Measure used virtual cores, not allocated ones, which is the single correction worth 20 to 35 percent of the count.
- Configure the measurement tool before the conversion, since sub capacity savings of 25 to 45 percent went unclaimed purely for want of evidence.
- Model real core density against the IBM proposal, which moved conversion ratios 10 to 20 percent where buyers did it.
- Treat the conversion ratio as negotiable, not as a published constant, because it behaves like a term once it is met with a model.
- Plan for the roadmap timing, not yours, as Cloud Paks and container products are sold in VPC and will bring the conversation to you.
- Read the first quote as an opening position, given it ran 15 to 30 percent above the defensible count across the engagements benchmarked.
What the re licensing engagements showed, 2024 to 2025
Across roughly 30 to 40 IBM re licensing engagements benchmarked:
Count inflation from sizing VPC on allocated virtual cores rather than the cores the workload actually consumed.
Savings that were available under the rules but went unclaimed because the measurement tool had never been configured.
The first conversion quote ran 15 to 30 percent above the count the buyer could defend, and conversion ratios moved 10 to 20 percent once real core density was modelled against the proposal.
PVU multiplies physical cores by a per core weighting from the IBM table. VPC counts virtual cores at a flat rate with no processor weighting, so the entire question becomes which virtual cores count.
Your first five moves
- Measure actual used virtual cores per workload, separately from what was allocated.
- Configure the measurement tool now, so the sub capacity position is evidenced before the conversion opens.
- Model core density against the IBM proposal to move the conversion ratio.
- Treat the first quote as an opening position, not as arithmetic.
- Start before the roadmap forces it. The IBM practice builds the used core position with you.
Frequently asked questions
What is the difference between PVU and VPC?
PVU multiplies physical cores by a per core weighting from the IBM table. VPC counts virtual cores at a flat rate with no processor weighting, so the whole question becomes which virtual cores count.
Why do VPC quotes come in high?
Because they are sized on allocated virtual cores rather than the cores the workload actually used, which inflated the count by 20 to 35 percent across the engagements benchmarked.
Why is allocation so much larger than use?
Because provisioning generously is operationally sensible and headroom is cheap inside a cluster. Nobody sizing a workload was thinking about a future licence metric, and the accumulated headroom is what gets priced.
How far above the defensible count is the first quote?
15 to 30 percent. That makes it a starting position rather than an arithmetic result, and it should be read that way.
Is the conversion optional?
No. Cloud Paks and most container based IBM products are sold in VPC rather than PVU, so the transition is driven by the product roadmap. You will face the conversation on the vendor timing.
What about sub capacity?
Savings of 25 to 45 percent were available but went unclaimed because the measurement tool was not configured. The entitlement existed and the evidence required to claim it did not.
Is the conversion ratio negotiable?
Yes. It moved 10 to 20 percent once the buyer modelled real core density against the IBM proposal. Most buyers treat it as a published constant, and it behaves like a term when met with a model.
What should we measure first?
Used virtual cores per workload, separately from allocated. That single measurement is the largest correction available and it is the input every other lever depends on.
When should the tool be configured?
Before the conversion opens. Configuring it afterwards proves a position you can no longer use, since the count will already have been agreed on the vendor evidence.
What is the biggest mistake?
Accepting allocation as the count. It is not technically wrong, it is measuring the wrong thing, and because it looks like a system generated number it rarely gets challenged.
