IBM Advisory
IBM Analytics and Data Platform Licensing: a Buyer Guide
How Cloud Pak entitlement works, where Virtual Processor Cores get overcounted, and how to rebase before renewal.
How Cloud Pak entitlement works, where Virtual Processor Cores get overcounted, and how to rebase before renewal.
IBM prices analytics on Virtual Processor Cores under Cloud Pak for Data, and generous sizing quietly pays for cores the workload never uses.
It is structured around Virtual Processor Cores under Cloud Pak for Data, with the underlying engines entitled inside the Cloud Pak rather than licensed separately.
The metric is the VPC, and the IBM License Metric Tool is what proves sub capacity. Without it, IBM measures full capacity.
Cloud Pak for Data ships in three commercial editions. Enterprise Edition carries the full service catalog, Standard Edition is a capped entry tier, and Enterprise Edition Non Production covers test and development at a lower VPC price.
The base platform bundles a working set of services with limits. IBM caps it at five dashboard authors and twenty viewers before a separate Cognos entitlement is required, plus 12 TB of Storage Fusion data per OpenShift cluster.
Two editions of the same tool can carry very different unit prices. Non production entitlement is materially cheaper, so tagging development and test clusters correctly is a pricing decision, not just housekeeping.
A VPC is a virtual core assigned to the OpenShift worker nodes that run the software. IBM counts the cores visible to the container platform, so oversized nodes inflate the number even when the workload sits idle.
The cartridge model lets one shared VPC entitlement move across services instead of buying each engine standalone. Each cartridge draws down Cloud Pak for Data VPCs at its own ratio when you deploy it.
IBM publishes the current catalog on its Cloud Pak for Data cartridges page. Db2, DataStage, Informix, Master Data Management, Cognos Analytics, Planning Analytics, Watson Discovery, and OpenPages are all offered as cartridges.
Shared entitlement is the selling point and the risk. Because one VPC pool feeds many cartridges, an unbounded deployment can quietly consume entitlement you meant to hold for another service. Governance of the pool matters as much as the purchase.
The mechanic matters at purchase. A cartridge ratio converts one unit of the underlying product into a set number of platform VPCs. Misread that ratio and a bundle that should cost less ends up priced like standalone licenses.
Cloud Pak for Data: representative cartridges
| Cartridge | Underlying product | Licensing note |
|---|---|---|
| Db2 | Db2 database engines | Covered inside the bundle, do not license twice |
| DataStage | Data integration | Non production tier available at lower VPC |
| Cognos Analytics | Enterprise BI | Trade up from standalone Cognos PVU |
| Planning Analytics | TM1 planning | Cartridge or standalone, not both |
| OpenPages | Governance and risk | Heavier VPC ratio per instance |
Each cartridge consumes platform VPCs at a fixed conversion, and heavier engines consume more. Confirm the ratio in the current license terms before you size, because an old ratio applied to a new bundle silently inflates the entitlement.
It gets overcounted at peak sizing, at engine double counting, and at full capacity defaults. Each is recoverable before renewal.
The drivers stack. An estate can carry peak sizing, a double counted engine, and a full capacity default at the same time, which is why the combined recovery often lands near the top of the range rather than the bottom.
IBM analytics licensing: overcount drivers
| Driver | What happens | Buyer counter |
|---|---|---|
| Peak VPC sizing | Entitlement set to busiest hour | Size to steady state plus burst headroom |
| Engine double count | Db2 licensed beside the Cloud Pak | Map engines covered by the bundle |
| Full capacity default | No metric tool reporting | Deploy ILMT and claim sub capacity |
| Non production | Test and dev counted as production | Apply non production entitlements |
| Ratio drift | Old VPC ratios on new bundles | Confirm current bundle ratios |
Size to steady state with a defined burst allowance. Peak sizing inflates the VPC count by 25 to 45 percent in our files.
It hides when Db2 or an analytics engine is licensed separately while a Cloud Pak already entitles it. Map every engine to its bundle before you renew.
Current metric tool reporting, refreshed on schedule. Lapsed reports push you back to full capacity at audit, the most expensive default.
Legacy Cognos and SPSS licenses trade up into Cloud Pak for Data VPCs rather than carrying across one to one. The conversion is negotiated, so the trade up ratio is a lever, not a fixed rate.
Standalone Cognos Analytics was sold on Processor Value Units and authorized users. IBM lifecycle notes put Cognos 11.2 at end of support on 30 April 2026, which pushes buyers toward the cartridge.
SPSS is not on the current cartridge list, so SPSS Statistics and Modeler map through a trade up quote rather than a published cartridge ratio. Treat any SPSS to VPC conversion as fully negotiable.
Trade up value is real leverage. Even shelved Cognos or SPSS licenses you never intend to run again carry credit, and IBM would rather convert them than watch them lapse unused.
The trap is trading up a peak sized legacy estate. If the old Cognos count was inflated, the VPC conversion inherits that inflation and locks it into the new metric.
Audits trigger on entitlement gaps, lapsed metric reporting, and large deployment changes. Preparation is continuous Passport Advantage record keeping, not a scramble.
IBM requires the License Metric Tool installed within 90 days of your first sub capacity deployment, with reports generated at least quarterly. Miss any of those and the affected products revert to full capacity.
Since 1 May 2023 IBM no longer accepts manual spreadsheet reporting for most environments. The sub capacity terms and conditions now expect a supported tool feeding an unbroken report history.
Retain the signed reports for at least two years. Auditors reconstruct the full window, so a single missing quarter can reopen the whole period at full capacity and erase the sub capacity benefit you earned.
Cost scales with the VPC count and the cartridge mix, so two estates running the same tools can pay very differently. The scenarios below show how sizing discipline moves the count, using illustrative VPC figures, not quotes.
These numbers are modeling assumptions to show the mechanics. They are not IBM quotes or Redress engagement data. Use them to frame your own count, then price it against your Passport Advantage terms.
Illustrative VPC rebasing scenarios
| Profile | Peak sized VPC | Rebased VPC | Main driver |
|---|---|---|---|
| Single data mart | 48 | 32 | Peak to steady state |
| Mixed BI and Db2 | 120 | 78 | Engine double count removed |
| Enterprise platform | 320 | 190 | Non production separated |
Read the table as ratios, not budgets. The recoverable gap between the peak sized and rebased columns is entitlement you stop paying for, and it is largest where non production was folded into production counts.
Rebasing to steady state and removing double counts typically strips a quarter to nearly half of the VPC count in our reviews. The larger the estate, the larger the absolute recovery, because peak headroom compounds across every cartridge.
Cut it by rebasing VPCs, removing double counts, and proving sub capacity before the renewal quote is built.
The common advice from the account team is that Cloud Pak simplifies licensing, so you should size generously and stop worrying about the individual engines. We disagree. In a clear majority of the estates Morten Andersen reviewed, generous sizing meant paying for 25 to 45 percent more Virtual Processor Cores than steady state demand, while engines already inside the Cloud Pak were licensed a second time on the side. The buyer side move is to rebase the VPC count to measured steady state, map every engine to the bundle that already covers it, and deploy metric tool reporting so sub capacity is provable. Simplicity is not a reason to overbuy.
A clean, measured VPC count backed by current metric reporting. It removes IBM's full capacity fallback and resets the quote to real demand.
Bring three artifacts to the table. A rebased VPC count, an engine to cartridge map, and a current metric report. Together they remove IBM's full capacity fallback and anchor the quote to demand you can defend.
Timing compounds the leverage. Rebasing 9 to 12 months out lets you drop unused cartridges at renewal rather than mid term, when IBM holds the pricing power and co terming works against you.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
IBM analytics is priced on the cores you might use at peak. The negotiation is won by proving the cores you actually use.
Cloud Pak for Data is licensed on Virtual Processor Cores. A fixed VPC ratio entitles a set of data and AI services bundled inside the Cloud Pak.
A Virtual Processor Core is the IBM metric that counts virtual cores assigned to a workload rather than physical sockets. Billing follows assigned VPCs.
Most often because it was sized to peak demand. In our 2024 to 2025 files, peak sizing overstated entitlement by 25 to 45 percent versus steady state.
It is licensing Db2 or an analytics engine separately when a Cloud Pak bundle already entitles it. Mapping engines to the bundle removes 10 to 20 percent.
Sub capacity lets you license the virtual cores assigned rather than full physical capacity. It requires current License Metric Tool reporting to claim.
If the metric tool reporting lapses, IBM measures full capacity at audit. That default is the most expensive outcome and is avoidable.
Keep metric reporting current across the full window, reconcile deployed VPCs to entitlement quarterly, and tag non production so it is not counted as production.
Start 9 to 12 months out so you can rebase the VPC count, remove double counts, and confirm sub capacity before IBM builds the quote.
A cartridge is a data or AI service that draws on a shared Cloud Pak for Data VPC entitlement. One pool of VPCs can run several cartridges instead of separate product licenses.
Yes, through a negotiated trade up into VPCs rather than a one to one carry over. Value the unused entitlement and fix the trade up ratio in writing before you sign.
The guide gives you the Virtual Processor Core counting method, the engine mapping worksheet, and the metric tool checklist that proves sub capacity.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
