IBM Power Systems Licensing: Stop Paying for Cores You Don't Use

IBM Power Systems: Why Software Costs Dominate the TCO Conversation

IBM Power Systems servers — running AIX, IBM i, or Linux workloads — are present in the majority of large enterprise technology estates, typically hosting critical ERP, database, and middleware workloads that were migrated to Power architecture decades ago and have remained due to performance characteristics, application certification requirements, and the significant effort of platform migration. The hardware acquisition cost of Power servers is significant but bounded; the software licensing costs that accumulate on Power infrastructure are frequently uncapped and represent the dominant total cost of ownership element over a 5–7 year server lifecycle.

IBM Power software licensing operates on a fundamentally different model from most enterprise software: licences are tied to activated processor cores rather than named users, concurrent sessions, or data volumes. Each activated core on a Power server requires appropriate IBM software licences for the operating system (AIX or IBM i) and all IBM middleware and database products deployed on that hardware. As organisations deploy larger Power servers to consolidate workloads, the activated core count increases and IBM's software charges scale proportionately — often outpacing the hardware consolidation savings that motivated the infrastructure investment. Our IBM advisory team regularly identifies Power software licensing overspend of 20–35% against what optimised architectures could achieve. For broader IBM cost context, visit our IBM Knowledge Hub.

Activated Processors vs Physical Cores: How IBM Counts and Charges

IBM Power servers support granular processor activation — not all physical cores in a server need to be activated for software licensing purposes. An IBM Power10 server with 16 physical cores can be configured with only 8 activated cores, with IBM software licences purchased only for those 8. This provides a legitimate mechanism to right-size software costs to actual processing requirements. The licensing risk arises when: physical core activations are increased to handle peak workloads without a corresponding licence review; virtualisation (PowerVM/LPAR) is used to allocate more virtual CPU capacity than licenced physical core equivalents; or when third-party software running on the Power server (Oracle Database, for example) has its own core-based licensing rules that interact with IBM's core definitions differently.

For AIX environments, IBM's IPLA licences for AIX itself (AIX subscription) and IBM middleware (IBM MQ, WebSphere Application Server, Db2 for LUW) are priced against Virtual Processor Cores (VPCs) — the number of virtual cores allocated to the LPAR running the software, subject to sub-capacity measurement rules. The sub-capacity licensing interaction is direct: if a Power LPAR is properly configured and ILMT is deployed, IBM software can be licenced against the LPAR's allocated virtual core count rather than the physical server's activated core count. For large Power environments with many LPARs, this sub-capacity optimisation — covered in detail in our ILMT compliance guide — can represent 30–50% reductions in IBM middleware licensing costs. The interaction with mainframe MSU costs matters for organisations running both Z and Power infrastructure — IBM negotiates these as a combined estate in ELA discussions.

AIX Subscription vs Perpetual: The Licensing Model Decision

IBM AIX is available under two commercial models: AIX subscription (annual recurring fee per VPC, includes updates, fixes, and technology refreshes) and perpetual licence with optional Software Subscription and Support (S&S). For organisations running large, stable AIX environments with no near-term plans to migrate to Linux or alternative platforms, the perpetual plus S&S model typically delivers better 5-year economics than annual subscription — particularly where S&S can be negotiated at discounted rates in an ELA. IBM's standard commercial motion pushes all customers toward AIX subscription, which generates predictable recurring revenue; the perpetual model requires active pushback and is most effectively negotiated during a broader IBM ELA renewal where total spend commitment gives leverage.

The IBM i licensing situation is more constrained. IBM i (the OS/400 successor running on Power for legacy AS/400 applications) is licenced per processor group and user tier — a complex matrix that IBM has not significantly simplified. IBM i user licence escalation (growing user counts triggering tier-up charges) is one of the most common IBM billing disputes in our client base, and proactive user licence auditing before IBM's own measurement is essential for cost control. Organisations running mixed AIX and IBM i environments on the same Power hardware face LPAR partition management requirements that are distinct for each OS — a compliance complexity that IBM's account team frequently uses to justify broader ELA structures. For organisations also deploying IBM watsonx workloads on Power infrastructure, the IPLA entitlement landscape becomes further complex — specialist advisory support before any new commitment is strongly recommended.

LPAR Compliance and Virtualisation: The Audit Risk Profile

IBM Power's virtualisation technology (PowerVM) allows a single physical server to host multiple independent LPARs, each running separate workloads under potentially different IBM software licences. LPAR configuration changes — increasing virtual CPU allocations to handle performance requirements, adding new LPARs for development or test environments, or migrating workloads between physical servers — can inadvertently create licensing compliance gaps that IBM identifies in audit processes.

Three specific compliance risks are most commonly found in Power environments. Dynamic LPAR capping — where a workload's LPAR is allowed to dynamically consume more VPCs than the licenced entitlement during processing peaks — is technically straightforward to misconfigure and creates a compliance exposure that IBM's ILMT data will capture. Shared processor pool allocation — where multiple LPARs draw from a shared pool of activated cores — requires careful mathematical analysis to verify that the total pool capacity remains within the sum of licenced entitlements. Cross-server LPAR migration (live migration of workloads from one physical Power server to another) requires the destination server to have equivalent software licences to the source — a requirement that is commonly missed during infrastructure optimisation exercises. Organisations that have not conducted a systematic Power LPAR compliance review in the past 18 months should treat it as a priority before IBM initiates its own review. Our ILMT sub-capacity compliance guide covers the technical requirements in detail, and booking a call with our IBM advisory team is the most efficient way to scope a compliance review.