IBM Cloud Pak licensing in 2026. How VPCs, bundle ratios and unused cores add up.

A Cloud Pak is a pool of Virtual Processor Cores you can spend on any bundled program. That flexibility has value only if you use it, and most buyers we review hold far more entitlement than they run.

How does IBM Cloud Pak licensing work?

You buy a pool of Virtual Processor Cores (VPCs) for one Cloud Pak and can run any program bundled in that Pak until the pool is used up. Cloud Paks are IBM's containerized software bundles, built to run on Red Hat OpenShift. IBM charges for that flexibility, so it pays off only when you run several of the bundled programs.

Each bundled program is counted in its own VPCs, then converted into Cloud Pak VPCs at a ratio IBM publishes for that program. You add the converted figures together, and that total must stay inside your entitlement. IBM licenses the combined peak of the Pak, so you can shift cores from one program to another without buying more.

What a Virtual Processor Core counts

A VPC is a core made available to the Cloud Pak software. That means your deployment design sets the count before any negotiation starts. Three settings move it:

• Container limits. In Kubernetes, a pod counts at the sum of its containers' CPU limits. A pod with any container that has no CPU limit counts at the full capacity of its worker node.
• Virtualization. On virtual machines, the count is the virtual cores assigned to the VM, provided sub capacity rules are met.
• Node placement. On each worker node, a program never counts above that node's capacity, so right sized, dedicated nodes cap the count in a way large shared nodes do not.

Which Cloud Pak families exist, and what should you watch in each?

The five main families are below. They overlap at the edges, so the first job is to confirm exactly which capabilities your entitlement covers and which you actually deploy.

Where a Security or Data Pak overlaps with a point tool you already pay for, pick one. Either consolidate onto the Cloud Pak and retire the duplicate, or drop the redundant Cloud Pak entitlement. Our guides to Cloud Pak for Data licensing and Cloud Pak for AIOps licensing cover those Paks in detail.

Is Red Hat OpenShift included in a Cloud Pak?

Most Cloud Paks include a restricted OpenShift entitlement, which may only run that Cloud Pak and its bundled programs. Cloud Pak for Integration, for example, carries 3 OpenShift cores for each Cloud Pak VPC, restricted to that Pak. The ratio differs by Pak, so check the license information document for each one you own.

Anything else on those worker nodes, such as your own applications or a second Cloud Pak, needs unrestricted OpenShift cores bought as a separate Red Hat subscription. IBM treats other workloads on restricted cores as unsupported, so expect an auditor to ask for separate OpenShift entitlement. Review those subscriptions for deployed versus entitled use too.

How much Cloud Pak entitlement goes unused?

More than most buyers expect, and IBM charges support on every unused core. Track three numbers for every Pak: entitled VPCs, consumed VPCs and the gap between them. The gap is shelfware, and it renews at full support cost until someone removes it.

A worked example of the overhang

Say you own 80 VPCs of Cloud Pak for Integration. Your License Service report shows the peak use below. The ratios are the ones IBM publishes for Cloud Pak for Integration, written as program VPCs to Cloud Pak VPCs.

The overhang is 24 VPCs, or 30 percent of the entitlement. If your annual support ran at $1,200 per VPC, a round figure used only for illustration, that gap would cost $28,800 a year for capacity no program uses.

The ratios also show why the program mix matters. Four more VPCs of App Connect Enterprise would consume 12 Cloud Pak VPCs, while the same 12 would cover 24 VPCs of MQ Advanced. Before you buy more cores for a new project, check which program it will run on.

Why the shared pool works for you and against you

Because every program meters against the same VPC pool, cores shift between programs without a new purchase. That is real portability when you use the breadth. The same pool also hides waste: the invoice shows a single Cloud Pak line with no split by program, so unused VPCs stay invisible until someone compares a License Service report with the entitlement.

Do you need ILMT or License Service for Cloud Pak sub capacity?

Yes, and which tool depends on how you deploy. Sub capacity licensing, which charges only for the cores assigned to the Cloud Pak, requires IBM's approved metering. For containers IBM License Service is mandatory with no exceptions, and it ships with every Cloud Pak. Programs deployed on virtual machines rely on the IBM License Metric Tool (ILMT).

IBM requires ILMT within 90 days of your first sub capacity deployment. Without current reports from either tool, IBM measures full capacity. For containers that means every vCPU on every worker node in the cluster, which can multiply the count several times over.

Which reporting habits keep you on sub capacity?

• Install and run the tools. Compliant quarterly reports are the price of entry to sub capacity.
• Retain the history. IBM's container terms require a License Service audit report every quarter, archived for two years. Those archives prove assigned cores over time, and they are the first evidence an IBM auditor asks for.
• Reconcile early. Compare the reports with your entitlement well before any audit window. Gaps you find yourself can be fixed before an auditor prices them.
• Declare non production correctly. Each Cloud Pak for Integration program in the example below has a cheaper non production ratio (App Connect Enterprise 2 : 3, API Connect 2 : 1), which applies only when the instance is deployed with the non production license setting.

The ILMT sub capacity guide covers the virtual machine side in detail, including the lapses that end sub capacity eligibility on any IBM product.

How to check your own position

1. License Service audit snapshot. Pull it from every OpenShift cluster for the last full quarter. IBM License Service Reporter combines several clusters into one view.
2. Pods without CPU limits. List every pod running Cloud Pak software, using the OpenShift console or the oc command line, and flag any container with no CPU limit.
3. ILMT audit snapshot. Run it for any Cloud Pak program deployed on virtual machines and check that the VMs map to the right hosts.
4. Entitlement records. Download your Cloud Pak entitlements from Passport Advantage and place them next to both snapshots, program by program.
5. OpenShift cores. Count the unrestricted OpenShift subscriptions and confirm which nodes they cover.

How does the PVU to VPC conversion affect a Cloud Pak deal?

Legacy Processor Value Unit (PVU) licenses convert into Cloud Pak VPCs at a ratio IBM sets per product, rarely one to one. Conversions accepted without checking the ratio lost 10 to 20 percent of paid value in the deals we reviewed. Confirm the exact ratio and how support continues, both in writing, before anything is signed.

Many Cloud Pak buyers arrive through this route. IBM offers to trade existing WebSphere, MQ or DB2 entitlements into a Pak, and each product converts on its own terms. Our PVU to VPC analysis works through the arithmetic product by product.

Questions to ask IBM before converting

• What ratio applies to each PVU line, and is it based on licensed cores or on PVUs owned?
• Does the support anniversary carry over, or does the converted entitlement start a new support term at a new price?
• Which bundled programs, at which ratios, will the converted VPCs cover?
• Can the converted lines be reduced at renewal without repricing what remains?
• Will the ratio be written into the order for the full term?

What have we seen in Cloud Pak reviews in 2024 and 2025?

Across roughly 25 to 35 IBM Cloud Pak reviews I led between 2024 and 2025, buyers consistently held far more entitlement than the capabilities they ran. The same patterns showed up whether the Pak was Data, Integration or Business Automation.

• Undeployed capability. 20 to 40 percent of entitled cores supported capabilities the customer never deployed, with support paid on all of it.
• The median gap. The median entitlement sat 32 percent unused.
• Stale reports. Where ILMT reports were missing or out of date, the customer faced full capacity true ups of 15 to 30 percent.
• The platform pitch. In roughly two thirds of accounts, capabilities bought generously for the future never deployed, and the surplus cores expired as shelfware.
• The result of preparation. Renewals that arrived with a capability map, current reports and the conversion ratio in writing cut cost by 21 percent on average.

Why we advise against buying Cloud Pak breadth for future use

IBM's sales case is that a Cloud Pak is a strategic platform, so generous entitlement now makes future capability cheap. We disagree, because in most of the accounts above that future never arrived and the customer paid support on idle cores for years.

License the programs you deploy at the core count your reports support, and get written expansion pricing for anything your roadmap has funded. Holding that price costs nothing, while 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. The capability map is the walk through the building that shows which doors have ever opened.

How do you prepare an IBM Cloud Pak renewal?

Build it on documentation, because IBM negotiates against evidence. The package that produced the reductions above has four parts:

1. A capability map. Every deployed program at its actual core count, family by family. It separates real flexibility from paid shelfware.
2. Current reports. License Service and ILMT reports that restore the sub capacity position, so cores count at the assigned number instead of the whole cluster.
3. The overhang, sized for removal. The entitlement no deployed program consumes, which support fees have been compounding on.
4. The conversion ratio in writing. For any Pak that came from PVU licenses.

Then co terminate the Cloud Pak with your wider IBM agreement, so the volume case and the anniversary timing apply to the whole relationship at once. The Passport Advantage guide explains how those terms work across IBM products.

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

Contract wording to ask for

• Written expansion pricing. A per VPC price for each named Cloud Pak for the full term, so you buy capacity when it deploys instead of prepaying for it.
• A reduction right. The right to cut VPCs at renewal without repricing the rest. Our note on termination and reduction rights has example terms.
• Swap rights across Paks. The right to move entitlement between Cloud Paks as needs change, covered in the swap and substitution clause guide.
• A support uplift cap. A ceiling on the annual increase for retained VPCs. See the uplift cap clause language.
• Conversion terms in the order. The PVU to VPC ratio and support continuity, stated per product.
• A common end date. Co termination with the rest of your IBM agreement.

When to start

What to do next

1. Map every deployed capability. Record each program's consumed core count, family by family. This is the document IBM negotiates against.
2. Confirm the reports are current. Check License Service and ILMT are running and the archive is complete, which removes the full capacity true up risk.
3. Size the overhang and cut it at renewal. Remove entitlement no program consumes.
4. Verify any PVU conversion ratio in writing. Include how support carries over.
5. Trade prepaid breadth for expansion pricing. Get it in writing and co terminate with the wider agreement.
6. Bring in help if the renewal is close. Our IBM practice runs Cloud Pak renewals with you.

Frequently asked questions