There is a pattern that repeats across enterprise software conversations in 2026. Technology leaders talk about Microsoft, Salesforce, SAP, and Oracle with energy and detail. They discuss cloud migrations, AI investments, contract renewals, and user adoption. They have opinions, data, and sometimes strong feelings.
Then someone mentions IBM, and the room gets quieter. IBM is one of the largest enterprise software vendors in the world. Its middleware sits inside mission-critical applications at hundreds of global organisations. Its database products underpin financial transaction systems that have been running reliably for decades. Its licensing model is among the most technically complex in the industry. And yet, in the enterprise technology conversations that dominate 2026, IBM often goes undiscussed until a problem forces it onto the agenda.
That problem is usually an audit notice.
This blog makes a simple argument: IBM is the vendor that enterprise organisations should be managing more carefully, and the fact that it generates less conversation than other major software vendors is not a sign that it requires less attention. It is a sign that the attention it does receive tends to come too late.
Why IBM Is Different From Other Enterprise Vendors
IBM’s relationship with most large enterprise customers has a characteristic that separates it from newer cloud-native vendors. IBM software tends to run deep. WebSphere Application Server, IBM MQ, Db2, CICS, DataStage, and the broader middleware portfolio have often been running inside enterprise architectures for fifteen or twenty years. The applications that depend on them were written to integrate with specific IBM APIs and behaviours. The operations teams that manage them have often built their practices around IBM’s specific operational model.
This depth of deployment creates commercial leverage that IBM has been willing to use. When software is deeply embedded in systems that the business depends on, the switching cost is not just financial. It is operational, technical, and reputational. Migrating away from IBM middleware is a multi-year project that requires application rewrites, operational retraining, and the careful management of systems that, while old, are running reliably. Most organisations would rather pay IBM’s licence and support costs than take on that migration risk. IBM knows this.
The commercial consequence is that IBM customers tend to pay what IBM asks, partly because the alternatives are genuinely unattractive and partly because the internal expertise to challenge IBM’s commercial positions has eroded as teams have been built around newer technologies. The people who understood IBM licensing deeply have often moved on, retired, or been redeployed. What remains is often a combination of institutional assumption about what the IBM costs should be and a vague anxiety about what an IBM audit might find.
The ITAM Review’s IBM licensing community has documented this pattern extensively, publishing practitioner-level analysis of how IBM licence management capability has declined in many organisations even as the IBM commercial relationship has grown in complexity. Their ITAM Review IBM licensing and management resources address both the technical complexity of managing IBM products correctly and the organisational knowledge gaps that leave many enterprises commercially exposed without realising it.
The Licensing Model That Creates Hidden Risk
IBM licences most of its software using processor value units or resource value units as the primary metric. The PVU model assigns a number of licence units per processor core based on the processor type and model, meaning that the licence cost of running IBM software is directly tied to the hardware it runs on. This sounds manageable until you factor in virtualisation, cloud deployment, and the fact that most enterprise infrastructure has changed significantly since the IBM licences were originally purchased.
In virtualised environments, IBM’s sub-capacity licensing rules allow organisations to licence based on the virtual processor capacity allocated to IBM software rather than the full physical capacity of the host server. This is commercially significant because it can reduce the licence requirement enormously compared to full-capacity licensing. But sub-capacity eligibility requires the deployment and continuous maintenance of IBM’s ILMT tool, which must be correctly configured, regularly updated, and producing accurate historical reports.
This is where many organisations fall short. ILMT was deployed when the IBM licensing was set up. It has not been maintained as the infrastructure has evolved. Virtualisation platforms have changed. Container environments have been added. Cloud deployments have been made. The ILMT that was adequate for the original infrastructure no longer provides complete coverage, and the sub-capacity measurements it is producing may no longer accurately reflect the actual IBM software deployment.
The practical consequence is that many organisations are claiming sub-capacity licensing entitlements that they cannot fully substantiate with ILMT data. When IBM audits those environments, which it does with increasing sophistication in 2026, the gaps in ILMT coverage translate directly into compliance findings.
Redress Compliance has published extensive technical guidance on IBM ILMT requirements and the sub-capacity licensing compliance gaps that IBM auditors most commonly find in enterprise deployments. Their Redress Compliance IBM audit and ILMT compliance guidance provide the technical detail that SAM teams and procurement professionals need to understand what constitutes a defensible IBM sub-capacity licensing position and where the most common vulnerabilities are.
IBM Audits in 2026: What Has Changed
IBM audits have become more data-driven and more targeted in 2026. IBM now uses telemetry data collected from its software installations alongside more traditional audit scripts to build a picture of software deployment before a formal audit is initiated. By the time an audit notice arrives, IBM often already has data that informs where it expects to find compliance gaps. The days when incomplete internal data provided inadvertent protection from audit findings are largely over.
The most significant areas of IBM audit focus in 2026 are virtualised environment coverage in ILMT, container deployments where IBM software runs in Kubernetes or OpenShift environments, cloud deployments particularly where BYOL rules are claimed without full eligibility verification, and high-availability configurations where passive standby environments may or may not qualify for reduced licensing treatment.
Each of these areas represents a genuine technical complexity that requires expertise to manage correctly. Organisations that have not specifically reviewed their IBM compliance position in these areas within the past two years are likely carrying exposure that they are not aware of.
The Conversation Most Organisations Are Not Having
The IBM conversation that most organisations are not having is a straightforward one: when did we last conduct a comprehensive review of our IBM licence position, including ILMT coverage, sub-capacity compliance, and SA status, and are we prepared to defend that position if IBM audits us within the next twelve months?
For most large organisations, the honest answer is that this review has not happened recently. IBM licensing is managed reactively rather than proactively. It comes to the surface at renewal time, sometimes at audit time, and occasionally when a major infrastructure change forces a licence review. Between those events, it tends to exist as a background cost that no one actively manages.
ISACA’s IT asset management frameworks provide governance structures for managing enterprise software compliance as a continuous operational discipline rather than a reactive audit response. Their ISACA IT governance and software asset management frameworks offer the organisational and process frameworks that enterprises can use to establish IBM licensing governance as an ongoing function rather than an emergency response capability.
What Proactive IBM Management Looks Like
Proactive IBM management has four components. First, a current and accurate deployment inventory that covers all IBM software products across all environments including on-premises, virtualised, cloud, and container deployments. This inventory needs to be maintained continuously rather than assembled at point-in-time reviews. Second, an ILMT deployment that is complete, correctly configured, and producing accurate sub-capacity measurements across all environments where IBM software runs. In modern hybrid environments this requires specific configuration attention to containerised and cloud deployments that the default ILMT setup often does not cover.
Third, an entitlement register that accurately maps current IBM licence holdings, their SA status, and the environments they cover. This register should be reconciled against the deployment inventory on a regular basis to identify any gaps between what is owned and what is running. Fourth, a commercial strategy that aligns IBM licence decisions to the renewal cycle and uses proactive compliance management as leverage in commercial conversations rather than discovering compliance gaps in the context of an audit.
KPMG’s software asset management practice publishes research on enterprise IBM governance and the commercial returns that organisations achieve when they treat IBM licence management as a strategic commercial discipline. Their KPMG IBM software asset management and licensing governance resources provide frameworks for building IBM compliance capability that is proportionate to the commercial risk IBM represents in the organisation’s total software portfolio.
Conclusion
IBM is the vendor that does not generate the same boardroom energy as cloud-native platforms, AI investments, or digital transformation initiatives. But it is often the vendor whose commercial risk is most underestimated. The licensing complexity, the audit sophistication, and the commercial leverage that comes from deep technical dependency all make IBM a vendor that rewards careful, proactive management. The organisations that treat IBM licensing as a strategic commercial priority rather than a back-office administrative function will find that the effort pays off in avoided audit exposure, improved commercial terms, and a much clearer picture of what they actually owe for software that is, in many cases, running some of their most critical business processes.
