Analytics estates carried 20 to 40 percent recoverable spend, and the cartridges nobody deployed are the least visible part
Cloud Pak for Data bundles many data and AI capabilities behind one VPC pool. Estates routinely pay for cartridges they never deploy, and the bundle structure is what makes that invisible.
Prepared by Redress Compliance · August 16, 2026 · IBM advisory.
Executive summary
Most analytics estates carry 20 to 40 percent recoverable spend, spread across role inflation on legacy products, cartridges nobody deployed, and sub capacity that was never measured.
The cartridge line is the least visible of the three. Cloud Pak for Data bundles many data and AI capabilities, and a bundle consumed at pool level gives no signal about which cartridges were ever switched on.
Conversion onto Cloud Pak for Data runs at a published ratio, so confirm the conversion math against existing entitlements before agreeing to migrate rather than after.
Legacy user roles carry very different list prices. Mapping people to the cheapest role that works remains a large single lever on anything still licensed by role rather than by VPC.
Two licensing worlds in one estate
IBM analytics is converging on Cloud Pak for Data while legacy products remain on their original metrics. Most estates run both at once, which is where the recoverable spend accumulates.
| Layer | Metric | Where spend leaks |
|---|---|---|
| Cloud Pak for Data | Virtual Processor Core against a pool | Cartridges bundled and never deployed |
| Legacy analytics products | User role metrics with distinct list prices | Role inflation against what people actually do |
| Sub capacity on VPC | Conditional on ILMT | Full capacity billing where measurement is missing |
| Conversion | Published ratio from legacy entitlement | Ratio accepted rather than confirmed |
The bundle is what makes unused cartridges invisible. Cloud Pak for Data consumption reports at pool level, so a pool drawn down by three capabilities looks identical to one drawn down by ten. Nothing in the consumption view distinguishes a cartridge that carries the estate from one that was bundled in at conversion and never switched on. That is not a reporting failure, it is what pooled licensing does, and it means the cartridge question has to be asked deliberately because no report will raise it.
Three leaks, and only one of them shows up in a review
Most analytics estates carry 20 to 40 percent recoverable spend, and it sits in three places that behave very differently under scrutiny. Role inflation on legacy products is the one a conventional licence review finds, because roles map to named people and the mapping can be tested against activity. Cognos user roles in particular carry very different list prices, so mapping people to the cheapest role that works remains a large single lever wherever role based licensing survives.
Unmeasured sub capacity is the second, and it is the familiar IBM condition: VPC sub capacity requires the IBM License Metric Tool, and without it IBM defaults you to full capacity at audit. That is not analytics specific and it is well understood, which is why estates that have addressed it elsewhere have usually addressed it here too. Where they have not, the exposure is mechanical rather than arguable.
The third leak is the one worth the attention, because nothing surfaces it. Cloud Pak for Data bundles many data and AI capabilities into a single VPC pool, and estates routinely pay for cartridges they never deploy. Pool level consumption gives no signal: a pool drawn down by a handful of capabilities reports identically to one drawn down by the full catalogue. The cartridges arrived at conversion as part of a bundle that looked like value, and nobody has since been asked which of them a workload depends on. Asking that question is the entire remedy, and it requires deliberate inventory rather than a report.
The conversion itself deserves the same treatment. Moving onto Cloud Pak for Data converts existing entitlements at a published ratio, and confirming that math before agreeing to migrate is materially easier than contesting it afterwards. The same discipline recurs across IBM: the ratio, the pool, and the instrumentation are all decided at moments that pass quickly and are hard to reopen. The shelfware position sits in the shelfware playbook, the role mix in Cognos licensing, and the library in the IBM practice.
- Your agreements decoded into plain English before the auditor interprets them for you
- Entitlement mapped to deployment cartridge by cartridge, not pool by pool
- A defensible position paper generated in minutes, not weeks
Recovering the three leaks
- Inventory cartridge usage deliberately, because pool level consumption reports give no signal about which capabilities are actually deployed.
- Map legacy users to the cheapest role that works, since analytics role metrics carry very different list prices and the mapping is testable against activity.
- Confirm the conversion ratio before migrating, as it is published rather than negotiated by default and far easier to check than to contest.
- Verify ILMT covers the VPC estate, since sub capacity is conditional and the default at audit is full capacity.
- Separate what converged from what did not, because most estates run Cloud Pak for Data and legacy metrics simultaneously and the leaks differ by layer.
- Ask which cartridges a workload depends on, which is the whole remedy for the least visible of the three leaks.
Where the recoverable spend sits
The pattern across IBM analytics estates is consistent, and the three components are not equally visible:
Carried by most analytics estates across role inflation, unused cartridges, and unmeasured sub capacity.
How Cloud Pak for Data consumption reports, which makes a pool drawn by three capabilities look identical to one drawn by ten.
IBM analytics is converging on Cloud Pak for Data licensed by Virtual Processor Core, while legacy products such as Cognos remain on user role metrics. Most estates therefore run both models simultaneously, and the leak differs by layer.
Moving onto Cloud Pak for Data converts existing entitlements at a published ratio. Confirming that math before agreeing to migrate is considerably easier than contesting it afterwards.
Your first five moves
- List every cartridge in the Cloud Pak pool and identify which ones a live workload actually depends on.
- Test legacy role assignment against activity, since roles carry very different list prices and the mapping is verifiable.
- Confirm the conversion ratio against your existing entitlements before agreeing any migration.
- Verify ILMT coverage across the VPC estate, because the audit default is full capacity.
- Treat the three leaks separately, since they surface differently and only one appears in a standard review. The IBM practice runs the inventory with you.
Frequently asked questions
How is IBM analytics licensed now?
It is converging on Cloud Pak for Data, licensed by Virtual Processor Core against a pool, while legacy products such as Cognos remain on user role metrics. Most estates run both models simultaneously.
How much is typically recoverable?
Between 20 and 40 percent, spread across role inflation on legacy products, cartridges that were bundled but never deployed, and sub capacity that was never measured. The three behave differently and only one shows up in a standard review.
Why are unused cartridges invisible?
Because Cloud Pak for Data consumption reports at pool level. A pool drawn down by three capabilities looks identical to one drawn down by ten, so nothing in the consumption view distinguishes a load bearing cartridge from a dormant one.
How do we find the unused cartridges?
By asking deliberately which cartridges a live workload depends on, product by product. There is no report that raises the question, so the inventory has to be built rather than pulled.
Is the conversion ratio negotiable?
It is published rather than negotiated by default, which is exactly why confirming the math against your existing entitlements before agreeing to migrate matters. Checking it beforehand is far easier than contesting it afterwards.
What is the role inflation lever worth?
Substantial on anything still licensed by role. Analytics user roles carry very different list prices, and mapping people to the cheapest role that works is testable against activity data you already hold.
Does sub capacity apply here?
Yes, and on the same terms as the rest of IBM. VPC sub capacity licensing requires the IBM License Metric Tool, and without it IBM defaults you to full capacity at audit.
Why does the bundle structure matter so much?
Because pooled licensing deliberately decouples what you pay for from what you run. That is what makes the pool flexible, and it is the same property that makes unused capability invisible without a deliberate inventory.
Should we resist converging on Cloud Pak for Data?
Not necessarily. The convergence brings real flexibility across data and AI capabilities. The question is whether the cartridges bundled at conversion match what your workloads need, and that is answerable only by asking.
Which of the three leaks should we address first?
The cartridges, because nothing else will surface them. Role inflation appears in a licence review and sub capacity appears at audit, but an unused cartridge inside a consumed pool leaves no trace until somebody asks.
