IBM ILMT Compliance: Sub-Capacity Licensing and Audit Requirements

What Is IBM ILMT and Why Does It Matter?

IBM License Metric Tool (ILMT) is IBM's proprietary software asset management tool, available free of charge to IBM customers. Its primary function is to discover, inventory, and report on IBM software deployments across an enterprise's server estate — specifically for products licensed under the Processor Value Unit (PVU) or Virtual Processor Core (VPC) sub-capacity metric.

The sub-capacity licensing model allows enterprises to licence IBM software based on the processor capacity actually assigned to the virtual machine or container running the software, rather than the full physical server capacity. This distinction is critical: a server with 32 cores running an IBM Db2 VM with only 4 cores assigned would be licenced at 4 cores (sub-capacity) rather than 32 cores (full capacity) if ILMT is properly deployed.

IBM introduced ILMT as the mandatory condition for sub-capacity eligibility. The tool generates the authoritative licence consumption reports that IBM uses during licence audits to verify whether a customer has been appropriately licenced at sub-capacity rates. Without ILMT — or with a non-compliant ILMT deployment — IBM auditors default to full-capacity calculation, applying PVU or VPC rates to the entire physical server capacity. This is not a negotiating position IBM typically softens during an audit: the absence of ILMT compliance creates legal liability that IBM actively pursues.

IBM ILMT Compliance Requirements: The Complete Checklist

IBM's ILMT compliance requirements are defined in the IBM International Passport Advantage Agreement and the associated Sub-Capacity Licensing Addendum. Meeting all requirements is binary — partial compliance does not qualify an enterprise for sub-capacity pricing. The requirements fall into five categories:

1. Deployment Scope

ILMT must be deployed on all servers and virtual machines in your IT environment that run IBM sub-capacity-eligible software. IBM's interpretation is broad: if a physical server or cloud instance could run IBM software — even if it doesn't currently — IBM auditors may argue that all systems should be under ILMT management. Best practice is to deploy ILMT across your entire managed server estate, not just systems you believe are running IBM software.

2. ILMT Version Requirements

IBM requires that customers run a supported, current version of ILMT. IBM publishes a list of supported ILMT versions and retires older versions on a rolling basis. Running an out-of-support ILMT version — even if the tool is otherwise functional — is treated as ILMT non-compliance by IBM auditors. Version upgrade cadence is something many ITAM teams fail to track, and discovering during an audit that your 3-year-old ILMT deployment is on an unsupported version can create significant exposure.

3. Scan Frequency

IBM requires that ILMT scans be executed on a minimum 30-day cycle. Scans must be successful — failed scans that generate error logs without completing do not satisfy the compliance requirement. Enterprises should configure automated scan schedules and monitor scan completion reports. A gap in scanning coverage — a server that missed three consecutive monthly scans due to network connectivity issues or a decommission-in-progress — creates a period of non-compliance that IBM auditors can use to retroactively apply full-capacity licensing for those months.

4. Report Generation and Retention

Audit-grade ILMT compliance requires generating and retaining licence consumption reports at least quarterly. IBM requires that these reports be available for the duration of any audit look-back period (typically 2 years, though IBM contractually reserves the right to audit further back). The reports must be generated directly from ILMT — manually assembled spreadsheets are not accepted as equivalent evidence, regardless of how carefully maintained they are.

5. ILMT Server Availability

The ILMT server itself must be maintained, patched, and available. IBM does not accept arguments that a server failure or migration caused a gap in ILMT coverage. Enterprise-grade ILMT deployments should include high-availability configuration, regular database backups, and documented disaster recovery procedures for the ILMT instance itself.

Common ILMT Compliance Failures — and Their Consequences

Independent reviews of IBM software estates consistently find the same categories of ILMT compliance failure. Each one creates quantifiable financial exposure that IBM pursues systematically during licence audits:

IBM Sub-Capacity Licensing: PVU vs VPC Metrics

IBM uses two primary sub-capacity metrics, and understanding the difference is essential for correct ILMT configuration and licence management:

Processor Value Unit (PVU)

PVU is IBM's legacy sub-capacity metric, used primarily for middleware and database products like WebSphere, Db2, MQ, and older versions of Watson products. PVU values are assigned per processor core based on processor model — a two-socket Intel Xeon server with 16 cores per socket at 100 PVU/core would require 3,200 PVUs at full capacity, or potentially 400 PVUs for a VM with 4 assigned cores at sub-capacity.

IBM publishes a PVU table that assigns a specific PVU value to each supported processor type. AMD processors historically carried lower PVU values than Intel equivalents, creating licensing incentives that influenced hardware purchasing decisions at some enterprises. ILMT automatically identifies processor types and applies the correct PVU values from IBM's table.

Virtual Processor Core (VPC)

VPC is IBM's newer metric, introduced alongside Cloud Pak products and applied to most Watson products, Cloud Paks, and newer IBM software. Unlike PVU, which varies by processor model, VPC is a flat metric: 1 virtual core assigned to a licensed workload equals 1 VPC, regardless of processor type. This simplifies calculation but removes the hardware arbitrage opportunities available under PVU.

ILMT tracks both PVU and VPC consumption simultaneously for environments running mixed IBM software portfolios. Correct ILMT configuration requires ensuring each product is assigned to the correct metric — PVU and VPC licences are not interchangeable.

ILMT and Cloud Environments: AWS, Azure, and Google Cloud

IBM sub-capacity licensing in cloud environments is one of the most contentious areas of IBM licence management, and ILMT's role in cloud deployments is frequently misunderstood. IBM's sub-capacity licensing terms were originally written for on-premises virtualised environments — applying them to cloud deployments introduces significant ambiguity that IBM's commercial team has generally resolved in IBM's favour.

IBM Software on AWS, Azure, and Google Cloud

IBM's BYOL (Bring Your Own Licence) model for cloud deployments technically allows sub-capacity pricing if ILMT is deployed and compliant. However, cloud environments create practical ILMT challenges:

• Auto-scaling groups: Auto-scaling cloud infrastructure means the number of instances running IBM software changes dynamically. ILMT must capture peak consumption correctly, and auto-scaling events that create new instances between scan cycles can create coverage gaps.
• Ephemeral instances: Short-lived cloud instances provisioned for batch jobs may run IBM software for hours and then be terminated. If ILMT doesn't capture these instances, IBM auditors argue that the software ran on unlicenced capacity.
• Container environments (Kubernetes): IBM software running in Kubernetes pods introduces additional complexity. ILMT has containerised deployment options, but container-to-host VPC mapping is a common source of disputes during IBM audits of cloud-native deployments.

Using ILMT Compliance as a Negotiation Tool

Most enterprises think of ILMT compliance purely as a defensive measure — something to maintain to avoid audit exposure. This is the wrong frame. A well-maintained, fully compliant ILMT deployment is also a commercial asset in IBM contract negotiations.

Accurate Sub-Capacity Data Challenges IBM's Estimates

IBM's initial licence true-up proposals at renewal are based on IBM's own estimates of your software consumption — estimates that systematically err on the high side. A compliant ILMT deployment producing auditable licence consumption reports gives you independent, IBM-accepted data to challenge those estimates. Enterprises with good ILMT data consistently negotiate lower true-up amounts at renewal because they can demonstrate exactly what they're consuming, rather than accepting IBM's conservative assumptions.

Right-Sizing Opportunities

ILMT data frequently reveals that enterprises are licencing IBM software on servers or VMs where actual consumption is zero or negligible. WebSphere Application Server instances that were deployed for a project three years ago and never decommissioned; Db2 instances running on test infrastructure that was never removed from the ILMT scope. Cleaning up the IBM software estate using ILMT data as the evidence base allows for meaningful licence reduction at renewal.

Demonstrating Compliance Reduces IBM's Audit Incentive

IBM's software audit programme is commercially motivated — audits are an IBM revenue recovery mechanism. Enterprises that demonstrate proactive, comprehensive ILMT compliance reduce IBM's expected audit return and, consequently, IBM's motivation to conduct a detailed audit. Conversely, enterprises with known ILMT gaps are attractive audit targets because the expected licence shortfall is predictable and significant.

What to Do If You Receive an IBM Licence Audit Request

IBM typically initiates licence audits through a formal letter from IBM's Software Compliance organisation, requesting access to your ILMT data and related deployment records. The initial response strategy significantly affects the ultimate financial outcome. Key principles:

1. Don't submit ILMT data immediately. Before providing any data to IBM, conduct an internal compliance assessment. Understand your ILMT gaps, identify the likely compliance shortfall, and determine your negotiating position before IBM sets its expectations.
2. Engage independent representation. IBM's audit team is staffed by professionals who conduct hundreds of audits per year. Responding without equivalent expertise systematically disadvantages the enterprise. Independent IBM licence experts — particularly those with former IBM commercial experience — understand IBM's audit playbook and can neutralise tactics that result in inflated settlement demands.
3. Challenge IBM's methodology, not just the numbers. IBM audits involve multiple methodological choices — which products to include, how to calculate peak consumption, how to handle coverage gaps — where IBM's default position maximises its revenue. Each methodological choice is negotiable.
4. Use the audit as a renewal negotiation lever. IBM is commercially motivated to close audit findings through licence purchases rather than cash settlements. Enterprises that negotiate a simultaneous contract renewal during the audit process often achieve better commercial outcomes than those who treat the audit as a purely compliance matter.

ILMT Alternatives: IBM's BigFix and Third-Party SAM Tools

IBM ILMT is not the only tool IBM accepts for sub-capacity compliance. IBM also accepts BigFix Inventory (formerly Tivoli Endpoint Manager) as an ILMT-equivalent tool for sub-capacity licence tracking. BigFix Inventory provides broader SAM capabilities beyond IBM licensing and is particularly relevant for enterprises that have already deployed BigFix for endpoint management.

Third-party Software Asset Management (SAM) tools — ServiceNow ITAM, Flexera One, Snow Software, Aspera SmartTrack — can extract IBM software deployment data and produce ILMT-format reports in some configurations. However, IBM's position on third-party tool substitutes is not consistent: some IBM audit teams accept third-party SAM data as supplementary evidence but still require ILMT for primary sub-capacity claims. Enterprises relying on third-party SAM tools should obtain explicit written confirmation from IBM that the tools satisfy ILMT requirements before submitting data in an audit context.

Related IBM Licensing Articles

• IBM Mainframe Licensing: How to Reduce Your MLC and MSU Costs
• IBM PVU Licensing: Sub-Capacity Rules That Could Save Millions
• IBM Cloud Pak for Data Pricing: Enterprise AI Platform Licensing Guide
• Software Audit Defence: Your Rights and Response Strategy
• Software Licence Audit: The 7 Triggers Vendors Use to Initiate

Related Services

• IBM Negotiation Service — sub-capacity licensing review and IBM contract negotiation
• Software Audit Defence — IBM licence audit response and settlement negotiation
• Multi-Vendor Negotiation — coordinate IBM alongside Oracle, SAP, and Microsoft