Cloud Pak, a key to every room and rent on the ones you never enter
Cloud Pak is IBM's containerized software packaging on Red Hat OpenShift, licensed on Virtual Processor Cores: you buy a pool of entitled cores and run any capability in that Cloud Pak up to the count. The flexibility is the product and it is what IBM charges for, which is genuine value when you use the breadth and dead weight when you do not, and across our reviews, buyers consistently held entitlement far broader than the capabilities they ran.
Prepared by Redress Compliance · August 8, 2026 · IBM advisory. Based on 25 to 35 IBM Cloud Pak reviews led 2024 to 2025.
Executive summary
The overhang is the finding: entitled minus consumed is your shelfware. 20 to 40 percent of entitled cores supported capabilities the estate never deployed, the median entitlement sat 32 percent unused, and support was paid on all of it: the three numbers that run the estate are entitled cores.
Consumed cores, and the gap.
A VPC counts a core made available to the Cloud Pak software, so container limits, virtualization, and node placement all change the count, and deployment design directly affects what you license before any negotiation starts.
Sub capacity is mandatory in practice, and ILMT is the entry ticket.
Sub capacity licenses the cores assigned to the Cloud Pak rather than every core in the cluster.
And without it IBM measures full physical capacity, which can multiply the count: the requirement is the License Metric Tool installed and producing compliant quarterly reports, with history retained to prove assigned cores over time. Estates without current ILMT reports risked full capacity true ups of 15 to 30 percent.
The same operational lapse that runs through every IBM sub capacity entitlement.
The PVU conversion is a ratio, and accepting it unchecked lost 10 to 20 percent.
Converting legacy Processor Value Unit licenses into Cloud Pak VPC uses a published ratio that is rarely one to one, and conversions accepted without checking the ratio lost 10 to 20 percent of paid value: the exact figure and the support continuity get confirmed in writing before anything signs.
The seller frame, entitle generously now because the platform vision makes future capability cheap, failed in roughly two thirds of estates, where the future capabilities never deployed and the surplus cores expired as shelfware.
The renewal turns on evidence, and evidence cut 21 percent on average.
IBM negotiates against documentation: the capability map listing what runs at what core count family by family, current ILMT reports restoring the sub capacity position, the overhang identified for removal, and the conversion ratio in writing.
Brought together and co terminated with the wider IBM agreement for volume leverage. The average renewal reduction achieved across our reviews was 21 percent, with written expansion pricing secured for capabilities that might genuinely deploy instead of prepaid entitlement for ones that never do.
The Cloud Pak families, and what to watch in each
| Cloud Pak | Capability focus | Watch for |
|---|---|---|
| Data | Data management, governance, analytics | Unused analytics modules riding the entitlement |
| Integration | API management, messaging, connectivity | Idle integration runtimes holding cores |
| Business Automation | Workflow and content | Surplus automation cores from the platform pitch |
| Watson AIOps | IT operations intelligence | Capability bought ahead of the operational maturity |
| Security | Threat and data security across tools | Overlap with point tools you already own |
The uniform metric is the value and the trap in one mechanism.
Because every capability meters on the same VPC pool, cores shift between capabilities without new purchases, real portability when the breadth is used, and the families overlap at the edges.
So the position starts by confirming exactly which capabilities the entitlement covers and which are actually deployed.
The overlap with point tools cuts both ways: consolidate onto the Cloud Pak and retire the duplicates, or drop the redundant Cloud Pak entitlement, but never pay for both.
The sub capacity discipline, three practices
- Install and run ILMT: compliant quarterly reports are the entry ticket to sub capacity, and no current reports means full capacity at audit.
- Retain the history: the archived reports are what prove assigned cores over time, the evidence standard every audit tests first.
- Reconcile early: ILMT against entitlement before any audit window, because the reconciliation done calmly finds what the audit would find expensively.
- Check the conversion in writing: the PVU to VPC ratio is rarely one to one, and unchecked conversions lost 10 to 20 percent of paid value.
The Cloud Pak licensing negotiation brief
The VPC mechanics, the capability mapping method, the conversion arithmetic, and the renewal sequence worked on a representative estate.
Get the white paper →The renewal, four moves against documentation
IBM negotiates against documentation, so the renewal preparation is a documentation exercise: map the capabilities that actually run at their actual core counts, family by family, because the map is what separates real flexibility from paid shelfware.
Restore the sub capacity position with current ILMT reports so cores count at the assigned number rather than the cluster; cut the overhang by removing entitlement no deployed capability consumes, the 32 percent median that support fees have been compounding on.
And co terminate the Cloud Pak with the wider IBM agreement, where the volume story and the anniversary leverage worked in the Passport Advantage guide apply to the whole position at once.
The conversion history matters too: estates that came to Cloud Pak through the PVU transition carry the ratio arithmetic worked in the PVU to VPC analysis.
And the container platform underneath prices through its own subscription, with OpenShift entitlements deserving the same deployed versus entitled scrutiny.
- 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 Cloud Pak reviews, 2024 to 2025
Across roughly 25 to 35 IBM Cloud Pak reviews Fredrik Filipsson led between 2024 and 2025, buyers consistently held entitlement far broader than the capabilities they ran:
Estates where the generously entitled future capabilities never deployed and the cores expired as shelfware.
Achieved on average with the capability map, current ILMT, and the written ratio in hand.
The seller pitch, that the bundle is a strategic platform and generous entitlement now secures cheap capability later, inverts the actual economics: the buyer side position entitles to deployed capabilities at the evidenced core count.
Secures written expansion pricing for capabilities the roadmap has genuinely funded, and declines to prepay for a vision, because expansion pricing costs nothing to hold and shelfware costs support fees every year it sits.
On a Cloud Pak you are buying a key to every room and then paying rent on the rooms you never enter, and the capability map is simply the walk through the building that lists which doors have ever opened.
Your first five moves
- Map every deployed capability to its consumed core count, family by family, the document IBM negotiates against.
- Confirm ILMT is current and the report archive complete, against the 15 to 30 percent full capacity true up.
- Quantify the overhang and cut it at renewal, the 32 percent median entitlement no capability consumes.
- Verify any PVU conversion ratio in writing, where unchecked acceptance lost 10 to 20 percent.
- Trade prepaid breadth for written expansion pricing, and co terminate with the wider agreement. The IBM practice runs the renewal with you.
Frequently asked questions
How does IBM Cloud Pak licensing work?
On Virtual Processor Cores: you buy a pool of entitled cores for a Cloud Pak, Data, Integration, Business Automation, Watson AIOps, or Security, and run any capability in that Pak up to the entitled count, on Red Hat OpenShift.
The uniform metric lets cores shift between capabilities without new purchases, which is the flexibility IBM charges for.
What is a Virtual Processor Core?
A core made available to the Cloud Pak software, with container limits, virtualization, and node placement all changing the count, so deployment design directly affects the license position.
The three numbers to track are entitled cores, consumed cores, and the gap between them, which is the shelfware overhang that sat at a 32 percent median across our reviews.
Does Cloud Pak require ILMT?
For sub capacity, effectively yes: licensing only the cores assigned to the Cloud Pak rather than the whole cluster requires the License Metric Tool installed and producing compliant quarterly reports, with history retained.
Without current reports the default is full physical capacity, and estates missing them risked true ups of 15 to 30 percent.
How does the PVU to VPC conversion work?
Through a published ratio that is rarely one to one: legacy Processor Value Unit entitlements convert to Cloud Pak VPC at a figure that varies by product, and conversions accepted without checking lost 10 to 20 percent of paid value.
Confirm the exact ratio and support continuity in writing before agreeing to any conversion.
Should you buy broad Cloud Pak entitlement for future flexibility?
Usually not: in roughly two thirds of estates we benchmarked, the future capabilities never deployed and the surplus cores expired as shelfware with support paid throughout.
Entitle to deployed capabilities at the evidenced core count and secure written expansion pricing for genuinely planned additions, because holding expansion pricing costs nothing and holding shelfware costs support every year.
How do you cut an IBM Cloud Pak renewal?
With documentation: the capability map showing what runs at what core count, current ILMT reports restoring the sub capacity position, the overhang identified for removal, the conversion ratio in writing, and co termination with the wider IBM agreement for volume leverage.
The average reduction achieved across our reviews with that package was 21 percent.
