IBM Cloud Paks package multiple IBM middleware and open-source components into containerised bundles designed to run on Red Hat OpenShift. Instead of licensing each product separately, IBM uses a unified Virtual Processor Core (VPC) metric. But VPC licensing inherits many of the same challenges as traditional models. This guide covers VPC fundamentals, container tracking challenges, IBM Licence Service, conversion ratios, deployment optimisation, audit pitfalls, and long-term cost governance.
Cloud Paks shift the discussion to an aggregate core usage model, but CIOs should understand that modernising the IBM contract does not mean simplifying licence governance. All traditional diligence requirements for IBM licences, monitoring deployed cores, complying with terms, archiving reports, still apply under VPC licensing. The key is proactive management: deploy the right tools, understand conversion ratios, optimise deployments, and govern costs continuously.
Under the VPC model, the number of virtual CPU cores allocated to IBM software (in VMs or containers) determines the licence requirement. One VPC equals one virtual core available to an IBM programme, standardised as 70 PVUs in legacy metrics. Each Cloud Pak you purchase entitles you to deploy a suite of IBM products up to your total VPC count. IBM introduced VPC to simplify licensing across technologies. It avoids hardware-specific PVU counting since a VPC is a flat unit regardless of processor type.
| VPC Licensing Concept | What It Means | ITAM Impact |
|---|---|---|
| VPC metric | 1 VPC = 1 virtual core = 70 PVUs. The number of virtual CPU cores allocated to IBM software determines the licence requirement. | Architects must size deployments with licensing in mind from the start. Every virtual core allocated to an IBM programme counts. |
| Bundled entitlements | Most Cloud Paks include a limited number of Red Hat OpenShift cores, commonly a 1:3 ratio (one VPC of Cloud Pak includes three VPCs of OpenShift capacity). | Those OpenShift entitlements are "restricted" for use only by Cloud Pak workloads, not for unrelated applications. Mixing workloads creates compliance exposure. |
| Aggregate core usage model | Cloud Paks shift licensing from per-product to a pooled VPC entitlement. Multiple IBM products draw from the same VPC pool. | Each component product has a conversion ratio dictating how its usage consumes your VPC entitlement. Some products consume disproportionately more than others. |
| Cost drivers | Total VPCs consumed drives subscription cost. Over-provisioning cores means paying for excess VPCs. Under-licensing leads to compliance violations. | Licence Cloud Paks for needed capacity with growth margin. Avoid grossly over-purchasing "just in case" but never deploy first and buy later. |
Use included OpenShift components for Cloud Pak workloads to avoid redundant spending. But ensure no non-Cloud Pak workloads use restricted entitlements without proper licensing. Inventory your IBM software landscape and evaluate the cost of a Cloud Pak licence versus separate product licences to confirm the bundle delivers value for your specific use case.
Containers can be created and terminated on demand, with orchestration platforms auto-scaling pods across clusters. This makes it difficult to manually tally the number of cores in use at any given time. Usage can spike quickly and migrate across hosts. Without proper tooling, organisations risk either undercounting (non-compliance) or overcounting (unnecessary costs).
| Challenge | What Happens | How to Address It |
|---|---|---|
| Ephemeral and elastic workloads | Containers are created and destroyed on demand. Orchestration platforms auto-scale pods across clusters. Usage spikes quickly and migrates across hosts. | Deploy licence tracking tools from day one. Use IBM's tools or third-party SAM tools that support container monitoring from the first Cloud Pak deployment. Retroactive reconstruction is far harder. |
| Full-capacity vs sub-capacity dilemma | Full-capacity licensing requires licensing all CPU cores on all cluster nodes regardless of usage, which is straightforward but usually inefficient. Sub-capacity licensing is based on actual container core usage but requires robust tracking. | For most scenarios, configure your environment for IBM's container sub-capacity licensing with proper monitoring. More tracking effort but significant cost savings compared to full cluster licensing. |
| Complex consumption rules | Each IBM product container has specific annotations or labels to enable tracking. Multiple products with different conversion ratios make tracking "who is consuming how much" complex across potentially dozens of containers and multiple clusters. | Educate DevOps and platform teams that spinning up an IBM container has licensing implications. They should notify licence managers of new deployments and label workloads accurately. |
| No native Kubernetes tools | Kubernetes itself does not account for software licensing. Without an external tool, you have no visibility into questions like "how many VPCs did WebSphere consume this month in our cluster?" | Never rely on manual reporting or cluster admin guesses. Deploy IBM Licence Service or equivalent third-party SAM tool as mandatory infrastructure alongside every Cloud Pak cluster. |
| Misconception of simplicity | Many organisations initially think Cloud Paks will simplify licensing, but in practice the complexity persists. Cloud Paks carry the same well-known issues of full-capacity licensing as PVU products. | Simulate and plan for peak usage. Work with architects to forecast peak container counts. Licensing is typically based on peak concurrent VPCs in a given period. Design workloads to stagger or limit concurrent use. |
IBM Licence Service (ILS) continuously measures vCPU consumption of IBM containerised products on each cluster. It aggregates usage per product and Cloud Pak, providing a dashboard and reports showing your highest VPC usage over time. It is the container-age equivalent of ILMT (Licence Metric Tool), purpose-built for Kubernetes, designed to report sub-capacity usage so you licence only what you use.
| ILS Requirement | Detail | Compliance Impact |
|---|---|---|
| Mandatory for sub-capacity | IBM's terms require deploying the Licence Service to utilise sub-capacity licensing. IBM Licence Service must be implemented within 90 days of first use of an eligible product. | If not deployed, IBM reserves the right to demand full-capacity licensing of the entire cluster. This is potentially a massive cost impact. Treat ILS as non-optional infrastructure. |
| How it works | Installed as a container in your cluster (often as part of Cloud Pak foundational services). Discovers IBM product containers through labels or known signatures and measures their CPU limits usage. | Produces licence usage reports showing peak VPC usage per IBM product per reporting period. The optional Licence Service Reporter aggregates data from multiple clusters into a consolidated enterprise-wide report. |
| Reporting obligations | IBM expects customers to generate and archive quarterly reports from the Licence Service. During an audit, you should be prepared to produce up to two years of these reports. | Automate report generation and archival. Institute a process to pull Licence Service usage reports at least quarterly and store records securely. |
| CPU limits critical | The Licence Service measures vCPU limits assigned to containers, rounded up to the nearest whole core. Containers without defined limits are assumed to use an entire node's capacity. | Setting realistic CPU limits is critical. Always set explicit CPU limits on IBM containers. If a WebSphere container only requires 0.5 cores, set that limit. |
| Data validation | Periodically cross-check Licence Service output against cluster metrics. If it shows 10 VPCs for a product but cluster admins believe only 5 are in use, there may be a mislabelled container or configuration issue. | Have your SAM/ITAM team review usage reports on an ongoing basis. Look for trends: components nearing entitlement limits, spikes from new deployments. |
Without ILS, you must assume every core in the cluster was used and licence accordingly, defeating the purpose of efficient licensing. Deploy ILS within 90 days of first use and generate quarterly reports. This is the container-age equivalent of running ILMT in traditional IBM environments. The same strict deployment and reporting requirements apply. See IBM ILMT Guide for the traditional equivalent.
When moving from traditional IBM licences (often PVU-based) to Cloud Paks (VPC-based), IBM defines specific conversion factors in each Cloud Pak's licence terms. These indicate how many Cloud Pak VPCs are consumed by a given amount of a component product. Getting these ratios wrong is one of the most common compliance failures in Cloud Pak environments.
| Cloud Pak Bundle | Component Product | Ratio (Product : Cloud Pak) | Interpretation |
|---|---|---|---|
| CP for Integration | App Connect Enterprise (ACE) | 1:3 | 1 VPC of ACE consumes 3 VPCs of CP4I entitlement. Intensive ACE workloads consume entitlement three times faster than expected. |
| CP for Integration | MQ Advanced | 2:1 | 2 VPCs of MQ count as 1 VPC of CP4I entitlement. MQ is one of the more efficient components within the bundle. |
| CP for Applications | WebSphere Liberty Core | 8:1 | 8 VPCs of Liberty use 1 VPC of CP4A entitlement. Very efficient ratio making Liberty workloads cost-effective under Cloud Paks. |
| CP for Business Automation | Content Collector for SAP | 1:3 | 1 VPC of this component uses 3 VPCs of CP4BA entitlement. Resource-intensive component that demands careful capacity planning. |
Ratios above are examples from IBM documentation. If a ratio is not explicitly stated, assume a default ratio of 1:1. Always confirm in the specific Cloud Pak's Licence Information document.
| Migration Step | What to Do | Why It Matters |
|---|---|---|
| 1. Inventory current licences | List IBM software with current metrics (PVUs, RVUs, etc.). Document every product, metric, and entitlement quantity. | Cannot calculate Cloud Pak requirements without accurate baseline of what you currently hold. |
| 2. Determine Cloud Pak eligibility | Identify which Cloud Pak includes each product. Some products appear in multiple Cloud Paks with different ratios. | Choosing the wrong Cloud Pak can result in significantly higher VPC consumption for the same workload. |
| 3. Apply conversion ratios | Calculate VPCs required using official ratios. For PVU-based licences, first convert PVUs to VPCs (1:1 standard), then apply the ratio. | Companies new to Cloud Paks often assume one core equals one entitlement. They get caught when IBM applies a conversion ratio (e.g. 4 cores consuming 20 entitlement cores due to a 1:5 ratio). |
| 4. Aggregate and reconcile | Sum Cloud Pak VPC requirements for all products. Compare against proposed Cloud Pak purchase. | Ensures total entitlement covers all planned workloads with appropriate growth margin. |
| 5. Negotiate trade-ups or credits | IBM may offer conversion deals for valid support contracts. Engage your IBM account team to document conversion of entitlements in writing. | Written confirmation protects you in audits. Verbal agreements have no weight when IBM's audit team arrives. |
| 6. Handle mixed environments | IBM does not allow applying both PVU and Cloud Pak licence to the same instance. Separate instances must use separate licences. | Mixed environments create the most complex compliance scenarios. Maintain clear records of how you arrived at Cloud Pak VPC counts relative to legacy licences. |
Conversion ratios mean using certain components excessively can consume your entitlement much faster than expected. An intensive ACE workload consumes three times its core count in Cloud Pak terms. After migrating, monitor any single product's usage that could disproportionately consume your Cloud Pak licences and adjust capacity or acquire additional VPCs before it becomes a compliance issue. See IBM VPC Licensing Complexities for detailed analysis.
| Strategy | What to Do | Impact |
|---|---|---|
| Enforce resource limits | Always set explicit CPU limits on IBM containers. This caps the licensable vCPU for each pod. If a WebSphere container only requires 0.5 cores, set that limit. | Containers without limits are assumed to use an entire node, instantly multiplying counted VPCs. Use cluster admission controls or OCP quotas to enforce this as policy. |
| Right-size environments | Clusters are often over-provisioned "just in case." With Cloud Paks, excess capacity equals excess VPC usage. Start with fewer nodes/cores and allow auto-scaling to add capacity up to a defined limit. | Maintains steady-state licence consumption. Only increases when necessary. Every CPU eliminated saves approximately 70 PVU equivalents in licensing. |
| Use auto-scaling intelligently | Kubernetes horizontal pod auto-scaling only runs more pods and VPCs when demand exists, but set an upper bound. Use node affinity/taints to concentrate IBM workloads on specific nodes. | Localises licensing impact. Allows other nodes to be scaled down. Prevents IBM workloads from spreading across the entire cluster footprint. |
| Separate non-production environments | IBM does not differentiate between production and non-production in Cloud Pak licence counting. All consume VPCs the same way. | Isolating non-prod on smaller clusters lets you closely control licence capacity. Allocate a fixed portion (e.g. 20%) of Cloud Pak licences to non-production and ensure those clusters do not exceed that allocation. |
| Monitor peak vs average | IBM charges based on peak concurrent usage within a reporting period. A single surge, even for just a day, could determine your required entitlement for the entire quarter. | Use Licence Service data to identify when and why peaks occur. Design applications to distribute load more evenly rather than consuming huge CPU for short bursts. |
| Periodic cleanup and review | Containers tend to grow if left unchecked. Regularly review what is running. Remove or scale down IBM product deployments not delivering proportional value. | Idle pods from development teams may still consume VPC capacity. A tidy-up can free up licences immediately. Treat VPC usage like cloud spend with quarterly optimisation cycles. |
| Pitfall | What Happens | Mitigation |
|---|---|---|
| Failing to run required tools | The number one issue: not using ILMT or IBM Licence Service where required. IBM mandates ILMT for sub-capacity on VMs and Licence Service for containers. If an audit finds these are not running, IBM can declare you out of compliance by default. | Always deploy and maintain required tools, keeping records of their outputs as your compliance safe harbour. See IBM ILMT Guide. |
| Incorrect product classification | A component might not be properly identified as part of a Cloud Pak. If ILMT discovers MQ on a VM and you have Cloud Pak for Integration, you must classify that instance under the Cloud Pak. Misclassification leads to gaps or double-counting. | Use IBM's features to assign discovered software to Cloud Pak bundles. Regularly review reports for "unmatched" products that need proper classification. |
| Overlooking conversion ratios | Companies new to Cloud Paks may assume one core equals one entitlement. They get blindsided when IBM applies a conversion ratio (e.g. 4 cores consuming 20 entitlement cores due to a 1:5 ratio). | Always refer to Licence Information documents for each Cloud Pak. Check IBM's official ratio tables for every component before and after deployment. |
| Misusing restricted OpenShift entitlements | Cloud Paks provide "restricted" OpenShift usage. Included OCP nodes can only run Cloud Pak workloads. Deploying unrelated workloads on those clusters can result in IBM requiring full OpenShift licences. | Treat Cloud Pak OCP clusters as dedicated. If mixing workloads, ensure full OpenShift subscriptions for non-Cloud Pak components. |
| Ignoring non-production use | IBM does not provide free rides for non-production under Cloud Paks. All usage counts. Assuming unlimited dev/test instances are free is a common and costly mistake. | Include dev/test environments in licence tracking. Allocate a fixed portion of Cloud Pak licences to non-production and enforce cluster-level quotas. |
| Underestimating peak usage windows | Brief periods where usage exceeded entitlements (e.g. a load test) can technically constitute non-compliance. IBM measures peak concurrent usage. | Monitor and record peaks. If you intentionally exceed entitlements for testing, inform IBM proactively. Slightly licence above expected peak to provide a buffer. |
| Lack of internal audits | Many organisations only discover compliance issues when IBM audits them. By then leverage is with IBM and remediation costs are higher. | Conduct regular internal compliance audits at least annually. Simulate an IBM audit: inspect deployments versus entitlements and address discrepancies on your own terms. See IBM Audit Defence Service. |
Communicate that software compliance is a serious matter with real financial risks. Establish the tone at the top that following licence terms is integral to business ethics and risk management. Schedule periodic internal audits every 6 to 12 months. Keep entitlements organised in a well-maintained repository of all IBM entitlement documents, licence certificates, Passport Advantage agreements, proof of purchase, and IBM correspondence. Having this ready avoids scrambling during audits.
| Governance Area | What to Do | Why It Matters |
|---|---|---|
| Governance framework | Integrate Cloud Pak licensing into IT governance. Establish a steering committee or expand an existing ITAM committee to oversee IBM licensing. Include stakeholders from IT, finance, procurement, operations, and enterprise architecture. | Meet regularly to review IBM usage, spending, plan future needs, and approve major changes. Without formal governance, Cloud Pak costs drift upward unnoticed. |
| Budgeting and chargeback | Include Cloud Pak costs explicitly in IT budgeting. Allocate costs to business units or projects (showback/chargeback) based on Licence Service data. | If Department A uses 60% of Cloud Pak capacity, reflect that in IT finance reports. This incentivises departments to optimise their usage rather than treating licences as a shared free resource. |
| Continuous licence optimisation | Treat licence capacity like cloud resources. Continuously optimise through measure, analyse, optimise cycles. Continuously measure VPC usage, analyse trends and inefficiencies, and take action. | This ingrains a habit of not leaving licences underutilised or costs unchecked. Rightsizing deployments, reallocating entitlements, and removing waste become ongoing disciplines. |
| Contract and vendor management | Use leverage at renewal times. If usage is growing, negotiate volume discounts for more VPCs. At renewal, secure price holds or concessions. Consider multi-year ELAs if aligned with strategy. | Independent experts can advise on discounts and terms that peers are getting from IBM. IBM may bundle training or support into renewal deals if pushed. See IBM ELA Renewal Service. |
| Cloud/hybrid transitions | IBM allows BYOSL (Bring-Your-Own-Licence) for public cloud in many cases, but you must mark instances and still run Licence Service or ILMT. Plan how to maintain governance when infrastructure spans on-prem and cloud. | Use Licence Service Reporter to combine data from multiple environments. Factor in that cloud VMs may have hyperthreading (e.g. 1 AWS vCPU = 1 VPC = 70 PVUs). See IBM LPAR Licensing for virtualisation considerations. |
| Exit strategy considerations | Governance should consider what happens if you want to exit a Cloud Pak or switch to alternatives. Avoid over-committing beyond what makes sense. | Do not roll everything into Cloud Pak if certain products might be phased out. A flexible contract with ability to reduce scope on renewal or trade entitlements between Cloud Paks is valuable. See IBM Negotiations Service. |
A Virtual Processor Core (VPC) represents one virtual core available to an IBM programme. IBM standardised 1 VPC as equivalent to 70 PVUs in legacy metrics. This means if you previously licensed a product at 700 PVUs, that translates to 10 VPCs under the Cloud Pak model. The VPC metric was introduced to simplify licensing across processor types. Unlike PVUs, which vary based on chip architecture (a POWER core carries a different PVU value than an x86 core), a VPC is a flat unit regardless of underlying hardware. However, this simplification only applies to the metric itself. The surrounding governance, tracking, reporting obligations remain equally complex.
Yes. IBM's terms require deploying the Licence Service within 90 days of first use of an eligible product in a container environment. It is described as the only authorised licence metering tool for containers. If IBM Licence Service is not deployed and an audit occurs, IBM reserves the right to demand full-capacity licensing of the entire cluster. This means licensing every core on every worker node regardless of actual IBM software usage. For even a moderately sized cluster, this can multiply your licensing obligation by five to ten times what sub-capacity measurement would show. There is no grace period or informal workaround. Deploy ILS within the 90-day window and generate quarterly reports.
No. Cloud Pak OpenShift entitlements are "restricted" meaning they can only be used to run the specific Cloud Pak's workloads. If you deploy unrelated applications, third-party software, or even a different Cloud Pak's workloads on clusters running under the restricted OpenShift entitlement, IBM can require full unrestricted OpenShift subscriptions for those nodes. The safest approach is to treat Cloud Pak OCP clusters as dedicated. If you need to mix workloads on the same cluster, ensure you hold full unrestricted OpenShift subscriptions for those nodes in addition to the Cloud Pak restricted entitlements.
Each component product within a Cloud Pak has a conversion ratio defining how its usage consumes your pooled VPC entitlement. For example, App Connect Enterprise in Cloud Pak for Integration has a 1:3 ratio meaning 1 VPC of ACE running consumes 3 VPCs from your Cloud Pak entitlement. MQ Advanced has a 2:1 ratio meaning 2 VPCs of MQ only consume 1 VPC of entitlement. If a ratio is not explicitly stated in the Licence Information document, assume 1:1. The critical implication is that different workload mixes produce very different entitlement consumption even with identical infrastructure. Running 10 VPCs of ACE requires 30 VPCs of Cloud Pak entitlement, while running 10 VPCs of MQ only requires 5. Always model entitlement consumption based on your specific product mix before committing to a Cloud Pak purchase.
No. IBM does not provide free rides for non-production under Cloud Paks. All usage counts regardless of whether it is production, development, testing, staging, or disaster recovery. Every container running IBM software consumes VPCs that must be covered by your entitlement. This is one of the most common surprises for organisations adopting Cloud Paks. The recommended approach is to isolate non-production on smaller, tightly controlled clusters, allocate a fixed portion (e.g. 20%) of your total Cloud Pak VPC entitlement to non-production, and enforce cluster-level quotas to prevent dev/test workloads from consuming production licence pools.
IBM measures peak concurrent usage within a reporting period. A single surge, even for just a day (such as a load test), can technically constitute non-compliance and could determine your required entitlement for the entire quarter. The recommended mitigation is to licence slightly above expected peak to provide a buffer, monitor and record peaks using IBM Licence Service data, design applications to distribute load more evenly rather than consuming large CPU bursts, and if you intentionally exceed entitlements for testing, inform IBM proactively. Use Licence Service data to identify when and why peaks occur and adjust deployment architecture accordingly.
Yes, but not on the same instance. IBM does not allow applying both PVU and Cloud Pak licence to the same software instance. You must maintain separate instances with separate licence entitlements. This means you can run a traditional PVU-licensed MQ on one server while running a Cloud Pak VPC-licensed MQ on a separate OpenShift cluster. The two cannot be mixed on a single instance. Mixed environments create the most complex compliance scenarios. Maintain clear documentation of which licence covers which deployment. During migration from PVU to Cloud Pak, plan for a period where both licensing models run in parallel and ensure both are properly covered.
Preparation centres on three elements: tools, documentation, and internal audits. First, ensure IBM Licence Service is deployed on every cluster and has been generating quarterly reports. IBM expects up to two years of archived reports. Second, maintain organised records of all IBM entitlement documents, Passport Advantage agreements, licence certificates, proof of purchase, and any written correspondence about conversion deals or trade-ups. Third, conduct regular internal compliance audits at least annually. Simulate what IBM would find: compare actual VPC consumption from Licence Service reports against your entitlements, accounting for conversion ratios. Address any discrepancies on your own terms before IBM discovers them. Having an independent licensing expert perform a compliance health check provides an unbiased assessment and balances the knowledge asymmetry with IBM.
Whether you need a Cloud Pak compliance assessment, help calculating conversion ratios for migrating legacy licences, guidance on deploying IBM Licence Service across your clusters, or support optimising VPC consumption and preparing for audits, our IBM licensing specialists deliver vendor-neutral expertise to reduce risk, eliminate waste, and ensure compliance.
IBM Advisory ServicesIndependent compliance assessment, conversion ratio modelling, IBM Licence Service validation, and audit preparation. Fixed-fee engagements. No vendor conflicts.