IBM Cloud Migration Licensing: What Every Organisation Needs to Know Before They Move

The IBM Cloud Migration Licensing Problem

IBM's software licensing model was built in an era of on-premises physical infrastructure. The core metrics — PVU (Processor Value Unit) and its successor VPC (Virtual Processor Core) — were designed to scale with physical processor capacity. When organisations migrate IBM workloads to cloud infrastructure, the licensing mechanics do not simply translate. They interact with cloud-specific variables in ways that can multiply licence obligations in ways the migration team did not anticipate.

The most common scenario we encounter is a migration project designed entirely around infrastructure cost reduction. The cloud team demonstrates significant server cost savings. The migration is approved. IBM licences are treated as an afterthought — "we already own them, so they'll just move with the workloads." Six months after the migration, IBM sends a licence verification notice. The resulting compliance exposure in virtualised cloud environments, where ILMT may not have been extended to cover cloud hosts, can exceed the entire infrastructure cost savings that justified the project.

IBM's cloud migration licensing landscape has three distinct policy frameworks that organisations must navigate simultaneously: the Eligible Public Cloud Bring Your Own Software Licence (BYOSL) policy, the ILMT and IBM License Service compliance obligations, and the PVU-to-VPC metric translation rules for products being re-platformed during the migration.

IBM's BYOSL Policy: What It Allows and What It Does Not

IBM's BYOSL policy allows organisations to use their existing perpetual or term software licences on approved public cloud infrastructure, including Amazon Web Services, Microsoft Azure, Google Cloud Platform, and IBM Cloud. This avoids the need to purchase new cloud-specific licences for software the organisation already owns. The policy was updated in August 2024 and covers IPAA and IPLA agreements held under Passport Advantage.

The BYOSL policy appears straightforward but contains several conditions that create compliance risk in practice.

Eligible Cloud Platforms Only

Not all cloud infrastructure qualifies under BYOSL. IBM designates specific eligible public cloud providers. Deploying licensed IBM software on a cloud provider that is not on IBM's eligible list — including many regional or specialised cloud platforms — is outside the scope of BYOSL and constitutes a licence violation regardless of whether the organisation holds a valid perpetual licence. Before approving any cloud platform for IBM workloads, verify that the target platform appears on IBM's current eligible cloud provider list.

Capacity Metrics Remain Applicable

BYOSL does not eliminate IBM's capacity-based metric requirements. Products licensed on PVU metrics must continue to be measured using PVU counts on cloud infrastructure, and ILMT remains the required compliance tool for sub-capacity PVU and VPC products even when deployed in cloud environments. Organisations that assume BYOSL grants a blanket permission to deploy without continued metric tracking will find themselves without the sub-capacity evidence required to defend their licence position during an IBM verification.

Licence Scope Restrictions Transfer

All restrictions that applied to the IBM software licence on-premises continue to apply in the cloud under BYOSL. Supporting Programs licensed to support a specific principal application on-premises retain that restriction when migrated to cloud infrastructure. The cloud deployment does not reset or expand the licence scope.

ILMT in Cloud Environments: The Compliance Continuity Obligation

ILMT is mandatory for sub-capacity licensing of IBM PVU and VPC products — and this obligation does not pause during or after a cloud migration. IBM requires that ILMT be deployed and generating licence reports for every host running sub-capacity IBM software, whether that host is on-premises, in a private data centre, or running on public cloud infrastructure.

The practical challenge is that ILMT was designed for network-accessible hosts with stable connectivity. Cloud environments introduce auto-scaling, ephemeral instances, network security groups, and multi-region deployments that ILMT's architecture was not designed to handle. Organisations migrating to cloud without specifically engineering ILMT coverage for cloud hosts will create gaps in sub-capacity reporting.

An ILMT reporting gap — any period where a host running IBM software is not included in ILMT's scan and reporting — means that sub-capacity entitlement cannot be claimed for that host during that period. IBM's licence auditors are trained to identify such gaps and will apply full-capacity licence calculations for the affected periods. In virtualised cloud environments where a single physical host may run dozens of virtual machines, the difference between sub-capacity and full-capacity calculation can be enormous.

For containerised IBM workloads running in Kubernetes or OpenShift environments on cloud platforms, IBM License Service replaces ILMT as the required tracking tool. Both tools must operate concurrently in hybrid estates where traditional virtual machines and containers coexist. IBM License Service tracks VPC consumption within Kubernetes clusters and is the only tool that generates licence evidence IBM will accept for Cloud Pak and containerised workload compliance.

The PVU-to-VPC Migration Decision

Many IBM cloud migrations coincide with a technology shift from traditional virtual machine deployments to containerised Kubernetes-based architectures. This technology migration intersects with IBM's transition from PVU-based to VPC-based licensing in a way that creates both cost risk and cost opportunity depending on how it is handled.

Products that were previously licensed under PVU metrics in traditional VM environments may have VPC-based equivalents available — particularly when the workload is being re-platformed onto IBM Cloud Paks or other containerised IBM products. The VPC metric calculates licence obligations based on virtual processor cores allocated to the workload, which in cloud environments where core allocation is configurable at the workload level, can be significantly lower than the PVU obligation based on the underlying physical processor count.

However, the PVU-to-VPC transition is not automatic. Organisations must formally migrate their licence entitlements from PVU to VPC through IBM Passport Advantage. Deploying containerised IBM products under the assumption that existing PVU entitlements cover VPC consumption is a compliance error. The metrics are separate; the entitlements are not interchangeable without conversion. Organisations that have undergone unplanned re-platforming without formal metric conversion have discovered the exposure during IBM licence verification exercises years after the migration completed.

The Five Licensing Actions Before Any IBM Cloud Migration

Based on our experience across 150+ IBM cloud migration licensing assessments, the following five actions — completed before the migration project begins — determine whether the licensing outcome is controlled or chaotic.

1. Inventory every IBM product scheduled for migration with its current licence metric. Create a complete list of IBM software titles, versions, licence agreements, metrics (PVU, VPC, per processor, per user, per install), and current deployment quantities. This inventory is the baseline against which cloud deployment plans are validated. IBM's account team will not provide this analysis; it must be done independently.

2. Check every target cloud platform against IBM's current BYOSL eligible provider list. Verify each target cloud provider and region before the architecture is finalised. Changing target platforms after infrastructure has been provisioned is significantly more expensive than checking BYOSL eligibility at the design stage.

3. Design ILMT coverage for cloud hosts from day one. The ILMT architecture — including server connectivity, scan scheduling, and report generation — must be extended to cover cloud hosts before any IBM software is deployed on them. An ILMT deployment that is extended to cloud after IBM software is already running has a coverage gap from the deployment date to the ILMT extension date. That gap is not recoverable from a sub-capacity compliance perspective.

4. Identify products that will be re-platformed and formally convert PVU entitlements to VPC where applicable. For any product moving from traditional VM to containerised deployment, review whether a VPC equivalent is available and whether the PVU entitlement can be formally converted. Involve IBM's account team early, before re-platforming completes, to ensure the metric conversion is documented and effective from the migration date.

5. Complete a licence position assessment before the migration and a post-migration licence review within 90 days of go-live. The pre-migration assessment establishes the baseline. The post-migration review verifies that actual cloud deployment quantities match entitlements, ILMT and IBM License Service are reporting correctly for all hosts, and no licence gaps were created during the cutover period.

What Redress Compliance Provides for IBM Cloud Migration Licensing

Redress Compliance provides independent IBM cloud migration licensing advisory on the buyer's side only. We do not have any commercial relationship with IBM, which means our analysis is not influenced by IBM's commercial objectives for the migration project. Our IBM cloud migration licensing advisory service covers pre-migration licence inventory and risk assessment, BYOSL compliance verification for target cloud platforms, ILMT architecture review and cloud extension planning, PVU-to-VPC conversion strategy, and post-migration licence position validation.

Organisations that engage us before the migration begins avoid the most common and expensive licensing errors. Organisations that engage us during an IBM licence verification triggered by a completed migration benefit from our experience in commercial resolution and licence remediation. In either scenario, independent IBM licensing expertise on the buyer's side is the single most effective cost control available for IBM cloud migration projects.