IBM Cloud Paks licensing: VPC metrics and conversion ratios.
IBM Cloud Paks license in Virtual Processor Cores, and each entitlement converts the underlying products at a fixed ratio — one Cloud Pak VPC can grant two to four VPCs of a component. That conversion ratio, not the headline VPC price, decides whether a bundle is a genuine consolidation saving or an expensive repackaging of software you already own.
A Cloud Pak saves money only when you deploy the breadth of the bundle. Capture the favorable conversion ratios, hold the sub-capacity count with accurate ILMT tracking, and reconcile the included OpenShift and foundational-services entitlements against real use. Buyers who use the full bundle capture a real consolidation saving; buyers who license a Pak for one product overpay and carry audit exposure.
01 Key findings
The conversion ratio is the whole game. One Cloud Pak VPC converts into underlying products at published ratios — roughly 1:1 for a primary product, 1:2 for a secondary, and 1:3–4 for a tertiary. The headline VPC price tells you almost nothing until you map it through the ratio table.
The model rewards breadth of use. A buyer who deploys several products from a Pak captures the favorable ratios and consolidates many licenses into one entitlement. A buyer who uses one product pays a bundle price for a single component and captures none of the ratio benefit.
Sub-capacity discipline still governs VPC. Because VPC counts virtual cores allocated to the workload, an inaccurate ILMT deployment inflates the count exactly the way it inflates a PVU count — and the gap becomes an audit finding.
Included OpenShift is bounded, not general. The OpenShift entitlement bundled with a Cloud Pak covers the cores running Cloud Pak workloads only. Other workloads on the same cluster can require separate OpenShift licenses, and that boundary is exactly where deployments drift past their rights.
Edition and metric are independent choices. A richer edition adds components or improves ratios; a lower edition covers a narrower set for less. Buying an edition richer than your deployment needs is a common overspend.
02 What a Virtual Processor Core is
A Virtual Processor Core is IBM's modern metric for container-based and hybrid-cloud software, counting the virtual cores available to the licensed workload. It replaced the older Processor Value Unit basis for the Cloud Pak family, simplifying the count from a weighted PVU figure to a straight virtual-core figure. The simplification is genuine, but it shifts the complexity into the conversion ratios that translate Cloud Pak entitlements into the component products underneath.
Because VPC counts virtual cores, the same sub-capacity discipline that governs PVU products governs VPC products: you license the cores allocated to the workload, and you need accurate tracking to hold that position. The relationship between virtual and physical capacity is the same one covered in our full versus sub-capacity guide, and it is the metric that IBM PVU licensing gave way to for the Cloud Pak family. This note pairs with our IBM licensing complete guide and the firm's IBM advisory practice.
03 The conversion ratios
Each Cloud Pak bundles a set of products, and one Cloud Pak VPC converts into the underlying products at published ratios that vary by product and by edition. The table uses representative figures to show the principle; the exact ratios depend on edition and version.
| Cloud Pak component | Example conversion | Effect |
|---|---|---|
| Foundational services | Included with the Pak | No separate license needed |
| Primary product (e.g. integration) | 1 Cloud Pak VPC = ~1 product VPC | Direct mapping |
| Secondary product (analytics) | 1 Cloud Pak VPC = ~2 product VPCs | Favorable if used |
| Tertiary product (automation) | 1 Cloud Pak VPC = ~3–4 product VPCs | Strong value if deployed |
| Unused entitled product | Granted but not deployed | Value left on the table |
The model rewards breadth of use. A buyer who deploys several products captures the favorable conversion ratios and consolidates many licenses into one entitlement at a lower effective cost. A buyer who licenses a Cloud Pak but uses one product pays a bundle price for a single component — the most common way Cloud Pak spending is wasted.
04 Bundle economics
The value of a Cloud Pak scales with how many bundled products you actually deploy. Effective product-VPC coverage delivered per single Cloud Pak VPC, by deployment breadth:
Cloud Paks only save money when you use the breadth of the bundle. Before buying one, map which underlying products you will actually deploy over the next two years and calculate the effective per-product cost at the published ratios. If you will use only one or two components, an individual product license is almost always cheaper than the Pak. Where you do use the breadth, push for a higher conversion ratio on the components you deploy most.
05 Sub-capacity and the ILMT audit trap
VPC is a sub-capacity metric: you are entitled to license only the virtual cores allocated to the workload, but the right to do so is conditional on accurate reporting. For Cloud Paks that means IBM License Metric Tool (ILMT) or an equivalent must be deployed, configured, and producing quarterly reports. Miss the reporting requirement and IBM can assess you at full capacity — every physical core in the cluster, not just the virtual cores you use.
The included OpenShift boundary is where drift becomes a finding. The OpenShift entitlement bundled with a Cloud Pak applies to the cores running Cloud Pak workloads, not to general OpenShift use across your estate. Running other workloads on the same cluster can require separate entitlement. Track which cores carry Cloud Pak workloads under the included rights and which carry other workloads that need their own license — the same restricted-use principle that runs through IBM Passport Advantage bundles.
06 Cost-control framework
Four factors keep a Cloud Pak position efficient. Weight them against your deployment reality before and after purchase.
Deployment breadth
Deploy the products the bundle grants so the favorable conversion ratios are captured rather than left unused. An under-deployed Pak is pure waste at a bundle price.
Sub-capacity tracking
Maintain accurate ILMT reporting so the VPC count holds and you are assessed on the virtual cores the workloads use, not on full physical capacity.
Included-entitlement reconciliation
Reconcile the included OpenShift and foundational-services rights against actual deployment, so you neither double-license what is bundled nor stray past its defined-role boundary.
Edition fit
Match the edition to the specific products you will deploy and the ratios that benefit them, then size the VPC count to the workloads. A richer edition than you use is overspend.
07 Recommendations
Do this when you will genuinely deploy several bundled products over two years. Model the effective per-product cost at the published ratios and push for a higher conversion on your heaviest components.
Do this when only one or two components will be deployed. An individual product license is almost always cheaper than a bundle used at a fraction, and perpetual entitlements you already own keep their value.
Do this every quarter regardless of vehicle. Reconcile deployment to entitlement, confirm ILMT reporting is clean, and watch the OpenShift boundary so general workloads do not consume Cloud Pak rights.
08 Governing the position over time
A Cloud Pak is not a set-and-forget purchase. The VPC count drifts as workloads scale, the included OpenShift boundary blurs as other workloads land on the same clusters, and the breadth of products actually used can shrink over a term while the entitlement stays fixed. Governing the position means reconciling deployment to entitlement on a regular cadence, confirming the included components are still used to justify the bundle, and watching the OpenShift boundary so general workloads do not quietly consume entitlement they are not licensed for.
Where buyers arrive already holding standalone perpetual licenses, model the Cloud Pak against the fully loaded cost of keeping them, maintenance included, and convert only where the bundle genuinely wins on breadth and ratio. A conversion driven by a sales incentive rather than a deployment reality can raise cost while reducing the flexibility perpetual ownership provided. Our advisors model the conversion ratios and the deployment plan together as part of licensing advisory engagements across the IBM portfolio.
Make the Cloud Pak math work
We model the conversion ratios against your deployment and defend the sub-capacity position under audit. Buyer-side only.
The Licensing Edge
Weekly vendor and licensing intelligence for enterprise IT leaders. 3,000+ subscribers.