Cloud migration and the PVU to VPC conversion.
When IBM workloads move to cloud, the metric often moves with them, from processor value units to virtual processor cores. The conversion is not cosmetic. Handled loosely, it produces a phantom entitlement gap that surfaces in the next audit.
A cloud migration is usually framed as an infrastructure project, but for IBM software it is also a licensing event. Many products that were metered in PVU on premises are licensed in virtual processor cores once they run in an eligible cloud environment. PVU is a core-based metric, weighting each core by a per core PVU rating, where an Intel core is commonly rated around seventy PVU. VPC counts virtual cores directly, without the weighting. Treat the two as interchangeable and the books will not reconcile when an auditor compares them.
The conversion matters because entitlements do not automatically follow the workload. You hold a quantity of PVU entitlement tied to a part number. Running the same software in cloud under a VPC metric requires the right VPC entitlement, and the relationship between the old and new quantity is governed by the product's terms, not by a simple division. Assuming a clean swap is where the gap opens.
Why the metric changes
Since Passport Advantage version eleven, with the change applying to existing customers from May 1 2023, sub-capacity reporting and ILMT obligations were extended to VPC-metered products, and manual counting is no longer permitted. The direction of travel is toward VPC for modern and cloud-deployed software. A migration is frequently the moment a product crosses that line, which means the on premises PVU position and the cloud VPC position are two different calculations that must each stand on their own evidence.
Where the conversion goes wrong
- Treating PVU and VPC as a fixed ratio rather than reading the product terms
- Carrying a PVU entitlement into cloud without securing matching VPC entitlement
- Losing sub-capacity because ILMT or the approved tool was not stood up in the new environment within the required window
- Landing on a cloud instance type or region that is not eligible for sub-capacity
- Double counting during the cutover, when the workload runs in both places at once
Keeping sub-capacity intact through the move
The defensible path is to plan the metric change as part of the migration rather than discovering it in an audit. Confirm the target metric for each product, secure the correct entitlement before cutover, and stand up approved sub-capacity reporting in the cloud environment from day one so the new VPC count is evidenced continuously. Track the cutover window deliberately so the same instance is never counted twice. Done this way, the migration closes the on premises position cleanly and opens a clean cloud position, with no gap for an auditor to find.
A migration creates two licensing positions, not one continuous one. Read each product's terms to confirm whether it converts to VPC, secure matching entitlement before cutover, and run approved sub-capacity reporting in cloud from day one, so the old PVU position and the new VPC position each stand on their own evidence.
Migrating IBM workloads to cloud?
Our Sub-Capacity Defense engagement confirms the right metric per product, validates entitlement coverage, and proves the cloud capacity count before an auditor questions it.
See Sub-Capacity Defense →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.