IBM Power Systems Licensing Guide: Complete Enterprise Advisory

The IBM Power Systems Licensing Landscape

IBM Power Systems — the successor to the AS/400, iSeries, and pSeries hardware families — runs three distinct operating platforms with separate licensing models: AIX (IBM's Unix), IBM i (the integrated application platform descended from OS/400), and Linux on Power. Each carries different licence structures, maintenance agreements, and compliance frameworks.

The complexity of Power licensing is compounded by the middleware layer. IBM software products running on top of these operating systems — WebSphere, Db2, MQ, CICS, and dozens of others — carry their own Processor Value Unit (PVU) or Virtual Processor Core (VPC) based licences that interact with the physical server architecture in ways that create both cost-saving opportunities and significant compliance risk. Understanding both layers — the platform layer and the middleware layer — is essential for any enterprise managing Power infrastructure.

AIX Licensing on Power Systems

Software Maintenance Agreement (SWMA)

IBM AIX is licensed through a Software Maintenance Agreement (SWMA) tied to the hardware serial number of the specific Power server where it runs. This hardware-binding model is a distinctive characteristic of Power platform licensing that differs significantly from commodity x86 operating system licensing. The SWMA provides the AIX operating system licence, version upgrades, and technical support. There are no separate concurrent user licences or CPU-count limits on the AIX operating system itself.

The serial-number binding of AIX licences has important implications for hardware migrations. When an organisation upgrades from a POWER9 to a POWER10 server, the AIX SWMA does not automatically transfer — a new licence or transfer transaction may be required. IBM allows licence transfers within the same "P class" system tier, but cross-tier transfers require separate transactions. Missing this step during a hardware refresh creates an unlicensed deployment that IBM can identify through support call records or hardware registration data.

AIX Subscription Licensing

IBM has introduced subscription licensing options for AIX, available in one-year and three-year terms, covering AIX Standard Edition, AIX Enterprise Edition, and AIX Enterprise Cloud Edition. Subscription licences are particularly relevant for organisations deploying AIX on IBM Power Virtual Server in IBM Cloud, where perpetual serial-number-bound licences are not applicable. The AIX Enterprise Cloud Edition includes features specific to hybrid cloud deployments and may be required for certain AIX on cloud configurations.

IBM i Licensing on Power Systems

The IBM i Licensing Model

IBM i (formerly known as OS/400 and i5/OS) is licensed per system based on the hardware serial number, similar to AIX, with an important additional dimension: IBM i licences are also tied to the software tier of the Power server. The software tier classification determines the base licence cost and dictates what IBM i capabilities and applications are included.

The IBM i software tier system assigns Power servers to categories (P05, P10, P20, P30) based on processing capacity. P05 and P10 tier systems are smaller configurations typically used by mid-market organisations; P20 and P30 are larger enterprise configurations. Licence costs scale with tier — moving a workload from a P10 to a P20 server increases IBM i licence cost significantly, a fact that is often overlooked in hardware refresh planning discussions.

IBM i Subscription Mandate for POWER10

A significant change announced by IBM on 7 May 2024 is that customers purchasing specific POWER10-based P05 and P10 software tier machines must now adopt subscription-based IBM i licensing. IBM withdrew perpetual OS licences for these tiers from that date. The subscription model covers the core licence, users, zero-dollar Licensed Program Products (LPPs), and software maintenance as an integrated package.

For enterprises managing IBM i deployments on smaller Power10 systems, this subscription mandate represents a shift from capitalising software licence costs to treating them as operating expenditure. Budget planning, procurement cycles, and vendor contract management all need adjustment to account for this change.

Linux on Power Licensing

IBM Power Systems support major Linux distributions including Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server on both bare-metal and LPAR configurations. Linux on Power licences are typically procured as Red Hat or SUSE subscriptions rather than IBM licences — the operating system cost is a subscription fee paid to the Linux distribution vendor, while IBM middleware running on Linux on Power carries IBM PVU or VPC licences.

A compliance risk specific to Linux on Power environments is the interaction between Linux distribution subscriptions (often managed by a separate team) and IBM middleware licences (managed by the IBM software asset management function). When Linux LPAR configurations change — adding cores, splitting LPARs, consolidating workloads — both the Linux distribution subscription scope and the IBM middleware licence calculations may be affected. Organisations that manage these two dimensions independently often discover mismatches during licence reviews.

PVU Licensing: The Core Middleware Metric

How PVU Licensing Works

Processor Value Units (PVUs) are IBM's primary metric for licensing distributed middleware products. A PVU is a weighted unit that assigns different values to different processor types based on their relative processing capability. IBM publishes PVU-per-core ratings for every major processor type — IBM Power processors, Intel Xeon, AMD, and others — in its Passport Advantage PVU licensing tables, updated periodically as new processor generations are released.

For IBM Power Systems specifically, PVU-per-core ratings are higher than for equivalent x86 processors, reflecting Power's historically superior single-thread performance. A current IBM POWER10 core carries 120 PVUs per core. Compare this to a typical Intel Xeon core at 70 PVUs per core. An IBM Db2 deployment on a 16-core POWER10 server requires 1,920 PVUs under full-capacity licensing — versus 1,120 PVUs for the same physical core count on x86.

Full Capacity vs Sub-Capacity: The Most Important Choice

IBM PVU licensing offers two modes: full capacity and sub-capacity (virtualisation capacity). Full capacity requires licensing all physical processor cores on the server where the software is installed, regardless of how many cores are actually allocated to the LPAR running the software. Sub-capacity allows licensing only the processor cores assigned to the virtualised partition where the software runs.

The financial difference between these two modes is dramatic. For a 32-core POWER10 server running a 4-core LPAR with IBM Db2, full-capacity licensing requires 3,840 PVUs while sub-capacity licensing requires only 480 PVUs — a ratio of 8:1 in this example. In production environments where multiple LPARs share a large physical server, the ratio can reach 10:1 to 20:1. This is why sub-capacity eligibility and the correct configuration of ILMT are among the highest-value topics in IBM licence management.

ILMT: The Sub-Capacity Gateway Tool

What ILMT Does and Why It Is Mandatory

IBM License Metric Tool (ILMT) is IBM's designated tool for measuring sub-capacity software usage in virtualised environments. For any IBM software product licensed under PVU sub-capacity rules, ILMT (or an IBM-approved equivalent such as HCL BigFix Inventory) must be deployed, configured, and actively measuring software deployments. This is not optional guidance — it is a contractual requirement under IBM's Passport Advantage sub-capacity terms.

ILMT works by deploying agents on every virtual machine or LPAR where IBM sub-capacity eligible software runs. These agents discover installed IBM software, map it to the relevant PVU or RVU metric, and report the maximum concurrent resource usage during each quarter. ILMT generates audit snapshot reports at quarter-end that serve as the evidentiary basis for sub-capacity licence calculations.

ILMT Requirements for IBM Power Systems

On IBM Power Systems running AIX, ILMT agents must be installed on every LPAR where IBM sub-capacity eligible middleware runs. The ILMT software catalogue must be current — IBM updates the catalogue to include new product versions and correct recognition rules, and an outdated catalogue leads to unrecognised deployments that create compliance gaps. ILMT audit snapshots must be retained for at least two years — this retention requirement is contractual, not merely advisory.

A specific technical requirement on Power Systems is that ILMT must correctly account for processor pool configurations. In dynamic LPAR environments where LPARs share a processor pool and can draw additional cores beyond their allocated minimum, ILMT must track the peak concurrent processor usage across the pool, not just the configured allocation. Enterprises that configure dynamic processor sharing to improve system utilisation without understanding the sub-capacity accounting implications regularly find their peak ILMT readings higher than expected — and therefore their licence obligations higher than their procurement planning assumed.

IBM License Service for Containerised Deployments

As organisations move IBM middleware workloads into containerised environments — Kubernetes, OpenShift, IBM Cloud Paks — IBM License Service replaces ILMT as the measurement tool. IBM License Service is a Kubernetes operator that measures IBM software container deployments and reports VPC (Virtual Processor Core) usage, which is the metric applicable to containerised IBM products.

The transition from ILMT-measured PVU licensing to IBM License Service-measured VPC licensing creates a parallel measurement requirement for enterprises with hybrid environments — some IBM workloads still running in traditional LPARs (ILMT, PVU) and others in containers (IBM License Service, VPC). Both measurement systems must be operational and generating accurate reports. The metrics are different and not directly comparable without formal IBM conversion transactions.

The PVU to VPC Transition: Compliance Gaps and Opportunities

What Changed and Why

IBM's shift from PVU to VPC as the primary licensing metric for Cloud Pak and containerised products reflects the architectural difference between traditional physical/virtual environments and containerised deployments. PVUs carry a hardware-weighting component — a Power core is worth more PVUs than an Intel core. VPCs are metric-neutral: one VPC equals one virtual CPU core, regardless of the underlying physical processor type or architecture.

For IBM Power Systems users, the PVU to VPC transition creates a potential cost change. If your Power server carries a 120-PVU-per-core rating and you convert to VPC licensing, the effective metric change needs careful modelling. IBM has published conversion guidance — approximately 1 PVU = 1 VPC for conversion purposes — but the specific conversion ratio depends on the product, the deployment context, and the terms negotiated in your Passport Advantage agreement.

Compliance Gaps During Transition

The most common compliance gap during the PVU to VPC transition occurs when organisations migrate IBM middleware from traditional LPARs to containerised environments without formally executing the licence conversion through IBM's Passport Advantage transaction system. Technically, the old PVU-based entitlements on the LPAR side do not automatically cover VPC usage on the container side — they are different metrics under different programme terms. IBM can assert that both sides require separate licence coverage during any overlap period.

Managing this transition requires coordination between the infrastructure team (handling the technical migration), the software asset management team (tracking licence entitlements and metrics), and IBM account management (executing the formal conversion transactions). In large enterprises, these teams often operate independently with limited cross-functional coordination, creating exactly the kind of gap IBM identifies during audits.

POWER10 Software Tiers and Cost Implications

The Software Tier Model

IBM POWER10 servers are classified into software tiers based on their processing capacity configuration. The tier classifications — P05, P10, P20, P30 — directly affect the licensing cost for IBM i and tier-priced IBM software products. The tier system exists to align licence cost with the effective processing capacity of the system, but in practice it creates step-change cost increases when organisations move to higher-tier hardware.

The current POWER10 tier assignments place scale-out systems such as the S1022 in P10 or P20 tiers depending on core count, while enterprise systems such as the E1080 are in the P30 tier. A POWER9-to-POWER10 upgrade that moves an organisation from a P20-tier to a P30-tier system can increase IBM i licence costs by a substantial percentage — a cost that is rarely made explicit in hardware sales discussions.

Subscription Mandate Impact

IBM's May 2024 withdrawal of perpetual IBM i licences for POWER10 P05 and P10 tier systems means that new deployments on these systems are subscription-only. For organisations used to perpetual licensing, this creates both budget structure changes (operating expenditure rather than capital) and contract management implications (IBM subscription licences under the 2023 IPAA cannot be cancelled before term end).

The subscription mandate for IBM i on smaller POWER10 systems mirrors IBM's broader strategy of shifting its software portfolio away from perpetual licences — a trend visible across IBM middleware, IBM Cloud Paks, and now IBM i. Enterprises planning multi-year Power infrastructure programmes should model licensing costs under subscription terms across their full hardware refresh cycle.

IBM Power Systems Licence Negotiation Levers

Hardware Refresh as a Negotiation Moment

Hardware refresh cycles are the primary moment of leverage for IBM Power software licence negotiations. When an organisation commits to new POWER10 hardware, IBM is motivated to retain the existing software footprint and expand it if possible. This motivation can be used to negotiate better software pricing, extended maintenance terms, or technology migration credits for organisations moving workloads between Power generations or platforms.

IBM's fiscal year ends on 31 December, which means fourth-quarter negotiations — particularly in November and December — carry additional pricing flexibility as IBM works to close the fiscal year with strong software revenue. Planning hardware refresh or ELA renewals to coincide with IBM's fiscal year-end is a well-established negotiation tactic that typically yields additional concessions.

ELA and Passport Advantage Negotiation

Enterprise License Agreements (ELAs) covering IBM Power middleware can bundle multiple products at a blended discount. For organisations running a broad IBM middleware stack on Power — Db2, WebSphere, MQ, CICS, Tivoli — an ELA can simplify procurement, provide licence flexibility for workload changes, and deliver total spend reductions compared to product-by-product renewal under Passport Advantage. However, ELAs typically require multi-year commitments and lock organisations into IBM's product roadmap for the ELA term.

Negotiating sub-capacity PVU quantities into an ELA requires accurate ILMT data as the baseline. IBM will attempt to anchor ELA quantities on the highest PVU reading from recent ILMT reports. Preparing clean, accurate ILMT data before ELA negotiations — and reconciling it against your actual deployment plans — gives you a defensible counter to IBM's anchoring and creates space to negotiate both the quantity baseline and the discount structure.

Common IBM Power Audit Scenarios and How to Handle Them

Scenario 1: Missing ILMT Coverage on Newly Created LPARs

This is the most common Power-specific audit finding. An organisation creates new LPARs for a project deployment and deploys IBM middleware, but the ILMT agent is not added to the new LPAR. ILMT continues generating clean reports that accurately reflect the old environment but miss the new deployment. IBM discovers the gap through support registration data or automated telemetry. The remediation requires back-licensing from the date the LPAR was created, typically at full-capacity rates for the uncovered period.

Prevention requires integrating ILMT agent deployment into the standard LPAR provisioning workflow. Every LPAR creation should trigger an automatic ILMT agent deployment as part of the provisioning checklist — not as a separate post-deployment activity that depends on individual team awareness.

Scenario 2: Dynamic Processor Pool Over-Count

An organisation configures LPARs with dynamic processor allocation to improve server utilisation. ILMT correctly measures peak processor usage per quarter. At quarter end, the ILMT report shows peak usage higher than the minimum LPAR core allocation because workloads temporarily drew additional cores from the shared pool. The organisation's licence inventory was sized on the minimum allocation, not the peak usage — creating a licence deficit that ILMT accurately reported but the organisation did not act on.

Resolution requires either right-sizing licences to cover peak usage (increasing licence cost), implementing processor pool hard limits to cap LPAR resource usage at the licensed amount, or negotiating a retroactive licence adjustment with IBM based on the business context of the dynamic allocation.

Scenario 3: PVU-to-VPC Transition Gap

An organisation migrates an IBM Db2 deployment from an AIX LPAR (PVU-licensed, ILMT-tracked) to a containerised environment on OpenShift (VPC-licensed, IBM License Service-tracked). The migration takes four months. During this period, the old LPAR continues running as a fallback. The PVU entitlements cover the LPAR side, but no VPC entitlements have been purchased for the container side because the formal conversion transaction has not been executed. IBM can assert that both deployments require separate licence coverage for the overlap period.

Prevention requires treating every platform migration as a licence conversion event. Engage IBM's licence management team at the start of the migration project, not at the end, and agree on the conversion terms and effective date before the dual-running period begins.

How Redress Compliance Supports IBM Power Licensing

Redress Compliance has been advising enterprise organisations on IBM Power Systems licensing for over 20 years, working exclusively on the buyer side. Our IBM Power practice provides ILMT health checks and sub-capacity compliance reviews, PVU to VPC transition planning and licence conversion management, POWER10 upgrade licensing modelling and cost impact analysis, ELA and Passport Advantage negotiation support for Power middleware estates, and IBM audit defence for Power-related audit notices including LPAR sub-capacity and metric disputes.

Our approach is always independent and always buyer-side. We work with your internal teams to build a clear picture of your compliance position, identify and remediate gaps before IBM does, and create the commercial leverage needed for fair licence negotiations. If you are planning a POWER10 upgrade, navigating a PVU-to-VPC transition, or dealing with an IBM audit notice related to Power Systems, contact our IBM practice team for a confidential initial consultation.