A Cloud Pak replaces a shelf of per-product PVU entitlements with one pooled subscription counted in Virtual Processor Cores — flat per-core counting with no processor table, support folded in, and a bundled OpenShift entitlement — but every component you run draws from that pool at a published conversion ratio, and the ratios, not the headline VPC count, decide what the bundle is actually worth. Standalone PVU remains the right basis where the estate is stable and the product list is short; the Cloud Pak case rests on breadth of use and a real container roadmap, and it should be proven against your own deployment numbers, not the conversion sheet’s.
Published 2 January 2026 · Last reviewed 30 January 2026
Standalone PVU is the classic Passport Advantage shape: a separate entitlement for each product — WebSphere here, MQ there, Db2 somewhere else — counted in Processor Value Units, where every core carries a weighting from IBM’s processor table according to chip family and model. Most of these entitlements are perpetual licences with annual Subscription and Support, and on virtualized infrastructure they live or die by the sub-capacity discipline covered in the full-capacity versus sub-capacity guide: ILMT or an approved tool, quarterly reports, two-year retention.
A Cloud Pak is IBM’s consolidation of that shelf into a single subscription. You buy a pool of Virtual Processor Cores — a flat metric, one core equals one VPC, no processor table — and the pool entitles you to run any of the Pak’s component products, each consuming capacity at a ratio IBM publishes per product and per deployment form. The bundle includes a restricted-use Red Hat OpenShift entitlement to run the containerised editions, support is included for the term rather than invoiced as separate S&S lines, and containerised deployments are metered by the IBM License Service rather than ILMT. The same family of choices — bundle versus à la carte — recurs across IBM’s commercial constructs, up to the agreement level compared in the ELA versus Passport Advantage guide.
The comparison, then, is not metric trivia. It is two different theories of the IBM relationship: per-product ownership with per-product compliance, against pooled subscription capacity whose economics are set by ratio arithmetic.
This guide compares licensing programs as published by the vendor; it is general information, not legal or licensing advice for your situation, and it names no firms. Program terms and conversion ratios change — verify current terms against your own Passport Advantage agreement and the product-specific licensing documents. The firm directory lists IBM-capable advisors with balanced pros and cons, listed, not ranked.
| DIMENSION | STANDALONE PVU | CLOUD PAK (VPC) |
|---|---|---|
| Unit of count | PVUs — cores weighted by IBM’s processor value table, per product | VPCs — flat per virtual or physical core, drawn from one pool at per-component ratios |
| Ownership shape | Typically perpetual licence plus annual S&S renewal per product | Term subscription; support included for the term; rights end if not renewed |
| What is entitled | The named product, exactly | The Pak’s component set, in containerised and usually traditional editions, plus restricted-use OpenShift |
| Metering | ILMT or approved tool for sub-capacity, quarterly reports, two-year retention | IBM License Service for containers; ILMT-class tooling persists for VM-deployed components |
| Cost mechanics | Driven by processor table and deployment count; S&S uplift compounds annually per line | Driven by pool size and conversion ratios; one renewal event reprices everything at once |
| Flexibility | Rigid — capacity sits with the product it was bought for | Fluid — the pool reallocates across components as consumption shifts, at ratio cost |
| Exit position | Perpetual rights survive an S&S lapse (run-as-is, unsupported) | Depends on what the conversion surrendered; pure subscription leaves nothing to fall back to |
The exit row deserves the longest look. A standalone PVU estate that stops paying S&S keeps running — degraded, unsupported, but licensed. A Cloud Pak estate at term end holds whatever the original paperwork preserved: if the deal traded perpetual entitlements in, the fallback may be nothing at all. That asymmetry is examined in depth in the IBM perpetual versus subscription guide; in the Cloud Pak context it is the clause to read before any other.
Every Cloud Pak proposal arrives with a conversion: your PVU entitlements translated into a VPC pool, commonly anchored on published trade-up ratios. Three pieces of arithmetic decide whether the translation is fair, and none of them is on the cover page.
First, the entitlement-to-consumption ratio per component. One licensed VPC does not buy one VPC of every product; each component consumes the pool at its own rate, and the rates differ between containerised and traditional deployment. A pool sized on the assumption that capacity converts one-for-one across the portfolio overstates what was bought — in advisory practice, unfavourable component ratios routinely cut effective capacity by double-digit percentages against the buyer’s expectation.
Second, the allocation baseline. The conversion is computed on today’s deployment, and today’s deployment is rarely right-sized: virtualized estates habitually carry allocated cores well above what workloads need. Converting an inflated baseline locks the inflation into a subscription that renews. Right-size first, convert second — the order changes the number materially.
Third, the things the bundle includes that you may not use. The OpenShift entitlement and the broader component set carry genuine value on a container roadmap and none without one. Price the bundle against the components you will actually run, not the catalogue list.
The Cloud Pak fits estates that genuinely use breadth: several of the Pak’s components in production, consumption that shifts between them, and a credible OpenShift or containerisation plan that will use the bundled platform and the flat VPC metric’s portability. It also suits organisations that want one renewal event and bundled support in place of a ledger of per-product S&S lines — accepting that consolidation concentrates renewal risk in a single negotiation.
Standalone PVU fits the narrow-and-stable estate: one or two products, deployments that move little, no container ambitions for these workloads, and perpetual entitlements whose economics improve every year they continue earning their keep. It also fits buyers for whom the exit position matters most — the right to keep running on lapsed support is real option value that a subscription does not replicate.
The test that decides it: list the Pak’s components you would actually run in the next three years, compute the VPC consumption for each at the published ratios on a right-sized baseline, and compare the total against the like-for-like cost of keeping the standalone lines. If the bundle wins only when unused components and the OpenShift entitlement are priced as if consumed, it does not win.
Conversions are IBM’s preferred audit settlement. PVU audit findings habitually resolve into Cloud Pak adoptions: the exposure becomes the down payment on a subscription. That can be a good outcome — but only if the conversion math is interrogated with the same rigour as the finding itself, which is precisely when buyers are least inclined to do it. An IBM audit defense engagement treats the settlement structure, not just the compliance number, as the thing under negotiation.
The compliance machinery doubles before it shrinks. A migrating estate runs ILMT-class tooling for its remaining PVU and VM-deployed VPC positions and the IBM License Service for its containers, simultaneously, often for years. Both must be healthy; an audit tests each on its own terms. Budget the overlap as part of the conversion, and keep the evidence chains separate and complete.
One renewal, all the leverage — on both sides of the table. Consolidating into a pool converts many small renewal events into one large one. Your position strengthens if you arrive with consumption data per component and a credible fallback; it weakens if the Pak has become load-bearing and the term simply expires into a repricing. Start the renewal analysis a year out, the way a renewal negotiation engagement would structure it.
Paper the fallback now. Whether perpetual entitlements survive the conversion is a drafting question answered at signature. Surrender clauses, reversion rights and what happens to deployed instances at non-renewal belong in the order document, explicitly — the cheapest moment to secure an exit is the moment you enter.
Converting the inflated baseline. The pool gets sized on allocated cores nobody right-sized, and the surplus renews forever after. The fix costs nothing but sequencing: optimise the deployment, then convert what remains.
Reading the headline ratio as the effective ratio. The trade-up ratio that converts entitlements is not the consumption ratio of each component you run. Estates discover the difference as a pool that empties faster than the spreadsheet said it would — a shortfall that surfaces, unhelpfully, as a compliance gap rather than a budget line.
Letting the License Service be nobody’s job. The container metering carries the same character of obligation as ILMT: deployed correctly, kept current, reports retained. Estates that learned ILMT discipline the hard way sometimes assume containers meter themselves; the audit finding that follows looks exactly like the old one with new vocabulary.
Surrendering perpetual rights for a discount that was leaving anyway. Trade-up pricing rewards bringing entitlements in; what it buys back is a subscription that reprices at term. Value the surrendered fallback position as an asset with a price, and make the discount clear that price explicitly.
Taking the conversion model from the party that profits by it. The vendor’s sizing, and sometimes a reseller’s, are sales documents. The independence test applies in full: whoever validates the ratio math should have no economics in the outcome.
It depends on how the deal is papered. Some Cloud Pak transactions are trade-ups that surrender the underlying perpetual entitlements in exchange for subscription capacity; others leave the perpetual licences in place and add the Cloud Pak alongside. The difference decides what you fall back to if the subscription is not renewed — have the surrender mechanics stated explicitly in the order before signing.
A Virtual Processor Core is a flat per-core unit: one virtual or physical core counts as one VPC regardless of the chip it runs on. A PVU entitlement depends on IBM’s processor value table, which weights each core by processor family — typically 70 to 120 PVUs per core. Moving to VPC removes the processor-table variable but introduces the Cloud Pak conversion ratios, which decide how much product capacity each licensed VPC actually buys.
The tooling obligation continues, but the tool changes with the deployment style. Containerised Cloud Pak workloads on OpenShift are metered by the IBM License Service, while VPC products deployed on traditional virtual machines remain in ILMT or an approved equivalent. Both routes carry the familiar discipline: deploy the tool, keep it current, generate and retain the reports.
Frequently yes. Most Cloud Paks include entitlement to the traditional, VM-deployed editions of their component products at published ratios, so adoption does not require same-day containerisation. The ratios for traditional deployment often differ from the containerised ones — check the product-specific licensing terms for each component you intend to run outside OpenShift.
Either, depending entirely on your platform strategy. The bundled OpenShift entitlement is restricted to running the Pak’s components and carries real value only where containerisation of those workloads is genuinely planned. An estate that keeps everything on virtual machines pays for an embedded platform it never deploys.
No. This is a directory, not a ranking. Firms are listed alphabetically with balanced pros and cons. Independence is shown as a pro and reseller, Big-Four or vendor-side-audit ties as a con, both stated as factual trade-offs for you to weigh.
Right-sizing the baseline, testing the conversion ratios against your real component mix, and papering the fallback before signature — that is precisely the work of an IBM licensing advisory engagement. The IBM hub maps the vendor’s wider licensing world, and the directory lists every firm covering IBM — with balanced pros and cons, listed, not ranked. Choosing between them? Start with how to choose an IBM licensing partner.
The criteria, questions and red flags →
Every firm for this work →
The counting basis underneath it all →
The ownership question behind the conversion →
When the finding has already landed →
Every field guide on the site →
Tell us the vendor, the service you need and where things stand, and we will route your brief to firms that genuinely cover that combination. The directory and matching are free for buyers, no vendor ever sees your brief, and we add no markup.
Our weekly dispatch on vendor audit programs, regional developments and one buyer move. Subscribe to The Licensing Radar.