Grab the full download below—perfect for saving or sharing with your team.
Three weeks ago, I was sitting across from a CTO who'd just received what he called "the email that made my stomach drop." IBM was requesting their quarterly ILMT reports. Simple enough, right?
Except when his team pulled the data, something felt off. The numbers looked... too clean. Too convenient. Like when your teenager tells you they've finished all their homework without you asking.
"We installed ILMT three years ago and ," he said. "We got green lights on the dashboard. We generate reports every quarter. But honestly? I have no idea if we're actually compliant today"
Sound familiar?
Here's what most of us don't talk about: having ILMT installed doesn't mean it's working correctly. In fact, it's a bit like having a smoke detector with dead batteries—everything looks fine until it isn't.
IBM's 2023 policy change eliminated the safety net for smaller organizations. Now, every company using sub-capacity licensing needs ILMT properly configured and reporting within 90 days. Miss that window, and you're automatically paying full-capacity rates—often 2-3 times more.
But here's the thing that keeps me up at night: most ILMT implementations we review have gaps. Not because IT teams are careless, but because ILMT is deceptively complex.
When we sit down with IT leaders, we ask some simple questions that often produce uncomfortable silences:
"When did you last validate that all your IBM software is being discovered correctly?"
Most people assume it just works. But what if that WebSphere instance on the test server isn't reporting? What if your virtualization changes broke agent connectivity? What if new software isn't being classified properly?
"Are you confident your bundling rules are current?"
IBM's bundling logic changes. Cloud Pak entitlements can cover multiple products you might be licensing separately. That expensive DB2 license might actually be included in something you already own. But ILMT doesn't automatically know this—someone has to configure it.
"What happens if IBM asks for documentation tomorrow?"
Can you explain why your usage numbers are what they are? Can you prove that decommissioned server isn't still counting against your license total? Can you demonstrate that your Cloud Pak deployment is properly tracking container usage?
"How do you know what you don't know?"
This is the big one. ILMT reporting gaps often create blind spots. You can't optimize what you can't see, and you can't protect against risks you don't know exist.
A municipal client thought they were fine. Three-year-old ILMT installation, regular reports, no obvious problems. Then we discovered 30% of their endpoints had outdated agents. Their reported usage was artificially low—not because they were using less software, but because they weren't seeing everything.
The gap represented $3.4M in potential backdated charges if IBM had audited them.
Another organization was paying for standalone IBM MQ licenses while running Cloud Pak for Integration. Nobody realized the MQ usage could be bundled under their existing entitlement. They were essentially paying twice for the same capability.
These aren't stories about incompetent teams. These are smart people managing complex environments who discovered that "set it and forget it" doesn't work with ILMT.
ILMT was challenging enough when everything ran on physical servers. Now we're dealing with:
Each layer adds complexity. Each change introduces risk.
Meanwhile, IBM's licensing models keep evolving. FlexPoints, subscription licensing, Cloud Pak bundling—the rules that seemed clear last year might not apply to your environment today.
Here's an exercise: walk over to whoever manages your ILMT and ask them to explain your current licensing position for your top five IBM products. Not just "we're compliant," but specifically how much you're using, what you're entitled to, and why they're confident in those numbers.
If they can give you detailed answers without hesitation, you're ahead of most organizations.
If they need to "check on some things and get back to you," you might want to dig deeper.
If they look slightly panicked... well, at least you know where you stand.
The challenge with ILMT is that partial success feels like complete success. Your quarterly reports generate without errors. Your dashboards show green. Your audits pass basic checks.
But underneath, you might have:
The difference between "working" and "working correctly" can be millions of dollars.
Compliance isn't about checking boxes—it's about having accurate data that supports intelligent business decisions.
When your ILMT is properly configured and maintained, it becomes a strategic asset. You can negotiate renewals from a position of strength. You can make infrastructure decisions with confidence. You can optimize spending based on actual usage patterns rather than guesswork.
When it's not, you're essentially flying blind while hoping for the best.
We've learned that most organizations fall into one of three categories:
The Optimists: "We installed ILMT. We're good." The Worried: "We think we're compliant, but we're not totally sure." The Realists: "We know we have gaps, but we don't know how big they are."
Each group needs a different approach, but they all benefit from the same starting point: an honest assessment of where things actually stand.
Some organizations handle this internally. They have the expertise, bandwidth, and objectivity to thoroughly review their ILMT implementation and fix whatever they find.
Others prefer external validation. They want someone to look at their environment with fresh eyes and tell them what they're missing. Not because their teams aren't capable, but because it's hard to audit your own work objectively.
Both approaches work. The key is actually doing it rather than assuming everything is fine.
If this resonates with you, here are the questions worth exploring:
The answers might surprise you.
At Connor Consulting, we help organizations understand where they actually stand with IBM licensing. Not because we think every ILMT implementation is broken, but because the cost of being wrong is too high to leave to chance. If you're curious about your current position, we're happy to have that conversation. https://advisory.connor-consulting.com/ibm
Three weeks ago, I was sitting across from a CTO who'd just received what he called "the email that made my stomach drop." IBM was
