Planning Analytics, the engine many teams still call TM1, has long been licensed by user and by processor in its standalone form. When it is deployed as a cartridge on Cloud Pak for Data, the licensing context changes. Cloud Pak for Data is a container platform, and software running on it is metered and entitled according to platform rules rather than the standalone product rules. Teams that migrate without re mapping the metric carry their old mental model into a new environment, and that mismatch is what an audit exposes.
The metric shift to VPC.
Since Passport Advantage version 11, sub-capacity reporting and ILMT apply to Virtual Processor Core metered products, and manual counting is no longer permitted. Cloud Pak for Data and the products that run on it sit squarely in that world. Planning Analytics consumed through the platform is measured against VPC entitlement drawn from the Cloud Pak pool, not against the standalone user or processor counts you may have purchased years earlier. The first defensive task is to establish which entitlement actually governs the deployment as it runs today, because it is frequently not the one on the original order.
Container rules raise the stakes.
The container model carries a sharp edge. For Cloud Pak and container deployments, non-compliance does not cost you the cores running the software. It can mean IBM charges for all cores in the cluster. A misconfiguration that would be a contained finding on a virtual machine becomes a cluster wide exposure on a container platform. That single rule is why Planning Analytics on Cloud Pak for Data deserves more licensing attention than the standalone product, not less, and why the tooling and entitlement tracking have to be correct continuously rather than reconstructed after the notice arrives.
Where these deployments find exposure.
- Metric carried over. Old user or processor counts assumed to still apply, when VPC entitlement now governs the platform deployment.
- Pool tracking gaps. Cloud Pak entitlement consumed across products without a current view of what the pool actually covers.
- Container non-compliance. A configuration or tooling failure that exposes the whole cluster rather than the Planning Analytics workload.
- Tooling not aligned to VPC. ILMT or the approved tool not capturing the container metric, so the sub-capacity position cannot be evidenced.
Planning Analytics on Cloud Pak for Data is a VPC and container licensing question, not a TM1 user count question. The buyer side response is to re map the metric to what governs the platform deployment, verify the entitlement pool, and confirm the tooling evidences VPC continuously, so a finding can be challenged and confined rather than left to expand across the cluster.
The buyer side defense.
We contain the data request, then establish the governing metric for the deployment as it runs on Cloud Pak for Data, mapping VPC consumption against the entitlement pool. We verify the container configuration and the tooling so the sub-capacity position is evidenced and the cluster wide charge has no foothold, and any genuine gap is confined to the precise workload and period. The reconciled position carries into the negotiation, where the settlement names the metric, the entitlement and a forward plan that keeps the platform deployment inside its VPC pool.