Client Background: IBM in a Telecommunications Environment
Telecommunications operators have among the most complex IBM software estates in any sector. The BSS/OSS infrastructure — Business Support Systems and Operations Support Systems — that underpins customer billing, network management, provisioning, and service assurance typically runs across large, distributed middleware architectures that have been built incrementally over decades. IBM WebSphere Application Server, IBM MQ message broker, and IBM DB2 are foundational components in most major telco BSS/OSS stacks, having been deployed as industry standards through the 1990s and 2000s.
The client operated a major telecommunications network in Singapore with regional operations in Malaysia, Thailand, and Indonesia. Its IBM middleware estate had been originally deployed in the early 2000s and had been progressively expanded through network rollouts, technology upgrades, and acquisitions of regional assets. The estate ran across both legacy physical infrastructure and a more recently deployed VMware virtualised platform that had been introduced as part of a network modernisation programme completed approximately 18 months before the IBM audit letter arrived.
The network modernisation programme had migrated the core billing and provisioning workloads from legacy physical IBM middleware servers to a new VMware cluster environment. This migration was the origin of the primary ILMT compliance issue. ILMT had been running on the legacy physical infrastructure, generating quarterly compliance reports that IBM accepted. During the migration to VMware, ILMT was not immediately deployed on the new VMware cluster, creating a gap period — from the date the workloads moved to VMware until the date ILMT was eventually deployed on the new platform — during which the sub-capacity licensing entitlement was technically suspended under IBM's policy.
IBM's Initial Audit Findings
IBM's audit letter, issued by IBM's Asia-Pacific Software Compliance team, requested deployment data covering the full IBM middleware estate including both the Singapore primary data centre and the regional data centres in Malaysia and Thailand. The letter specifically requested ILMT quarterly reports for all virtualised environments.
The client's ITAM team — which had been established as part of the same modernisation programme that introduced the VMware platform — identified the ILMT gap immediately when reviewing the data for the IBM response. The gap covered a period of approximately seven months during the VMware migration window. ILMT had been deployed on the new VMware cluster after the migration was complete, but the seven-month gap had not been addressed before the audit letter arrived.
IBM's Effective Licence Position, produced after reviewing the data submission, cited three separate findings. The largest was a full-capacity billing claim for the ILMT gap period, treating the full VMware cluster's physical core count — 192 cores across 8 hosts — as chargeable IBM WebSphere and DB2 capacity for the seven-month window. The second finding was a metric mismatch for certain WebSphere entitlements, asserting that current-version WebSphere deployments required VPC licensing while the entitlements held were expressed in PVU units. The third finding was a disputed IBM MQ installation claim, asserting that IBM MQ queue managers running at the regional NOC (Network Operations Centre) sites in Malaysia and Thailand required separate MQ licences rather than falling within the primary Singapore licence.
Is your telecommunications IBM estate exposed to infrastructure migration ILMT gaps?
Redress Compliance provides proactive ILMT gap assessments before audit letters arrive — and expert defence after.Dispute 1: The VMware Migration ILMT Gap
The ILMT gap created by the VMware migration was the most significant financial exposure in the entire audit. IBM's full-capacity billing calculation for the seven-month gap — 192 physical cores at PVU values multiplied across WebSphere and DB2 — produced a claim in the millions that dwarfed every other finding in the ELP.
Sub-capacity licensing is only valid if ILMT is correctly configured and reporting continuously. This requirement is unambiguous in IBM's sub-capacity licensing policy. However, the financial magnitude of the full-capacity claim warranted a detailed technical challenge rather than immediate acceptance, and Redress Compliance identified several grounds for contesting the scope and duration of the claimed gap.
First, a review of the migration timeline established that not all IBM workloads were migrated to VMware simultaneously. The migration had occurred in phases over four months, with different application components moving at different points. For the initial two months of the seven-month gap period, significant IBM workloads were still running on the legacy physical infrastructure where ILMT was fully operational. Only after the final workload migration were all IBM workloads on the VMware cluster without ILMT coverage. The effective gap duration for the full VMware-migrated estate was therefore four months, not seven.
Second, VMware vCenter performance logs and resource allocation records from the VMware cluster during the gap period demonstrated that the cluster was significantly underutilised at peak capacity, with the IBM workload VMs allocated substantially fewer resources than the total cluster capacity. Redress Compliance presented this VMware utilisation data as evidence that applying full-capacity billing to all 192 physical cores materially overstated the actual IBM software consumption during the gap period.
Third, the ILMT deployment on the new VMware cluster had been initiated eight months prior to the audit letter arriving — meaning the gap was already closed before IBM's audit commenced. The telco was not seeking to avoid ILMT deployment; it had already deployed ILMT and had current-quarter reports available. This demonstrated good-faith compliance intent and strengthened the argument for a remediation-based settlement rather than a punitive full-capacity billing claim.
IBM's compliance team accepted a combination of the shorter effective gap duration and a consumption-based assessment for the gap period, reducing the ILMT dispute from the initial full-capacity claim to approximately 35 percent of the opening figure.
Dispute 2: PVU-to-VPC Metric Transition for WebSphere
IBM's second finding — the PVU-to-VPC metric mismatch for WebSphere — required a detailed review of the telco's entitlement history and the applicable licence terms. The client held WebSphere Application Server entitlements expressed in Processor Value Units, originally purchased through IBM's Passport Advantage programme over a series of transactions spanning more than a decade.
IBM's claim asserted that the current-version WebSphere deployments on the VMware cluster required VPC licensing rather than PVU licensing, and that the PVU entitlements held did not cover the VPC metric requirement. The PVU-to-VPC transition created compliance gaps for organisations that had not updated their entitlements to the current metric for the deployed version. IBM had been transitioning products to the VPC metric progressively since 2020, and WebSphere Application Server traditional edition was among the products moved to VPC for new licence purchases.
Redress Compliance's metric review found two grounds for contesting IBM's position. First, several of the WebSphere entitlements had been purchased under licence agreements that predated IBM's VPC metric transition and contained perpetual licence terms under the PVU metric without version restriction. These entitlements remained valid for current-version WebSphere under the original purchase terms regardless of IBM's subsequent metric transition for new purchases. Second, for the entitlements where IBM's metric transition argument had stronger basis, a conversion analysis using IBM's own PVU-to-VPC conversion table demonstrated that the total PVU quantity held converted to sufficient VPC coverage for the actual deployment scope under the processor types in use.
The combination of the historical entitlement analysis and the conversion calculation eliminated the metric transition dispute entirely, with no settlement purchase required for this component of the ELP.
Dispute 3: IBM MQ Multi-Site Licensing
IBM MQ's licensing for multi-site deployments is a source of frequent disputes in IBM audits. IBM MQ licences are typically site-based or install-based, and IBM's audit teams have different interpretations of what constitutes a separate installation requiring a separate licence in a distributed enterprise environment. For a telecommunications operator with NOC sites in multiple countries, this distinction is commercially significant.
IBM's position was that the IBM MQ queue manager instances running at the Malaysia and Thailand NOC sites were separate installations requiring separate licence entitlements. The telco's position was that these instances were part of a single distributed MQ deployment managed from the Singapore primary data centre, operating as channel agents under the primary Singapore MQ licence rather than as independent queue managers.
Redress Compliance reviewed the MQ configuration documentation, the IBM MQ topology maps, and the relevant IBM MQ licence terms to establish the correct characterisation. The review found that the Malaysian and Thai queue manager instances were operating in a connector mode — handling message routing between the regional sites and the primary Singapore hub rather than originating or terminating message flows as independent installations. Under the applicable IBM MQ licence terms, this configuration was consistent with the primary Singapore licence covering the regional connector instances without requiring separate entitlements.
IBM accepted the configuration evidence and the licence term analysis, withdrawing the multi-site MQ claim entirely.
Settlement Outcome and Post-Audit Programme
With the metric transition dispute eliminated, the MQ multi-site claim withdrawn, and the ILMT gap claim substantially reduced through the migration timeline analysis and VMware utilisation evidence, the residual exposure was limited to the confirmed ILMT gap period, calculated on a consumption basis rather than full capacity. IBM's fiscal year ends on December 31, and the Q4 window (October through December) creates meaningful leverage for IBM customers whose technical workstreams are complete before year-end. IBM's compliance and sales organisations face strong internal pressure to close outstanding claims before December 31, and this case was deliberately timed to reach the settlement table in Q4, which contributed to IBM's willingness to accept a settlement well below its opening ELP position. The final settlement represented 18 percent of IBM's original ELP claim, with no retroactive penalties or back-maintenance fees.
As part of the settlement framework, the telco committed to maintain ILMT across all IBM software environments going forward — including a specific requirement to deploy ILMT as a mandatory component of any future infrastructure migration project, with ILMT coverage established on the new platform before workloads are moved rather than after. This process change, embedded in the organisation's ITAM governance framework, directly addresses the root cause of the primary audit risk.
The post-settlement programme also included a PVU-to-VPC transition assessment for the remaining PVU-licensed IBM products in the telco's estate, ensuring that as the organisation upgrades WebSphere and DB2 versions in future refresh cycles, the entitlements are correctly aligned with the applicable metric for the deployed version. The PVU-to-VPC transition created compliance gaps for many long-standing IBM customers across Asia-Pacific who have not yet systematically reviewed their metric alignment — a proactive assessment avoids future audit exposure from the same issue.
IBM Compliance Considerations for Telecommunications Operators
Telecommunications operators face IBM compliance challenges that reflect both the complexity of their technical environments and the scale of their IBM software estates. Several sector-specific factors merit particular attention from IBM licensing and ITAM teams in the telecommunications industry.
Infrastructure modernisation is endemic in the telecommunications sector. Network technology cycles, spectrum changes, 5G rollouts, BSS transformation programmes, and cloud migration initiatives all drive frequent infrastructure transitions. Each transition is a potential IBM ILMT gap trigger. The lesson from this case and many others is that ILMT must be treated as a migration dependency — a work package that must be completed on the new platform before IBM workloads are migrated, not after.
Multi-site and multi-country deployments create MQ and IBM middleware licensing complexity that differs from single-site enterprise environments. IBM's licence terms for distributed deployments require careful interpretation, and the distinction between centralised management of distributed connector instances and independent site-level installations is commercially significant. IBM's audit teams do not always apply this distinction in the customer's favour, and organisations with NOC or hub-and-spoke network architectures running IBM MQ should review their configuration against the applicable licence terms before audit exposure arises.
The PVU-to-VPC transition is particularly acute for telecommunications operators that have been IBM customers since the early 2000s and are now upgrading to current-version software. Legacy PVU entitlements may cover current-version deployments under original purchase terms or through conversion calculations, but this requires active analysis — IBM's auditors will not volunteer the conversion calculation if the straight metric mismatch argument is more commercially favourable for IBM.
Redress Compliance's IBM advisory practice works with telecommunications operators globally to maintain IBM compliance proactively and to defend against audit claims aggressively when IBM initiates a review. Our buyer-side advisory model and deep IBM licensing technical expertise provide the knowledge base to challenge IBM's findings effectively across every dimension of the ELP.