IBM Cloud Paks Licensing and VPC Metrics

IBM Cloud Paks are licensed in Virtual Processor Cores, and each Cloud Pak entitlement converts the underlying products at a fixed ratio, so one VPC of a Cloud Pak can grant the equivalent of two to four VPCs of an individual component, which makes the conversion ratio, not the headline VPC price, the number that decides whether the bundle saves money. The Cloud Pak model trades simplicity for a conversion table, and reading that table correctly is the difference between a genuine consolidation saving and an expensive repackaging of software you already own.

This guide explains how Cloud Pak licensing and VPC metering work, how the conversion ratios drive value, and where the model traps buyers. It pairs with our IBM licensing complete guide, the IBM PVU licensing analysis that VPC replaced for many products, and the firm's IBM advisory practice.

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 getting it wrong inflates the VPC count the same way it inflates a PVU count.

The conversion ratios are the whole game

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 Cloud Pak edition. The table below illustrates how the ratios work in practice, using representative figures to show the principle, since the exact ratios depend on edition and version.

The model rewards breadth of use. A buyer who deploys several products from a Cloud Pak 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 only uses one product pays a bundle price for a single component and captures none of the ratio benefit, which is the most common way Cloud Pak spending is wasted.

Foundational services and what is included

Every Cloud Pak runs on IBM Cloud Pak foundational services, a shared layer providing identity, logging, monitoring, and licensing functions across the products in the Pak. This layer is included in the Cloud Pak entitlement, so you do not license it separately, but it does consume infrastructure and it does participate in the VPC count for the workloads that depend on it. Understanding what foundational services include prevents both the error of licensing them twice and the error of ignoring their resource footprint.

The included nature of foundational services is one of the genuine simplifications of the Cloud Pak model. Under the older product-by-product approach, the shared services often required separate consideration. Folding them into the Pak entitlement removes that overhead, which is part of why the model can save money for buyers who use the bundle as intended. The point connects to how IBM packages capability in Passport Advantage bundles, where included components also carry specific rights.

Container and OpenShift considerations

Cloud Paks are designed to run on Red Hat OpenShift, and the OpenShift entitlement is often included with the Cloud Pak for the cores running Cloud Pak workloads. This inclusion is valuable, but it is bounded: the included OpenShift rights apply to the Cloud Pak workloads, not to general OpenShift use across your estate. Running other workloads on the same OpenShift cluster can require separate OpenShift entitlement, and the boundary between included and separate use is exactly where deployments drift past their rights.

The discipline is to track which OpenShift cores carry Cloud Pak workloads under the included entitlement and which carry other workloads that need their own license. This mirrors the restricted-use principle throughout the IBM catalog, where included capability is granted for a defined role rather than for general use, a theme in our IBM Cloud Paks overview and the broader IBM licensing model.

Optimizing a Cloud Pak position

Three moves keep a Cloud Pak position efficient. First, deploy the breadth of the bundle so the favorable conversion ratios are captured rather than left unused, since an under-deployed Pak is pure waste. Second, maintain accurate VPC tracking so the sub-capacity count holds and you are not assessed on more virtual cores than the workloads use. Third, reconcile the included OpenShift and foundational-services entitlements against actual deployment so you neither double-license what is included nor stray past its boundary.

Done together, these moves turn the Cloud Pak model into the consolidation saving it is designed to be. Neglected, they turn it into a bundle price for fractional use plus drift exposure on the included components. Our advisors model the conversion ratios and the deployment plan together, which is the only way to know whether a Cloud Pak is the right vehicle, a calculation we run as part of licensing advisory engagements.

Cloud Pak editions and what changes between them

Cloud Paks ship in editions that change both the products included and the conversion ratios that apply to them. A higher edition may add components or improve the ratio on the products you use most, while a lower edition covers a narrower set at a lower price. The edition decision is separate from the VPC count, and choosing an edition richer than your deployment needs is a common overspend, the same feature-tier trap that appears across the IBM catalog where the tier and the metric are independent choices.

The discipline is to 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 buyer who buys the top edition for the prestige of its component list, but only deploys two products, pays for breadth they never use, while a buyer who buys a lower edition and then needs a component it excludes faces an upgrade. Modeling the edition against the two-year deployment plan, before committing, lands you on the edition that fits, which our advisors do as part of the same conversion-ratio analysis.

Migrating onto Cloud Paks from standalone licenses

Many buyers come to Cloud Paks already holding standalone licenses for the underlying products, and the migration question is whether to convert. The conversion can save money when you use several of the bundled products and the ratios are favorable, but it can also strand value in existing perpetual licenses if the move is made carelessly. Before converting, account for what you already own, since trading perpetual entitlements for a subscription bundle changes both the cost structure and the ownership position, and the trade is not always in your favor.

The right approach is to model the Cloud Pak position against the fully loaded cost of keeping the standalone licenses, including their maintenance, and to 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 that perpetual ownership provided. This is the kind of trade we model in licensing advisory, where the existing entitlement is treated as an asset to be valued, not discarded.

Governing a Cloud Pak 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 the same. Governing the position means reconciling deployment to entitlement on a regular cadence, confirming the included components are still being used to justify the bundle, and watching the OpenShift boundary so general workloads do not quietly consume Cloud Pak entitlement they are not licensed for.

The payoff of governance is that the Cloud Pak keeps delivering the consolidation saving it was bought for, rather than decaying into a bundle whose breadth is no longer used and whose included entitlements have been breached. The cost of the governance is modest quarterly effort against the size of the entitlement, which is why it is the standing discipline our advisors build around any Cloud Pak position, the same way we govern a sub-capacity estate.

A short worked example of the ratio math

Picture a buyer weighing a Cloud Pak against standalone licenses for three of its products. Under the standalone path, each product is licensed and maintained separately, and the combined cost reflects three full entitlements. Under the Cloud Pak, the buyer licenses a number of Cloud Pak VPCs and converts them into the three products at the published ratios, where the secondary and tertiary products convert at two to four product VPCs per Cloud Pak VPC. If the buyer genuinely deploys all three, the conversion ratios stretch each Cloud Pak VPC across far more product capacity than its price implies, and the bundle wins decisively.

Now change one fact: the buyer deploys only the primary product and shelves the other two. The favorable ratios on the secondary and tertiary products are never realized, so the buyer has paid a bundle price to use a single component at roughly its standalone rate, capturing none of the consolidation benefit. The math turns entirely on breadth of deployment, which is why the deployment plan, not the price sheet, decides whether a Cloud Pak is the right vehicle. Modeling the actual planned deployment against the ratios before committing is the single most valuable step in any Cloud Pak decision.

The bottom line

IBM Cloud Paks are licensed in Virtual Processor Cores, and the conversion ratios that translate Cloud Pak VPCs into the underlying products decide whether the bundle saves money. Deploy the breadth of the Pak to capture the ratios, hold the sub-capacity count with accurate tracking, and reconcile the included OpenShift and foundational services against real use. Buyers who use the full bundle capture a real consolidation saving; buyers who license a Pak for one product overpay. Our advisors model and negotiate Cloud Pak deals across the IBM portfolio.