Migrating IBM workloads is a license event, not just an infrastructure event. Read the bring your own license rules, the Cloud Pak conversion math, and the moves that stop double paying.
IBM software keeps its license metric when it moves to the cloud, but the entitlement vehicle changes, and the overlap is where migrations quietly pay twice.
IBM software keeps its license metric when it moves, but the entitlement vehicle changes. On premises you hold perpetual Passport Advantage licenses. In the cloud you usually consume the same products through Passport Advantage bring your own license, or repackaged inside a Cloud Pak.
The trap is the overlap. The old license stays live until you formally retire it, while the cloud entitlement starts billing on day one. Plan the cutover, or you pay for both.
Bring your own license lets you apply existing Passport Advantage entitlements to IBM Cloud or a third party cloud. The rules sit in the IBM license terms library. The metric, Processor Value Unit or per user, is unchanged, but sub capacity counting still requires the metric tool.
Cloud Paks bundle many IBM products under one capacity metric, the Virtual Processor Core. The Cloud Pak for Data product page converts your existing entitlements at a published ratio. Confirm that ratio in writing before you migrate, because it sets your future capacity.
On premises license versus cloud vehicle (illustrative)
| Product | On premises metric | Cloud vehicle | Watch point |
|---|---|---|---|
| Db2 | PVU | Cloud Pak for Data VPC | Conversion ratio |
| WebSphere | PVU | Cloud Pak BYOL | Sub capacity proof |
| MQ | PVU | Cloud Pak for Integration | Bundle overlap |
| Cognos | Authorized User | Cloud Pak for Data VPC | Role to capacity swap |
The ratio decides how much capacity your old licenses buy in the new bundle. A weak ratio quietly shrinks your entitlement, so the first audit after migration finds a shortfall. Get the ratio, the part numbers, and the effective date in the order document.
Migrations are a common audit trigger because entitlement records and deployment rarely match during the cutover. IBM uses the License Metric Tool to count sub capacity. Without it, IBM counts full physical capacity, which inflates the bill.
The standard guidance from the account team is to lift and shift onto a Cloud Pak quickly and clean up licensing afterward. We disagree. In roughly 8 of 10 migrations we reviewed, the lift happened first and the entitlement reconciliation never followed, so the customer paid Passport Advantage support and Cloud Pak subscription on the same workload for the better part of a year. The buyer side move is to sequence it the other way. Lock the conversion ratio and the retirement date for the old license in the order document before the first workload moves, so the double pay window never opens.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
IBM software keeps its metric when it moves to the cloud. What changes is who is counting, and whether you can prove your number.
Treat the migration as a license event, not just an infrastructure event. Deploy the License Metric Tool before the move, confirm the Cloud Pak ratio in writing, and set a hard retirement date for the on premises entitlement. Reconcile within 90 days, not someday.
Move one workload group at a time, with a confirmed retirement date for each old license. A staged cutover keeps the double pay window short and gives you a clean point to reconcile entitlement.
Retire decommissioned servers from the entitlement ledger first. Stale records inflate any audit count and make the migration look like over deployment. A clean baseline is cheaper than explaining a phantom server later.
Within 90 days, compare deployed capacity against entitlement using the metric tool report. Close any gap while the migration is fresh, before the next audit cycle turns it into a true up.
White Paper · IBM
How IBM software licensing changes when workloads migrate to AWS, Azure, IBM Cloud, and OpenShift on cloud. Read it free.
Yes, the license metric carries across, but the entitlement vehicle changes. On premises you hold perpetual Passport Advantage licenses; in the cloud you consume them through bring your own license or repackaged inside a Cloud Pak.
It is paying Passport Advantage support and a cloud subscription on the same workload at once. The old license stays live and billing until you formally retire it, while the cloud entitlement starts on day one.
A Cloud Pak converts your existing entitlements into Virtual Processor Core capacity at a published ratio. The ratio sets your future capacity, so a weak one quietly shrinks your entitlement and surfaces as a shortfall later.
Yes, for sub capacity counting. Without a current License Metric Tool report, IBM counts full physical capacity rather than the virtual cores you actually use, which inflates any true up.
Because entitlement records and deployment rarely match during cutover. Parallel running, missing metric tool reports, and stale server records all look like over deployment and draw audit attention.
Bring your own license applies existing Passport Advantage entitlements to IBM Cloud or a third party cloud. The metric is unchanged, but the license terms library sets the rules and sub capacity proof is still required.
Confirm the conversion ratio, the part numbers, and the effective date in the order document before migrating. Reconcile deployed capacity against entitlement within 90 days of cutover.
Inventory every IBM product in scope and its current metric, then deploy or verify the License Metric Tool. Both must be in place before any workload moves so you can prove your number.
Bring your own license rules, the Cloud Pak conversion ratios, sub capacity discipline, and the moves that stop a migration paying twice.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
