Executive Summary
The assumption that cloud migration eliminates IBM licensing obligations is the single most expensive misconception in enterprise IT. IBM's licensing policies do not evaporate when you move to AWS, Azure, or GCP. They follow you – and in many cloud environments, they become more restrictive, more expensive, and harder to manage than on-premises.
IBM's Cloud Licensing Rules
IBM's licensing policies for cloud environments are documented in IBM's "Eligible Public Cloud BYOL" policy and the Passport Advantage agreement. The rules are complex, provider-specific, and frequently updated.
The Eligible Public Cloud framework. IBM permits customers to deploy IBM software on "Eligible Public Cloud" providers using a BYOL (Bring Your Own Licence) model. Under this framework, you apply your existing on-premises IBM licences to cloud VMs. However, the counting rules in cloud differ from on-premises: sub-capacity via ILMT is replaced by VPC counting rules specific to each cloud provider's virtualisation technology.
VPC counting in cloud. In eligible public cloud environments, IBM counts Virtual Processor Cores (VPCs) based on the vCPUs allocated to the VM or container. The conversion is typically 1 vCPU = 1 VPC for most cloud instance types. However, IBM applies a minimum of 1 VPC per product deployment, and certain instance types (bare metal, dedicated hosts, GPU instances) carry different counting rules that can significantly increase the licence requirement.
Full-capacity vs sub-capacity in cloud. On-premises, sub-capacity licensing (via ILMT) allows you to license only the virtual partition where IBM software runs. In cloud, the equivalent "sub-capacity" benefit requires deploying on an eligible provider, using supported VM types, and maintaining manual quarterly usage records. If any of these conditions are not met, IBM can demand full-capacity licensing of the physical host – which in cloud is typically a shared multi-tenant server with 64–128 cores.
Cloud Provider Licensing Comparison
IBM's licensing rules vary by cloud provider. Each provider has different virtualisation technology, instance types, and IBM eligibility conditions.
| Dimension | AWS | Azure | Google Cloud | IBM Cloud |
|---|---|---|---|---|
| Eligible for BYOL? | Yes (most instance types) | Yes (most instance types) | Yes (most instance types) | Yes (fully supported) |
| VPC Counting | 1 vCPU = 1 VPC | 1 vCPU = 1 VPC | 1 vCPU = 1 VPC | 1 vCPU = 1 VPC (favourable terms) |
| Sub-Capacity Equivalent | VM-level counting with manual reporting | VM-level counting with manual reporting | VM-level counting with manual reporting | Full sub-capacity via ILMT equivalent |
| Container Support | Worker node counting (EKS) | Worker node counting (AKS) | Worker node counting (GKE) | Container-level with OpenShift |
| Bare Metal | Full physical core licensing | Full physical core licensing | Full physical core licensing | Sub-capacity available |
| ILMT Supported? | No | No | No | Yes |
| Reporting Requirement | Quarterly manual self-report | Quarterly manual self-report | Quarterly manual self-report | Automated via IBM tools |
| Licence Cost vs On-Premises | Often higher | Often higher | Often higher | Comparable or lower |
The 8 Migration Licensing Traps
These eight traps consistently catch organisations migrating IBM workloads to public cloud. Each is avoidable with pre-migration licensing assessment.
1. The Sub-Capacity Assumption
Organisations assume cloud VM-level licensing is equivalent to on-premises sub-capacity. It is not. Cloud sub-capacity requires eligible provider, eligible VM type, and quarterly manual reporting. Missing any condition triggers full-capacity licensing of the entire physical host.
2. The Container Counting Explosion
IBM products in Kubernetes containers are licensed based on worker node capacity, not container limits. A Db2 container requesting 4 vCPUs on a 32-vCPU worker node requires 32 VPCs of licensing. In auto-scaling clusters, the licence requirement fluctuates with node count – and IBM counts the peak.
3. The Auto-Scaling Licence Surge
Cloud auto-scaling increases VM count (and therefore licence count) automatically during peak demand. IBM licences are counted at peak deployment – not average. An environment that scales from 4 VMs to 16 VMs during peaks requires licensing for 16 VMs, even if the peak lasts 2 hours per month.
4. The ILMT Gap
ILMT is not supported in AWS, Azure, or GCP. Without ILMT, you cannot claim sub-capacity for PVU-licensed products in cloud. You must use VPC counting rules instead – and maintain manual quarterly reports. Most organisations do not realise this until IBM asks for the reports during an audit.
5. The DR/Failover Double-Count
Disaster recovery VMs in cloud that are "warm" or "hot" (running but not serving traffic) still require IBM licences. IBM does not distinguish between production and DR instances for licensing purposes. A 50-VM production environment with a 50-VM DR standby requires 100 VMs of licences.
6. The Instance Type Ineligibility
Not all cloud instance types qualify for IBM's Eligible Public Cloud BYOL. Bare metal instances, GPU instances, and some dedicated host configurations carry different counting rules. Deploying on a non-eligible instance type without realising it triggers full-capacity licensing.
7. The Reporting Obligation
IBM requires quarterly self-reporting of cloud deployments: VM instance types, vCPU counts, IBM software installed, and peak deployment periods. Failure to maintain these records – or providing incomplete records during audit – gives IBM grounds to apply full-capacity counting retroactively.
8. The S&S Continuation Requirement
BYOL in cloud requires active Subscription & Support (S&S) on the underlying licences. If S&S has lapsed on the licences you are bringing to cloud, those licences are not eligible for BYOL. You must either reinstate S&S (with back-payment penalties) or purchase new cloud-native licences.
The BYOL Reality
IBM's BYOL model for cloud appears to offer a cost-efficient migration path. The reality is more nuanced.
What BYOL permits. You apply existing on-premises PVU or VPC licences to cloud VMs. The licences must have active S&S, the cloud provider must be on IBM's Eligible Public Cloud list, and the VM instance type must qualify for sub-capacity-equivalent counting. If all conditions are met, you can run IBM software in cloud using your existing licences.
What BYOL does not eliminate. BYOL does not eliminate the licence obligation – it transfers it from on-premises to cloud. You still need enough licences to cover the cloud deployment. Because cloud VPC counting rules often produce a higher licence count than on-premises sub-capacity counting, BYOL frequently requires purchasing additional licences to cover the cloud environment. BYOL also does not eliminate S&S costs, which continue at 20% of the licence value annually.
| Scenario | On-Premises (Sub-Capacity) | Cloud (BYOL) | Licence Cost Impact |
|---|---|---|---|
| Db2 on 4-vCPU VM | 4 VPCs (with ILMT) | 4 VPCs (eligible provider) | Equivalent |
| Db2 in Kubernetes (4-vCPU request, 32-vCPU node) | 4 VPCs (with ILMT, capped LPAR) | 32 VPCs (worker node capacity) | 8x increase |
| WebSphere on auto-scaling group (4–16 VMs) | N/A (fixed capacity on-prem) | 16 VMs × vCPUs at peak | 4x vs baseline |
| MQ on bare metal cloud instance | Partition-level sub-capacity | Full physical core licensing | 2–4x increase |
| Any product, ineligible instance type | Sub-capacity via ILMT | Full host capacity (128+ cores) | 10–30x increase |
ILMT & Sub-Capacity in Cloud
The absence of ILMT in public cloud is the single most consequential licensing difference between on-premises and cloud IBM deployments.
On-premises: ILMT provides automated sub-capacity tracking. ILMT continuously monitors your virtual environment, tracks vCPU allocations, detects IBM software installations, and generates the quarterly reports IBM requires to validate sub-capacity licensing. ILMT is automated, auditable, and accepted by IBM as definitive sub-capacity evidence.
Cloud: manual quarterly self-reporting replaces ILMT. In AWS, Azure, and GCP, you must manually track and report your IBM deployments quarterly. This includes documenting every VM running IBM software, the instance type and vCPU count, the IBM products installed, and the peak deployment during the quarter. This manual process is error-prone, resource-intensive, and creates audit exposure when records are incomplete.
The audit implication. If IBM audits your cloud deployment and your quarterly self-reports are incomplete, inconsistent, or missing, IBM can demand full-capacity licensing retroactively. The burden of proof is on you to demonstrate sub-capacity eligibility – and without ILMT-quality data, that proof is difficult to provide.
Migration Licensing Strategy
Eight strategic actions that ensure your cloud migration does not create IBM licensing exposure.
1. Pre-Migration Licensing Assessment
Before migrating any IBM workload, model the licence requirement under IBM's cloud counting rules. Compare the cloud VPC count against your current entitlement. Identify gaps before migration – when you can plan procurement or restructure the architecture – not after.
2. Select Eligible Instance Types
Verify that your target cloud instance types are on IBM's Eligible Public Cloud list. Avoid bare metal, GPU, and dedicated host instances unless the licensing implications are explicitly modelled. The instance type selection directly determines your licence count.
3. Isolate IBM Workloads in Containers
In Kubernetes environments, isolate IBM software on dedicated worker nodes with minimal vCPU capacity rather than deploying alongside non-IBM workloads on large nodes. A dedicated 8-vCPU node for Db2 requires 8 VPCs; a shared 64-vCPU node requires 64 VPCs.
4. Cap Auto-Scaling for IBM Workloads
Set maximum auto-scaling limits on VM groups running IBM software. IBM licences at peak – uncapped auto-scaling creates uncapped licence liability. Define auto-scaling ceilings that align with your licensed capacity.
5. Implement Automated Cloud Reporting
Deploy automated inventory and reporting tools before migration. Configure quarterly reports that document every VM, instance type, vCPU count, and IBM product for every cloud account running IBM software. Automated reporting creates audit-defensible records.
6. Evaluate IBM Cloud for IBM Workloads
IBM's licensing terms are most favourable on IBM Cloud: ILMT support, container-level counting, and automated reporting. For IBM-heavy workloads, the licensing cost savings on IBM Cloud can offset the operational preference for AWS/Azure/GCP.
7. Negotiate Cloud-Specific Terms with IBM
Before migrating, negotiate explicit cloud deployment terms with IBM: confirmed instance type eligibility, agreed VPC counting methodology, container counting rules for your specific Kubernetes platform, and reporting format acceptance.
8. Consider Replacing IBM Products Pre-Migration
For IBM products with cloud-native alternatives (Db2 → PostgreSQL/Aurora, MQ → Amazon MQ/Azure Service Bus, WebSphere → containers with open-source middleware), replacing the IBM product before migration eliminates the licensing trap entirely. Evaluate replacement where the migration effort is comparable.
Recommendations
Seven priority actions for organisations migrating IBM workloads to public cloud.
- Model Cloud Licensing Before You Migrate: Do not migrate any IBM workload to cloud without first modelling the VPC requirement under IBM's cloud counting rules. The on-premises licence count is not your cloud licence count. Discovering gaps post-migration costs 2–5x more than proactive planning.
- Isolate IBM Workloads on Dedicated Resources: In container environments, deploy IBM products on dedicated worker nodes with minimal vCPU counts. In VM environments, right-size instances to the IBM workload's actual requirements. Over-provisioned cloud resources create over-provisioned licence obligations.
- Implement Cloud Reporting from Day One: Deploy automated IBM software inventory and quarterly reporting before the first IBM workload reaches cloud. Do not rely on manual tracking – it is error-prone and audit-vulnerable. Automated reporting is your ILMT replacement.
- Evaluate Product Replacement Before BYOL: For each IBM product targeted for cloud migration, assess whether replacing it with a cloud-native alternative is more cost-effective than BYOL. PostgreSQL for Db2, Amazon MQ for IBM MQ, and containerised open-source middleware for WebSphere are mature alternatives that eliminate IBM licensing entirely.
- Negotiate Cloud Terms with IBM Pre-Migration: Get written IBM confirmation of the VPC counting rules, eligible instance types, container methodology, and reporting requirements that will apply to your cloud deployment. Verbal assurances from IBM's sales team are not contractually binding.
- Cap Auto-Scaling and DR Environments: IBM licences at peak deployment. Uncapped auto-scaling and always-on DR create uncapped licence liability. Define scaling ceilings and evaluate cold DR (not requiring IBM licences) vs warm DR (requiring full licensing).
- Engage Independent Advisory: IBM cloud licensing is a specialised discipline at the intersection of IBM's licensing policies, cloud architecture, and contract law. Independent advisory with current IBM cloud licensing expertise ensures your migration does not create compliance gaps that cost more than the migration saved.
Need a case study on IBM cloud migration licensing?
See how a financial services firm avoided $2.1M in licensing exposure through pre-migration assessment.
Subscribe to Our Newsletter
Get the latest on IBM licensing, cloud compliance, and enterprise software advisory delivered to your inbox.
Ready to audit your IBM cloud licensing?
Our team conducts 40+ IBM cloud migration licensing assessments annually. Get a compliance plan in 48 hours.