IBM Cloud Pak strategy guide. How VPC, swap rights and OpenShift set the bill.

An IBM Cloud Pak bill is set by the container CPU limits, the component ratios and the restricted OpenShift entitlement. Count those three from your own License Service data before IBM quotes the renewal.

IBM Cloud Paks package IBM middleware and data products into six offerings, each running on Red Hat OpenShift and each priced in Virtual Processor Cores (VPC). Inside one Pak, the VPC you buy can be spent on any of its products. That flexibility is the main reason to buy a Pak. Most overspend comes from how the VPC is counted.

Read this guide alongside the IBM knowledge hub, our IBM advisory practice, the IBM audit defense kit and the Vendor Shield subscription.

What have we seen in recent IBM Cloud Pak renewals?

The VPC count in the contract rarely matches what the containers run. Across roughly 30 to 45 Cloud Pak renewals we benchmarked in 2024 and 2025, three patterns kept coming back.

Each of these patterns traces back to the count, so the renewal section below starts there. The product rules below come from IBM's Cloud Paks product page, the Passport Advantage sub capacity terms and IBM's container licensing guide.

Which of the six IBM Cloud Paks fits your workload?

Choose the Pak from the workload you already run. Each Pak carries its own set of IBM products, and the VPC you buy can only be spent on those products.

How to pick the Pak

Start with the Pak that holds the highest VPC consumption today. Integration suits companies with heavy ESB, MQ and API gateway use, and Data suits companies whose IBM spend sits in Db2, DataStage and Cognos. The Pak you choose sets which products your swap rights can reach.

Check product names before you sign. IBM renamed Watson AIOps to Cloud Pak for AIOps and sold the QRadar SaaS business to Palo Alto Networks in 2024, so older quotes may not match the current price list. See our pages on Cloud Pak for Data licensing and Cloud Pak for AIOps licensing.

How does IBM Cloud Pak VPC licensing work?

One VPC equals one virtual core, measured at the CPU limit of the running container. The size of the host or worker node does not matter as long as the container has a limit set. IBM License Service is the only tool IBM accepts for the measurement.

Five VPC counting rules

• The container CPU limit drives the count. A container with a 4 core limit counts as 4 VPC, whatever it actually uses. A container with no limit counts the full capacity of its worker node.
• Burst inside the limit is not counted. Kubernetes throttles a container at its limit, so there is no burst charge. Extra pods from horizontal scaling do count, because License Service polls at least every 30 minutes and keeps the daily peak.
• Non production carries a half rate. Most products run at 0.5 VPC per virtual core in non production.
• Cold and idle warm standby carry no VPC. A hot standby that runs and synchronizes data alongside the primary must be fully licensed under IBM's backup rules.
• OpenShift control plane and infrastructure nodes are excluded. Only worker nodes running IBM containers carry VPC.

Why the component ratio matters as much as the core count

Cloud Pak VPC does not convert to product cores one for one. In Cloud Pak for Integration, a production core of App Connect Enterprise consumes 3 Cloud Pak VPC, a core of API Connect or DataPower consumes 1, and 2 cores of MQ Advanced consume 1. Non production halves each rate.

Worked example: the same containers in three products

Say you run an integration platform with 100 containers at 4 cores each in production, plus a non production replica at the same scale. Under IBM's published ratios, the Cloud Pak for Integration VPC depends heavily on which product runs in those containers.

API Connect is the simple case, with 400 VPC in production plus 200 VPC for the replica giving 600 VPC. Run App Connect Enterprise in the same containers and the bill triples.

Hyperthreading changes every row. IBM divides the container's vCPU limit by the threads per core, so if those limits are 4 vCPUs on hyperthreaded x86 nodes, the 400 production vCPUs count as 200 cores. License Service applies that divisor only when you configure it.

How do swap rights work inside an IBM Cloud Pak?

VPC bought for a Pak can be redeployed between any of that Pak's products without a new purchase. It cannot cross into a different Pak. This is the main commercial value of the Cloud Pak model, and it only pays off if you actually redeploy.

1. Inside Cloud Pak for Integration. Move VPC from MQ to App Connect with no new license fee.
2. Inside Cloud Pak for Data. Move VPC from DataStage to Watson Studio with no new license fee.
3. Across Paks. Moving Integration VPC into Cloud Pak for Data needs a new VPC purchase or a renewal negotiation.

Swaps still follow the component ratios

Retire 60 production cores of MQ Advanced and you free 30 Cloud Pak VPC. At 3 VPC per core, that covers only 10 cores of App Connect Enterprise. Plan every swap in Cloud Pak VPC, and see our note on the Cloud Pak swap and substitution clause for the contract side.

Is Red Hat OpenShift included in an IBM Cloud Pak?

Yes, as a restricted entitlement. Every Cloud Pak runs on Red Hat OpenShift, and the Pak covers OpenShift on the worker nodes that run its own workloads. In Cloud Pak for Integration, IBM grants 3 cores of restricted OpenShift Container Platform for each Cloud Pak VPC.

• Cloud Pak workloads. OpenShift is included on their worker nodes. No separate purchase.
• Other workloads. Anything outside the Pak needs its own Red Hat entitlement, even on the same cluster.
• Public cloud. OpenShift on AWS, Azure and IBM Cloud follows the same rule.

What the bundled OpenShift is worth

Priced as standalone Red Hat subscriptions, the bundled OpenShift typically equals 15 to 25 percent of the Cloud Pak list value. Teams that compare the Pak only against IBM's standalone product prices miss that value.

Split the worker nodes running Cloud Pak workloads from the rest of your OpenShift clusters, price each side against standalone Red Hat, and negotiate the gap where you run OpenShift beyond the Pak. Our guide to how the Red Hat acquisition changed IBM licensing covers the Red Hat side.

Where can IBM Cloud Paks run, and which deployment pattern costs least?

Cloud Paks run on premises, on AWS through ROSA, on Azure through ARO, on IBM Cloud, and on Google Cloud through a partner. After swap rights, the deployment pattern is the second largest driver of Cloud Pak value, so decide it before you buy the entitlement.

1. On premises only. Traditional data center deployment. Lowest run cost on stable workloads.
2. On premises plus cloud. A hybrid pattern that shifts workloads at runtime.
3. Cloud first. ROSA or ARO for the primary workload.
4. Multi cloud. Two or more hyperscalers, with the Cloud Pak entitlement spanning all of them.

ROSA and ARO charge for the OpenShift layer inside the managed service fee. Ask IBM in writing whether your restricted OpenShift entitlement offsets that fee, or whether you pay for OpenShift twice. Our guide to IBM cloud migration licensing covers the wider rules.

How do you check your own Cloud Pak VPC count?

Use IBM License Service, the tool IBM itself relies on in an audit. IBM requires it within 90 days of first using an eligible container product, with audit reports generated quarterly and archived for up to two years.

• The /products report. VPC consumed per Cloud Pak.
• The /bundled_products report. VPC consumed by each component inside a Pak, such as MQ or App Connect.
• The /snapshot archive. The audit snapshot IBM asks for. Pull one before any audit letter arrives.
• License Service Reporter. Aggregates usage once you run more than one cluster.
• Your own pod listing. List every IBM pod with its CPU limit using kubectl or oc, and flag containers with no limit.

Common counting mistakes

• Containers with no CPU limit. Each counts the whole worker node. On a 32 core node, one unlimited container costs as much as eight containers at 4 cores.
• Non production counted at production ratios. Label namespaces and deployments so the half rate applies.
• Other workloads on the Pak's OpenShift entitlement. This opens a Red Hat compliance gap that tends to surface in the same review.

For the audit side, see our guide to the IBM software license audit process.

How do you cut an IBM Cloud Pak bill at renewal?

Rebuild the VPC count from the container limits and cut the entitlement to match. The first three year Cloud Pak ELA usually leaves the over licensing described above, and the renewal is where you reset it.

• VPC consolidation. Right size the VPC count against actual container CPU limits and component ratios.
• Pak rationalization. Drop the Pak with the lowest VPC consumption.
• OpenShift scoring. Price the bundled OpenShift entitlement against your real OpenShift footprint.
• Hybrid deployment plan. A workload that could leave IBM middleware during a cloud migration gives the account team a reason to price sharply.
• Competitive pressure. Bring Confluent, Snowflake, MuleSoft or Splunk quotes into the renewal cycle.

Typical renewal savings

Independent advisory work on a Cloud Pak renewal typically saves 18 to 30 percent, mostly from VPC consolidation and Pak rationalization. Scoring the OpenShift bundle adds a further 3 to 6 percent for most buyers.

Why we push back when IBM says to put everything in one Pak

The usual IBM pitch is that the Cloud Pak bundle costs less than the same middleware bought standalone, so you should consolidate everything into a Pak. We disagree. In roughly 2 of 3 Cloud Pak deals we benchmarked, IBM priced the bundle against list instead of the VPC the containers consumed.

Once we counted at the runtime limit, the headline saving shrank. Count VPC at the container CPU limit first, then price the OpenShift footprint separately against standalone Red Hat and negotiate the gap.

Count VPC at the container limit, apply the component ratio, and only then compare the bundle price.

What will the IBM account team say, and how should you answer?

Expect a handful of familiar lines in a Cloud Pak renewal. Each has a factual reply.

• "The Pak is cheaper than buying the products separately." Ask for the comparison at your measured VPC by component, using the published ratios.
• "Your containers have no limits, so you owe for the full nodes." Set the limits, show the new License Service reports, and agree the corrected count from the quarter the change took effect.
• "Sign the renewal with added capacity and we will close the compliance finding." Settle the compliance number first. Decide on added capacity separately, against your forecast.
• "OpenShift is included, so there is nothing to price." The entitlement is restricted to the Pak. Show how many cores run other workloads and ask IBM to price that Red Hat subscription in the same deal.

Our Cloud Pak negotiation guide covers timing and escalation.

What contract terms should you ask for in a Cloud Pak deal?

Ask for the terms that protect the count, the swap and the price for the full term, and get each into the order documents.

1. The ratio table attached to the order. Your entitlement keeps its value if IBM changes its documentation mid term.
2. Swap rights covering new components. Products IBM adds to the Pak should fall inside your pool.
3. The OpenShift entitlement in numbers. Restricted cores per VPC, and the platforms it applies to, including ROSA, ARO and IBM Cloud.
4. A price hold on added VPC. The original discount applies to extra VPC bought during the term. See our note on price hold clauses.
5. A reduction right at renewal. Cut VPC or drop a Pak without repricing the lines you keep.
6. Measurement and DR in writing. License Service quarterly reports as the agreed basis, and your warm standby design confirmed as unlicensed.

When should you start preparing for a Cloud Pak renewal?

Start 12 months out. A reliable count needs several quarters of clean License Service data.

How does Redress work on IBM Cloud Paks?

We run Cloud Pak strategy and renewal work through Vendor Shield, the Renewal Program, the Benchmark Program and the Software Spend Assessment. A former IBM commercial executive leads every engagement. See our benchmarking, about us and locations pages, or contact the IBM team.

What to do next

1. Map the workload to a Pak. Pick the Pak that holds your largest VPC consumption.
2. Count VPC at the container CPU limit. Apply the component ratios and record the result in your SAM system.
3. Identify the swap pool. Read the component list for your Pak and plan swaps in Cloud Pak VPC.
4. Score the OpenShift footprint. Separate Cloud Pak workloads from the rest of your OpenShift clusters.
5. Pick the deployment pattern. On premises only, hybrid, cloud first or multi cloud, decided before you buy.
6. Run the renewal forecast. Review the VPC count every quarter from License Service reports.
7. Plan the consolidation. Set a VPC target per Pak from the rebuilt count, and price the renewal from that target.
8. Bring in an independent advisor. Have the renewal scored by someone IBM does not pay.

Frequently asked questions