Updated September 10, 2026 (originally published in 2019)
IBM ILMT (the IBM License Metric Tool) is the tool IBM requires you to run if you want to license eligible IBM software by what you actually use in a virtualized environment (sub-capacity) instead of paying for the full capacity of every server it could touch. If ILMT isn’t installed, scoped, and reporting correctly, IBM can license your environment at full capacity — retroactively.
See exactly what IBM’s ILMT terms require →
An IBM audit letter arrives. The team pulls the ILMT reports to prove sub-capacity licensing held up all along and finds two quarters missing from last year. Nobody remembers why. Someone installed the tool. Someone was supposed to check it.
Missing reporting evidence can put your eligibility for subcapacity licensing at risk. If the applicable requirements are not met, the affected software may need to be licensed against the full activated physical capacity of the server, rather than the eligible virtual capacity available to it.
Quick answer: IBM ILMT compliance requires more than installing the tool. For eligible subcapacity deployments, you need an eligible environment, correctly configured ILMT or an approved alternative, complete measurement, accurate software classification and the required reporting history. IBM requires audit snapshots at least quarterly, retained for at least two years. Gaps can put subcapacity eligibility at risk and expose the affected software to full-capacity licensing.
Need ILMT handled, not just explained?
MetrixData 360 reviews and manages ILMT setup, reporting evidence and software bundling so your subcapacity position is ready to defend.
What Is PVU Licensing?
Processor Value Units (PVUs) are one of the metrics used to license IBM software. The PVU requirement depends on the processor technology and the number of cores that must be licensed. ILMT also supports other metrics, including Virtual Processor Core (VPC).
Full-capacity licensing generally counts the activated physical processor cores on the relevant server. Eligible subcapacity licensing can use a lower virtual capacity, subject to IBM’s counting rules. It is not a measure of average CPU utilization.
Your reporting needs to substantiate the capacity available to the software over the relevant period. IBM’s subcapacity licensing requirements explain the eligible products, technologies and approved tools.
What could full-capacity exposure look like? Consider an eligible deployment with four virtual cores allocated to IBM software on a server with 32 activated physical cores. If the software must instead be licensed at full capacity, the count could move from four to 32 cores—eight times the license quantity, assuming the same PVU-per-core factor. This is an illustration, not an estimate of your bill. The applicable counting rules, environment, existing entitlements and pricing determine the exposure. See IBM’s explanation of full-capacity and subcapacity licensing.
Not sure your ILMT reporting would hold up today?
Talk to an ILMT expert about your current setup, reporting history and concerns. We’ll discuss what needs a closer look and whether MD360 can help.
Why ILMT Compliance Is Not Optional Once You Have Sub-Capacity Licensing
Subcapacity licensing can reduce the capacity you need to license, but eligibility depends on meeting IBM’s requirements. Those include the relevant products and technologies, approved tooling and reporting evidence.
The commercial risk is a change in the licensing basis: software you licensed at subcapacity may need to be licensed at full capacity if the requirements are not met. IBM explains the reporting and configuration obligations in its licensing tools guide.
An audit is a difficult time to discover that reports are missing or the measured environment is incomplete. Checking the position earlier gives you time to understand the gaps and address them.
What IBM’s ILMT Terms Actually Require
The requirements are specific, and they are unforgiving of gaps:
- Installation inside 90 days. You must install ILMT (or an approved alternative, such as BigFix Inventory) and have it actively tracking sub-capacity-eligible products within 90 days of the first deployment. Late installation puts the entire pre-installation period at risk of full-capacity treatment.
- Full scope, not partial scope. You must discover and track every sub-capacity eligible product in the environment, not just the ones someone remembered to configure. IBM treats a product running outside ILMT’s scope as unmanaged.
- Quarterly reports, reviewed and retained. Generate audit snapshots at least quarterly and retain them for at least two years. Before generating a snapshot, check that software and capacity data are complete, imports have succeeded, and software classification reflects your licensing documents. Scheduling scans or seeing a current dashboard is not the same as reviewing and retaining the required evidence. Follow IBM’s guidance on preparing and retaining ILMT audit reports.
- Correct topology, not just correct software. ILMT must accurately reflect the virtualization environment underneath the software: hosts, clusters, and how workloads move between them. Incomplete or incorrect virtualization data can distort the reported capacity, even when the tool is running.
None of this is unusual or aggressive on IBM’s part — IBM publishes all of it in its own licensing terms. What makes it risky is that it demands continuous operational discipline, not a one-time installation.
Correct software bundling is part of the reporting work
ILMT discovers software components and assigns them to products, but those assignments need to match your licensing documents. A component may be separately licensable or included with another product as a bundled or supporting program, subject to the permitted use. The tool’s initial assignment is not a substitute for checking those rights.
Review the product and metric assignments, correct them where necessary, and confirm the classifications before generating your audit snapshot. Incorrect bundling can overstate or understate the license requirement. It does not mean every classification error automatically removes all subcapacity eligibility. IBM explains how to review and confirm software classifications.
Where IBM License Metric Tool Programs Actually Fail
In the IBM engagements we walk into, the tool itself is rarely the problem. The gap is almost always operational:
- Nobody owns it after installation. A team deploys ILMT to pass an initial audit or satisfy a renewal condition, then assigns nobody to review the quarterly reports it generates. The reports exist. Nobody looks at them.
- New deployments outrun the scope. A new VM cluster, a cloud migration, or an acquisition adds sub-capacity eligible software, and nobody adds it to ILMT’s scan scope. The tool keeps reporting correctly on what it knows about, and silently misses what it doesn’t.
- The topology drifts. Virtual environments change constantly: teams add hosts, reorganize clusters, and move workloads. If nobody keeps the virtualization data current, reports can overstate or understate the licensing position, and the discrepancy may remain unnoticed until the data is reviewed.
- Reports are generated but not retained. The quarterly report ran, but nobody saved it anywhere a second person can find two years later — which, for audit purposes, is close to never running it at all.
Take ILMT maintenance and reporting off your team’s plate
Keeping ILMT installed is only the beginning. MetrixData 360’s ILMT as a Service helps you manage ongoing maintenance and reporting, address compliance gaps, and reduce the burden on your internal team.
See what’s included and how we help you stay prepared for an IBM audit.
What This Looks Like in a Live Engagement
MetrixData 360 currently manages an ongoing ILMT program for a large North American enterprise running IBM software across a multi-thousand-server estate. Partway through a routine reporting cycle, our team surfaced a gap the client didn’t know existed. An acquisition years earlier had brought in an entire environment, complete with its own set of virtualized servers — and nobody had ever added it to ILMT’s scan scope. On paper, the quarterly reports looked clean. In practice, a whole acquired environment was running IBM software with zero sub-capacity visibility behind it.
That is the “new deployments outrun the scope” pattern above, just with real servers behind it. Without correction, that missing coverage could put the affected deployments’ subcapacity eligibility at risk.
Instead, we treated it as a scope-correction problem, not a compliance failure to explain away. Our team validated the current ILMT deployment against the client’s actual environment and identified every asset running outside scope. Then we rolled out ILMT agents across the newly discovered servers. Reporting on that estate now runs on the same regular cadence as the rest of the program — specifically so the process catches the next acquisition or environment change, instead of an auditor catching it.
That is the shape of the work: find what the reports aren’t telling you, close the gap before IBM’s audit team finds it, and put a cadence in place so you catch the next gap early instead of late.
The Reframe: Installing ILMT Is Not the Same as Being Compliant
Installing the IBM License Metric Tool is one step. Maintaining the measurements, classifications, and retained reports is an ongoing responsibility. A current installation does not, by itself, substantiate earlier reporting periods.
A deployment that has not been reviewed since year one has an unverified current position. The next step is to check the environment and evidence, rather than assume either compliance or noncompliance.
How Organizations Close the Gap
Closing an ILMT gap is a data and governance problem before it is a negotiation problem. That is the same sequence MD360 applies across every vendor: build a defensible position before you need one.
For IBM, that means validating ILMT’s scope against actual deployment data, checking virtualization data, and reviewing available reporting history. Where evidence is missing, investigate what reliable historical data remains and what can be substantiated. Correcting the current deployment does not automatically resolve an earlier gap. Assign ongoing ownership so the next reporting period does not depend on institutional memory.
At MetrixData 360, we start with your existing ILMT setup and records. We compare the reports with your deployments, entitlements and IBM’s requirements, then explain which gaps need investigation, correction or a licensing decision. Our ILMT as a Service support includes recurring reporting and review, with agreed responsibilities for following up on changes and unresolved issues.
IBM ILMT Installation: What It Takes and What Goes Wrong
IBM requires an approved sub-capacity tool to be installed within 90 days of your first sub-capacity deployment. Miss that window and IBM’s position is that the whole environment is licensed at full capacity for the period you were uncovered.
What actually gets installed
ILMT is not a single agent you drop on a server. A working deployment has four parts: a BigFix server, the ILMT application server, a DB2 database behind it, and a BigFix agent on every server running IBM sub-capacity software. Most organizations budget for the first three and underestimate the fourth, which is where the coverage gaps start.
The realistic timeline
A straightforward ILMT deployment across a contained estate takes two to four weeks. A complex one — multiple data centres, mixed platforms, servers nobody has a current inventory for — takes longer, and the long pole is almost never the software. It is finding every server that needs an agent and getting change approval to touch it.
Where installations go wrong
The four failures we see most often, in order:
1. Agents that were deployed and then stopped reporting, with nobody watching for it.
2. Servers added after the initial rollout that never got an agent at all.
3. Scan scope defined once and never revisited as the estate changed.
4. Software detected correctly but bundled wrong, which produces clean-looking reports
that overstate or understate your position.
Each of these produces an ILMT that looks installed and healthy from the console. You find out it was not on the audit.
After installation
Installing ILMT is the start of the obligation, not the end of it. IBM expects reports to be generated at least quarterly and retained for at least two years. An ILMT that is installed but has not produced a retained report in eighteen months gives you no more protection than no ILMT at all.
If you are planning a deployment or have inherited one you are unsure about, we can review it before IBM does.
IBM ILMT Alternatives: What IBM Actually Accepts
IBM does accept alternatives to the IBM License Metric Tool, but only three, and only if they are deployed and reporting correctly. Anything else — a general SAM platform, a VMware inventory export, a spreadsheet maintained by your team — is not an alternative. It is an unlicensed environment waiting to be discovered.
HCL BigFix Inventory
BigFix Inventory is the most common ILMT replacement, and the one most often misunderstood. It is no longer an IBM product (it was transferred to HCL), yet IBM continues to accept it as a validated sub-capacity reporting tool. Organizations already running BigFix for endpoint management can often extend it to IBM sub-capacity reporting without standing up a second tool. The catch is that BigFix Inventory has to be licensed and configured for that purpose specifically; running BigFix for patching does not give you sub-capacity reporting.
Flexera One with IT Asset Management
IBM validates Flexera One and Flexera One Select with IT Asset Management for sub-capacity reporting. This is the usual choice for organizations that already run Flexera across a multi-vendor estate and do not want a single-vendor tool sitting beside it. It is heavier in both cost and implementation effort, and it is seldom worth deploying for IBM alone.
Staying on ILMT
For most organizations with an IBM sub-capacity estate and no existing SAM platform, ILMT is still the right choice. It is free, it is built specifically for IBM’s metrics, and it is the tool IBM’s own audit teams are most comfortable reading.
The reason people go looking for an alternative is usually not the tool itself. It is that their ILMT deployment is incomplete, out of date, or producing reports nobody can defend. Swapping tools does not fix any of that. Fixing the deployment does.
The option that is not an option
Choosing to deploy nothing comes at a cost. Without an approved tool reporting correctly, IBM licenses your environment at full capacity: every physical core on every eligible server, whether or not your software is running there. On a virtualized estate, that difference is routinely six figures.
If you are not sure which of these applies to you, that is the question our ILMT team answers first.
IBM ILMT Support: Where to Get Help
“ILMT support” means three different things depending on what has gone wrong. Knowing which one you need saves a lot of time.
IBM product support
If ILMT itself is broken — the server will not start, scans fail, the console throws errors — that is IBM product support, and it is included with your Passport Advantage Subscription and Support. You raise a case through IBM Support with your customer number. IBM will help you fix the tool. They will not help you interpret what the reports mean for your license position, and they are not obliged to tell you that your deployment has a coverage gap.
Deployment and configuration help
Most ILMT problems are not product defects. They are configuration: agents that never deployed, servers that fall outside the scan scope, software that is detected but misclassified, and bundling rules that were never applied. IBM support will close these as “working as designed” because technically, the tool is. This is where most organizations need help and where they are least likely to get it from the vendor.
Ongoing managed support
ILMT is not a deploy-once tool. Every new server, every VM migration, every product upgrade changes what it needs to see. The organizations that stay compliant are the ones treating ILMT as an ongoing process with an owner, not a finished project. That can be an internal owner with the right training, or it can be outsourced.
What IBM support will not do
IBM support will not tell you whether your reports would survive an audit. They will not review your bundling decisions. They will not flag that a server has been missing from your scan scope for eight months. Those are the questions that decide your exposure, and you have to answer them yourself or bring someone in who can.
If your ILMT reports exist but you are not confident they are defensible, an ILMT review is the faster path than a support ticket.
______________________________________________________________________________________________________________________________________
Frequently Asked Questions
What is IBM ILMT? IBM License Metric Tool identifies IBM software and measures license metric consumption. For eligible subcapacity deployments, it helps produce evidence of the capacity available to the software and the associated license requirement.
Is ILMT mandatory? IBM requires approved tooling for subcapacity reporting. ILMT is IBM’s standard tool, and specified approved alternatives are also permitted. Your environment must meet the applicable eligibility, measurement and reporting requirements.
What happens if ILMT quarterly reports are missing? Missing reports can put your subcapacity position at risk. Check which periods are affected, what underlying data exists and whether the available evidence supports the applicable requirements. Do not assume that generating a current report resolves historical gaps.
Can I use an alternative to ILMT? Yes. IBM accepts approved alternatives such as BigFix Inventory, provided they are installed and actively tracking sub-capacity eligible products within 90 days of deployment, with the same quarterly reporting and two-year retention requirements as ILMT.
Who is responsible for ILMT compliance after installation? IBM holds the licensee responsible, not the installer. In most of the gaps we find, ILMT was installed correctly and nobody was assigned to own it afterward — the tool kept running, but nobody reviewed the reports or updated the scope as the environment changed.
Check Your Own Exposure
Answer these honestly, without pulling a single file first:
- Do you know whether the required quarterly ILMT snapshots for the past two years—or since your deployment began, if more recent—are retained somewhere a second person can access?
- If a new virtualized workload went live in the last six months, are you confident it is inside ILMT’s scan scope, or are you assuming it is?
- Could someone other than the person who configured ILMT explain your current topology model and defend it to an auditor?
- Have your product and bundle assignments been checked against your entitlements and permitted use, or are you relying on the tool’s initial classifications?
- If IBM issued an audit letter this week, do you know how many quarters of history you could actually produce?
If any answer is uncertain, your ILMT position deserves a closer look. Uncertainty does not prove noncompliance, but it is a reason to check the evidence before relying on it.
Need help checking your ILMT position?
MetrixData 360 reviews your existing ILMT setup, reporting evidence and software bundling against your deployments and license entitlements. You do not need a complete technical inventory to start the conversation.