Licensing IBM Workloads in the Cloud: The Three Track Decision
One IBM workload, three license tracks, and a 90 day clock that decides whether you count 1,400 cores or 2,520. The track you pick is a money decision, not a technical one.
Prepared by Redress Compliance · June 2026 · Representative IBM estate scenario (benchmark scenario, not a quote)
Executive Summary
Moving an IBM workload to public cloud does not move the license question, it sharpens it. The same PVU you counted on a host now has three possible homes: a Cloud Pak VPC bundle, a bring your own license deployment, or an IBM SaaS subscription. The track you choose sets your cost and your audit exposure for years.
The conversion math is fixed and public. 70 PVU equals 1 VPC equals 1 vCPU equals 1 core on the standard exchange. What is not fixed is which metric IBM gets to count. Run the IBM License Metric Tool and you count deployed cores. Miss the 90 day install clock and IBM counts the whole host.
In the worked scenario below, a 20 core WebSphere estate counts as 1,400 PVU under sub capacity and 2,520 PVU at full capacity. That gap is 1,120 PVU, roughly 143,000 dollars a year of support for cores you never ran IBM software on.
This paper sets out the three tracks, the conversion ratios, the cloud vCPU mapping, the sub capacity evidence IBM accepts, why audit risk rises in containers, and when retiring the metric entirely through SaaS is the cheaper answer.
Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025.
Which of the three migration tracks fits this workload?
Pick the track by what you already own and how stable the workload is, not by what the IBM account team is selling this quarter. Bring your own license keeps your sunk PVU investment working. Cloud Pak conversion modernizes the metric to VPC and bundles related products. SaaS retires the license and the support stream together.
Each track answers a different question. Bring your own license asks whether you can move what you have. Cloud Pak asks whether a bundle is worth a premium. SaaS asks whether you would rather stop counting cores at all.
| Track | Metric counted | Best fit | Key constraint |
|---|---|---|---|
| Bring your own license | PVU, sub capacity | Stable workload, active maintenance already paid | ILMT mandatory, support must stay current |
| Cloud Pak conversion | VPC bundle | Modernizing to containers, using several bundled products | Bundle premium if you use only one product |
| IBM SaaS subscription | Subscription, no metric | Workload you want IBM to run and patch | 3 to 5 year term, no trade back to perpetual |
The choice is rarely uniform across an estate. A mainframe adjacent MQ broker may stay on bring your own license while a customer facing app server moves to WebSphere Hybrid Edition SaaS. IBM publishes the container terms that govern all three on its Passport Advantage container licenses page.
How does a PVU license convert into a Cloud Pak VPC entitlement?
A Cloud Pak conversion is a one time exchange of legacy PVU entitlements for Virtual Processor Cores. The published baseline is 70 PVU to 1 VPC, and on a favorable trade up IBM has offered 1 PVU of credit toward 1 VPC of bundle value. The exchange is permanent. Once you convert, the original perpetual entitlement is retired.
The value of a Cloud Pak is fungibility. One Pak entitlement covers multiple bundled products at flexible ratios, so VPC held against Cloud Pak for Data can run Db2, Watson services, or Data Virtualization in any mix. Red Hat OpenShift is bundled in, which is why the workload becomes portable across any cloud that runs OpenShift.
| Starting entitlement | PVU held | VPC after exchange | What the VPC also unlocks |
|---|---|---|---|
| WebSphere ND | 1,400 | 20 | Liberty runtime, container portability on OpenShift |
| MQ Advanced | 700 | 10 | MQ on containers plus managed file transfer in the Pak |
| Db2 Advanced | 1,050 | 15 | Cloud Pak for Data services, fungible across Db2 and Watson |
The contract mechanic buyers miss is the trade in credit. IBM does not advertise it, but prior perpetual spend on products with active support can be recognized against the conversion. We have seen 25 to 40 percent credit applied when the buyer asked and held the line.
The conversion ratios and bundle rules are set out in the IBM Cloud Paks licensing guide.
Can you keep your PVU licenses and move them to the cloud?
Yes. Under the IBM bring your own software license policy, existing PVU entitlements move to AWS, Microsoft Azure, Google Cloud, IBM Cloud, and other eligible providers, and sub capacity rules still govern the count. You do not buy the license again. You move it.
Two conditions decide whether the move holds. Maintenance must be current, because a lapse in support disqualifies bring your own license on most products. And the cloud vCPU has to translate to PVU through a published mapping, which is uniform on the major clouds.
| Cloud provider | Counting unit | PVU per vCPU | ILMT required |
|---|---|---|---|
| AWS | vCPU | 70 | Yes, quarterly |
| Microsoft Azure | vCPU | 70 | Yes, quarterly |
| Google Cloud | vCPU | 70 | Yes, quarterly |
| IBM Cloud | vCPU | 70 | Yes, quarterly |
The active maintenance trap is the one that costs real money. A buyer who lets support lapse to save a year of cost loses the right to count sub capacity. IBM is then entitled to full capacity on the host.
The policy and the eligible provider list sit in the IBM eligible public cloud BYOSL policy and the BYOSL licensing guide.
What sub capacity evidence does IBM accept in a container cluster?
IBM accepts ILMT quarterly reports, and almost nothing else, as proof of sub capacity in a cloud or container deployment. The tool must be installed within 90 days of the first eligible sub capacity deployment, and snapshots must be retained for two years. Miss the install window and IBM is contractually entitled to full host capacity for that period.
Container deployments raise the evidence bar because partitioning is dynamic. ILMT has to see the pods, the vCPU limits, and the namespace boundaries to count deployed cores instead of the whole node. Without that, the cluster counts at full capacity.
| Counting basis | vCPU counted | PVU | Annual support |
|---|---|---|---|
| Sub capacity, deployed pods | 20 | 1,400 | $179,200 |
| Overcount if ILMT clock missed | 16 | 1,120 | $143,360 |
| Full capacity, whole host | 36 | 2,520 | $322,560 |
Full capacity versus sub capacity, WebSphere ND PVU counted
Benchmark scenario, not a quote. Numbers match the table above.
First deployment
- First eligible sub capacity product goes live in the cloud.
- The 90 day ILMT clock starts here, not at audit notice.
ILMT installed
- Tool discovers pods, vCPU limits, and namespaces.
- First snapshot captured before the window closes.
Reports retained
- Quarterly PVU report generated and signed off.
- Snapshots kept two years, capping IBM reach back.
The mechanic worth internalizing is that the clock runs from deployment, not from the audit letter. The IBM sub capacity licensing terms and the sub capacity terms and conditions make the 90 day install and the two year retention non negotiable.
Why does audit risk go up when IBM workloads move to cloud?
Cloud raises audit risk because the things IBM counts become elastic. Container clusters burst vCPU, high availability replicas duplicate the workload, and autoscaling spins capacity up and down faster than a quarterly snapshot can capture. Each of those is a counting argument IBM can open.
The IBM compliance team scopes three things in a cloud audit: containers and their partitioning evidence, vCPU bursts above the steady state, and high availability replicas that may or may not need their own entitlement. The defense for all three is the same. Continuous ILMT evidence beats a point in time reconstruction every time.
| Cloud audit vector | What IBM scopes | The buyer side evidence |
|---|---|---|
| Container bursts | Peak vCPU across the cluster | ILMT pod level limits, namespace caps |
| HA replicas | Standby and failover copies | Cold standby terms, replica entitlement rules |
| Autoscaling | Transient peak capacity | Quarterly high water mark, not instantaneous peaks |
Audit exposure by track on the worked estate
Benchmark scenario, not a quote. Exposure is the cost if the count moves to full capacity.
When does SaaS beat keeping the license at all?
SaaS wins when you would rather IBM run and patch the workload than count it. An IBM SaaS subscription replaces the underlying product, retires the PVU metric, and ends the ILMT obligation in one move. The support stream folds into the subscription, so there is no separate maintenance line to keep current.
The trade is term and control. SaaS anchors a 3 to 5 year commitment and there is no path back to a perpetual entitlement once the original is retired. In exchange, the audit surface for that workload drops to zero, because there is no metric left to dispute.
| Legacy product | IBM SaaS replacement | What the move retires |
|---|---|---|
| WebSphere ND | WebSphere Hybrid Edition | PVU count, ILMT reporting, separate support |
| MQ Advanced | MQ on Cloud | Broker capacity counting and snapshots |
| DataPower gateway | DataPower as a Service | Appliance and gateway entitlement tracking |
The credit mechanic applies here too. When the original entitlement is retired, IBM can recognize a trade in credit at conversion, which softens the first year subscription cost. Cloud Pak for Data follows the same logic, replacing Db2, Watson services, and Data Virtualization with a fungible subscription rather than a counted estate.
What do the three tracks cost on the same estate?
On one 20 core WebSphere estate, the three tracks separate on annual cost and on tail risk. Bring your own license carries the lowest annual support and the highest audit exposure. SaaS carries the highest annual cost and zero exposure. Cloud Pak sits between. The right answer depends on how much you trust your ILMT discipline.
| Track | Metric counted | Annual cost | Audit exposure | Three year total |
|---|---|---|---|---|
| Bring your own license | 1,400 PVU | $179,200 | $143,360 | $680,960 |
| Cloud Pak conversion | 20 VPC | $224,000 | $40,000 | $712,000 |
| IBM SaaS | Subscription | $260,000 | $0 | $780,000 |
Three year total is annual cost times three plus the one time audit exposure. Benchmark scenario, not a quote.
Annual cost by track on the worked estate
Benchmark scenario, not a quote. Numbers match the table above.
The lesson the table teaches is that the cheapest sticker is not the cheapest outcome. Bring your own license wins on annual cost only if the ILMT clock never slips. If it does, the 143,000 dollar exposure erases the saving in a single audit.
SaaS pays a premium to make that risk disappear. That is rational for a workload you do not want to manage.
Recommendation
Decide the track before you sign the cloud contract, not after the first audit letter. The migration plan and the license plan are the same plan, and the cost of getting it wrong is set on day zero.
- Run ILMT before the first production deployment. The 90 day clock is the cheapest insurance in this paper, and it is the one most estates miss.
- Convert to Cloud Pak only where you will use the bundle. A VPC exchange you do not exercise is a premium you pay for nothing, so keep stable workloads on the metric you already own.
We are glad to tie a meaningful part of the fee to delivered value.
