Executive Summary
The assumption that migrating off IBM infrastructure eliminates IBM licensing costs is one of the most expensive misconceptions in enterprise IT. IBM's licensing terms are designed to follow workloads wherever they run — and in cloud environments, the economics often get worse, not better.
Key Findings
- IBM licensing obligations persist in cloud environments. Perpetual licences for Db2, MQ, WebSphere, and other IBM middleware do not automatically authorise deployment on third-party cloud infrastructure. IBM's IPLA and Passport Advantage terms restrict where software can be deployed, and cloud environments introduce additional licensing complexities around virtualisation, containerisation, and multi-tenancy that do not exist on-premises.
- BYOL to cloud without explicit rights creates compliance exposure. "Bring Your Own Licence" for IBM software requires explicit authorisation. Unlike Microsoft or Oracle, IBM does not have a broad BYOL framework. Each cloud deployment scenario must be validated against the specific licence agreement, and in many cases, the existing agreement does not permit cloud deployment without amendment.
- PVU calculations in cloud environments are punitive without sub-capacity rights. IBM's PVU-based licensing in virtualised cloud environments defaults to full-capacity licensing (the entire physical host) unless sub-capacity terms are explicitly negotiated and ILMT reporting is maintained. On shared cloud infrastructure, full-capacity licensing can increase costs by 5–20x compared to on-premises sub-capacity positions.
- IBM's "Authorised Cloud Provider" programme is selective and conditional. IBM maintains a list of authorised cloud environments where sub-capacity licensing is permitted. AWS, Azure, and GCP are included — but authorisation comes with conditions around ILMT deployment, reporting frequency, and eligible instance types that must be satisfied to maintain compliance.
- Cloud-friendly licensing terms are negotiable — but only before migration. Once workloads are deployed to cloud, the enterprise has no leverage to negotiate better terms. IBM knows this. The negotiation window for cloud-friendly terms (passporting rights, BYOL authorisation, VPC metrics, container licensing) is before migration, ideally at the ELA renewal point.
Why Licensing Doesn't Stop at the Data Centre Door
Understanding why IBM licensing follows workloads to cloud requires understanding how IBM structures its software agreements and why cloud deployment creates new licensing obligations.
IBM software is licensed under the International Program License Agreement (IPLA) or, for older products, the International License Agreement for Non-Warranted Programs (ILAN). These agreements grant the enterprise the right to use the software — but they define where that software can be deployed, on what infrastructure, and under what conditions. The deployment location is not unlimited; it is contractually specified.
On-premises, the enterprise controls the physical infrastructure, can deploy ILMT for sub-capacity reporting, and has established PVU positions validated against known hardware. In cloud environments, three factors change the equation. First, the enterprise does not control the underlying physical infrastructure — the cloud provider does. Second, virtualisation is pervasive and dynamic — VMs and containers can move across physical hosts, changing PVU calculations without the enterprise's knowledge. Third, multi-tenant shared infrastructure means that IBM's full-capacity licensing default applies to the entire physical host, not just the enterprise's partition.
Cloud vs. On-Premises: Licensing Cost Impact
with full-capacity default
workloads without licence review
discovered post-migration
cloud-friendly IBM terms
The Sub-Capacity Trap in Cloud
Sub-capacity licensing is what allows enterprises to licence IBM software based on the virtual capacity allocated to the workload rather than the full physical server capacity. On-premises, this is achieved through ILMT reporting. In cloud, sub-capacity eligibility requires that the cloud provider be on IBM's "Eligible Public Cloud" list, that specific instance types are used, and that ILMT or an approved alternative is deployed and reporting at the required frequency. If any of these conditions are not met, the licensing reverts to full-capacity — and the cost implications are catastrophic.
Migrating IBM software to cloud without first validating sub-capacity eligibility, BYOL rights, and authorised cloud provider conditions is the single most common source of post-migration IBM compliance exposure. By the time the enterprise discovers the problem, the leverage to negotiate better terms has been spent.
IBM Cloud Licensing Restriction Map
Every IBM licensing restriction that applies in cloud environments, mapped by product category and restriction type.
| Restriction | On-Premises | Cloud (Default) | Cloud (Negotiated) |
|---|---|---|---|
| Capacity Licensing | Sub-capacity via ILMT | Full-capacity (entire host) | Sub-capacity with eligible cloud + ILMT |
| BYOL Rights | N/A (deployed on own infra) | Not automatically granted | Explicit BYOL clause in agreement |
| PVU Calculation | Based on allocated virtual CPUs | Based on cloud instance vCPU mapping | VPC metric or agreed PVU/vCPU ratio |
| Container Deployment | Sub-capacity with ILMT v9+ | Full node capacity default | Container licensing clause + ILMT for containers |
| Passporting | Between own data centres freely | Not permitted without clause | Explicit passporting to named cloud providers |
| Multi-Cloud | N/A | Each cloud counted separately | Unified licence pool across named clouds |
| Disaster Recovery | DR server terms apply | Cloud DR = additional deployment | Cloud DR rights with cold/warm standby terms |
Every restriction in the "Cloud (Default)" column represents either a cost increase or a compliance risk if not addressed before migration. Every item in the "Cloud (Negotiated)" column represents a term that can be secured through explicit negotiation — but only at the right point in the commercial cycle.
Planning an IBM workload migration to AWS, Azure, or GCP?
Provider-by-Provider: IBM Licensing Rules on AWS, Azure & GCP
IBM's licensing treatment varies by cloud provider. Each hyperscaler has a different relationship with IBM and different eligible instance types for sub-capacity licensing.
Amazon Web Services (AWS)
AWS is on IBM's Eligible Public Cloud list. Sub-capacity licensing is permitted on specific EC2 instance types that map to IBM's PVU table. ILMT must be deployed on AWS with reporting maintained at the standard interval. Bare-metal instances (e.g., i3.metal, m5.metal) offer the most favourable PVU positions. Shared tenancy instances require careful vCPU-to-PVU mapping validation.
Key risk: Auto-scaling and spot instances can create untracked PVU consumption that ILMT may not capture, creating compliance gaps.
Microsoft Azure
Azure is on IBM's Eligible Public Cloud list. Sub-capacity licensing is permitted on dedicated host or isolated VM instance types. ILMT deployment on Azure VMs is required. Azure's hyper-threading model means that vCPU-to-PVU mapping must account for the physical core-to-vCPU ratio, which varies by instance family. Azure Dedicated Host offers the most controlled PVU position.
Key risk: Azure Reserved Instances that change instance family at renewal can invalidate the PVU calculation that was validated at deployment time.
Google Cloud Platform (GCP)
GCP is on IBM's Eligible Public Cloud list but has fewer validated instance types than AWS or Azure. Sub-capacity licensing is permitted on Compute Engine instances with sole-tenant nodes offering the most favourable treatment. Standard shared-tenancy instances require validation against IBM's eligible instance type list, which is updated periodically and may not include the latest GCP instance families.
Key risk: GCP's custom machine types do not appear on IBM's eligible instance list and may not qualify for sub-capacity licensing.
IBM Cloud: The "Preferred" Alternative
IBM Cloud offers the most favourable licensing treatment for IBM software, including automatic sub-capacity eligibility, simplified PVU calculations, and in some cases, embedded IBM software licences within cloud service pricing. IBM will aggressively position IBM Cloud as the migration target for IBM workloads during renewal negotiations. While the licensing simplicity is genuine, the total cost of ownership must be independently validated. IBM Cloud pricing, feature set, and ecosystem maturity should be evaluated against AWS, Azure, and GCP on their merits — not solely on licensing convenience.
Do not choose your cloud provider based on IBM licensing treatment. Choose based on the cloud platform that best serves your broader infrastructure and application strategy. Then negotiate the IBM licensing terms needed to operate on your chosen platform without penalty. The licensing terms are negotiable. The cloud strategy should not be compromised by them.
BYOL Rights, Passporting & Authorised Cloud Designations
Three categories of cloud-friendly licensing rights that must be secured through negotiation. None are granted by default.
Bring Your Own Licence (BYOL)
BYOL authorises the enterprise to deploy existing IBM perpetual licences on cloud infrastructure without purchasing new cloud-specific licences. IBM's default position is that BYOL is not automatically permitted — the licence agreement must explicitly authorise deployment on third-party infrastructure. Securing BYOL rights requires an amendment to the Passport Advantage agreement or the inclusion of a BYOL clause in the ELA. The BYOL clause should specify which cloud providers are authorised, which IBM products are covered, and the licensing metric that applies in cloud (PVU, VPC, or user).
Passporting
Passporting extends BYOL to allow movement of licences between environments — from on-premises to cloud, between cloud providers, or between cloud regions. Without passporting, each deployment location requires its own licence entitlement. Passporting is particularly important for hybrid architectures where workloads move between on-premises and cloud, or for multi-cloud strategies where workloads may shift between AWS, Azure, and GCP based on cost or performance.
Authorised Cloud Provider Designation
This designation formally recognises specific cloud providers as approved deployment targets within the IBM licence agreement. It establishes the sub-capacity licensing rules, PVU calculation methodology, and ILMT reporting requirements that apply for each named provider. Without this designation, the enterprise relies on IBM's published Eligible Public Cloud list — which IBM can change unilaterally. A contractual designation locks the terms for the agreement period.
| Right | What It Grants | Why It Matters | How to Secure It |
|---|---|---|---|
| BYOL | Deploy existing licences on named cloud providers | Avoids purchasing new cloud-specific licences | ELA amendment or renewal negotiation |
| Passporting | Move licences between on-prem and named clouds | Enables hybrid and multi-cloud without double-licensing | Specific passporting clause at renewal |
| Authorised Cloud Provider | Contractual sub-capacity and PVU terms per provider | Locks terms for agreement period; IBM cannot change unilaterally | Named provider schedule in ELA |
Negotiation Framework: Securing Cloud-Friendly Terms
The negotiation framework addresses six categories of cloud licensing rights, sequenced for maximum leverage at the ELA renewal or mid-term amendment point.
Explicit BYOL Authorisation for Named Cloud Providers
Negotiate a BYOL clause that lists each cloud provider (AWS, Azure, GCP, or others) where existing IBM licences may be deployed. Specify that BYOL applies to all IBM products in the ELA, not just selected products. Avoid BYOL clauses limited to IBM Cloud only.
VPC Metric for Cloud Deployments
Negotiate Virtual Processor Core (VPC) as the licensing metric for cloud-deployed IBM software, replacing PVU. VPC aligns to cloud instance vCPU allocation, which is transparent and auditable. PVU in cloud requires a mapping table that introduces ambiguity and compliance risk.
Passporting Between On-Premises and Cloud
Negotiate explicit passporting rights that allow licences to be deployed interchangeably between on-premises data centres and named cloud providers without additional licence requirements. Essential for hybrid architectures and migration transitions where workloads move gradually.
Container Licensing Terms
Negotiate explicit container licensing that allows IBM software to run in Kubernetes/OpenShift containers with licensing based on container resource limits, not full node capacity. Without this, every IBM workload in a shared Kubernetes cluster triggers full-node PVU licensing for the entire cluster.
Disaster Recovery and High Availability Rights
Negotiate cloud DR rights that allow cold or warm standby replicas in cloud without full licensing. IBM's default treats every deployment — including passive DR — as a licensed installation requiring full PVU entitlement. Cloud DR rights should specify that passive/cold standby deployments require zero or reduced licensing.
ILMT Reporting Flexibility for Cloud
Negotiate extended ILMT reporting intervals and grace periods for cloud environments where instance types change frequently. Cloud auto-scaling, instance family changes, and reserved instance renewals can create ILMT reporting discrepancies that technically invalidate sub-capacity eligibility. A flexibility clause prevents IBM from using transient reporting gaps as compliance leverage.
Stay Updated on IBM Licensing Strategy
Get expert guidance on licensing trends, negotiation tactics, and compliance risk in your inbox.
Migration Licensing Traps
Cloud migration introduces licensing traps that do not exist in on-premises environments. Each trap is avoidable with pre-migration planning.
Trap 1: Migrating Before Negotiating Cloud Terms
Once workloads are running in cloud, the enterprise has no leverage to negotiate cloud-friendly terms. IBM knows the migration has occurred and that reversing it is costly. All cloud licensing negotiations must be completed before the first IBM workload is deployed to cloud.
Trap 2: Assuming BYOL Is Automatically Permitted
Unlike Microsoft or Oracle, IBM does not have a general BYOL policy. Each cloud deployment requires explicit authorisation in the licence agreement. Deploying IBM software to cloud under the assumption that existing licences automatically apply creates compliance exposure that IBM can enforce at any audit.
Trap 3: Ignoring Full-Capacity Default in Cloud
IBM's default licensing in any virtualised environment — including cloud — is full physical capacity. Sub-capacity licensing requires explicit eligibility (Eligible Public Cloud + ILMT + qualifying instance type). If any condition is not met, the licensing reverts to the full physical host capacity, multiplying costs by 5–20x.
Trap 4: Deploying to Non-Eligible Instance Types
IBM's Eligible Public Cloud list specifies which instance types qualify for sub-capacity licensing on each cloud provider. Deploying to instance types not on the list — including newer instance families that IBM has not yet validated — means full-capacity licensing applies. The list changes periodically; enterprises must validate before every deployment.
Trap 5: Containerising Without Container Licensing Terms
Deploying IBM software in Kubernetes or OpenShift containers without explicit container licensing provisions triggers full-node licensing for every node in the cluster where IBM software could potentially run. In shared clusters, this means licensing the entire cluster infrastructure for IBM, regardless of actual usage.
Trap 6: Treating Cloud DR as "Just Another Environment"
Cloud-based disaster recovery for IBM workloads is treated as a fully licensed deployment unless DR-specific terms are negotiated. A passive Db2 replica in AWS for DR purposes requires the same PVU licensing as the production primary. Without DR rights, the enterprise pays double for resilience.
Recommendations: 7 Priority Actions
These seven actions, executed before IBM workloads are migrated to cloud, will protect the enterprise from post-migration licensing exposure and secure the cloud-friendly terms that enable cost-effective cloud operation.
Conduct a Pre-Migration Licensing Assessment
Before any IBM workload is scheduled for cloud migration, assess the licensing implications. For each IBM product, determine: current licensing metric, current sub-capacity position, whether BYOL rights exist in the current agreement, and what the cloud licensing cost would be under current terms. This assessment is the foundation for the negotiation agenda.
Map Target Cloud Deployments to IBM's Eligible Instance Types
For each cloud provider in the migration plan, validate which instance types are on IBM's Eligible Public Cloud list. Design the cloud architecture to use eligible instances for IBM workloads. If the preferred instance type is not eligible, include this in the negotiation agenda for explicit authorisation.
Negotiate BYOL, Passporting & Cloud Provider Designations at Renewal
Include all six rights from the negotiation framework (Section 06) in the ELA renewal term sheet. Negotiate these as a package, linked to the overall renewal commitment. IBM will resist individual cloud rights; bundling them with the broader renewal commitment creates the leverage needed to secure them.
Negotiate VPC Metrics for Cloud-Deployed Products
Push for Virtual Processor Core as the licensing metric for all cloud-deployed IBM software. VPC maps directly to cloud vCPU allocations, is transparent, auditable, and eliminates the PVU mapping ambiguity that creates compliance risk. This is a structural improvement that produces ongoing savings.
Secure Explicit Container Licensing Before Containerising
If IBM workloads will run in Kubernetes or OpenShift containers, negotiate container-specific licensing terms that licence based on container resource limits, not full-node capacity. This must be done before the first containerised deployment — retroactive container licensing negotiation is significantly less favourable.
Plan ILMT Deployment for Cloud Before Migration
Ensure ILMT is deployed and reporting correctly in the cloud environment before IBM workloads arrive. Sub-capacity eligibility requires continuous ILMT reporting from the moment of deployment. A gap between workload deployment and ILMT activation creates a compliance window that IBM can exploit.
Engage Independent Advisory Before the Migration Programme Starts
Cloud migration licensing for IBM is a specialist discipline that requires knowledge of IPLA terms, Passport Advantage structures, PVU/VPC calculations, ILMT requirements, and IBM's Eligible Public Cloud programme. Independent advisory with cross-client precedent ensures that cloud-friendly terms are secured before migration creates irreversible licensing exposure.
Need help securing cloud-friendly IBM licensing terms?
Related Reading
About Redress Compliance
Redress Compliance is a 100% independent enterprise software licensing advisory firm. We work exclusively for buyers — no vendor partnerships, no reseller agreements, no referral fees. Our IBM Practice specializes in licensing compliance, audit defence, and ELA negotiation across Db2, MQ, WebSphere, POWER Systems, and modern IBM Cloud platforms. We've completed 40+ IBM cloud migration licensing assessments across AWS, Azure, and GCP.