Optimizing IBM Middleware Licensing
Introduction
IBM’s middleware portfolio—WebSphere Application Server, IBM MQ, and Notes/Domino—forms the backbone of many enterprise applications. Yet, the licensing for these products is complex, with multiple models (from processor-based to user-based to new cloud-centric licenses) that can even confuse seasoned IT leaders.
Non-compliance or suboptimal licensing not only drives up costs but also exposes the organization to significant audit risks.
This playbook, written by an analyst combined with the pragmatism of an independent IBM licensing advisor, provides CIOs with actionable guidance to optimize licensing and manage compliance for IBM middleware products.
We cover the core licensing models, common compliance pitfalls, real-world hybrid deployment scenarios, audit risk factors, and proven strategies to both defend in audits and proactively reduce licensing costs.
A final recommendations section distills strategic and tactical steps CIOs should take to safeguard their organizations.
Licensing Models Overview for IBM Middleware
Understanding the licensing models for each IBM middleware product is the first step in effective management. IBM offers various licensing metrics and editions tailored to different needs, including traditional models like PVU and newer cloud-focused models.
Below is an overview of how WebSphere, MQ, and Notes/Domino are licensed, including modern bundled options:
WebSphere Application Server (WAS) Licensing
Editions and Features: WebSphere Application Server is available in multiple editions, including Base, Network Deployment (ND), Liberty, and others such as Express and z/OS. The Base edition provides core Java EE server capabilities for standalone or simple deployments.
Network Deployment (ND) is the advanced edition, designed for enterprise clusters and distributed environments. It introduces features such as a centralized Deployment Manager, clustering and load balancing, high-availability failover, and intelligent management tools not available in Base.
In other words, ND includes the robust orchestration and scaling features needed for mission-critical applications, whereas Base is intended for simpler or single-server scenarios. Liberty is a lightweight, modular runtime, often used in cloud-native or container scenarios, and can be licensed separately or as part of bundles.
Licensing Metrics: Traditionally, WebSphere is licensed based on processing power, using Processor Value Units (PVUs). PVU licensing ties the entitlement to the CPU cores and type. Each core (physical or virtual) has a PVU rating, and you must procure enough PVUs to cover all cores running WebSphere. This has been IBM’s classic model for middleware.
Another option is Virtual Processor Cores (VPC) licensing, introduced with IBM Cloud Paks and WebSphere Hybrid offerings. VPC is effectively IBM’s cloud-era equivalent of PVU, measuring the virtual CPU resources allocated to software in containerized or virtual environments.
In practice, VPC licensing allows for more cloud-flexible consumption (measured by virtual cores), which aligns with deployments on Kubernetes or public cloud VMs.
User and Other Metrics:
Although less common for WebSphere itself, IBM has historically offered Authorized User or Concurrent User licensing for specific middleware cases. For example, an Authorized User license would entitle a specific named individual to use the software, potentially across multiple servers.
However, WebSphere Application Server is typically not licensed per user because it is a server platform; user-based models are more relevant to end-user software or certain tools. Resource Value Unit (RVU) licensing has also been available in IBM’s catalog, tying license counts to a usage metric or capacity beyond CPU. Still, for WAS, the dominant models are PVU or VPC.
Bundled / Cloud Pak Options:
In recent years, IBM has bundled WebSphere in broader offerings. The key one is IBM Cloud Pak for Applications, along with its related WebSphere Hybrid Edition. Under these bundles, customers purchase a pool of VPCs that can be flexibly allocated across various WebSphere editions (such as Traditional WAS ND, WAS Base, Liberty, etc.) and related tools.
For example, WebSphere Hybrid Edition provides the right to use both traditional WebSphere ND and Liberty in any mix, up to the purchased capacity, which aids in modernization efforts. Cloud Pak for Applications similarly includes entitlements for WebSphere along with other runtime components.
These bundles simplify mixing and matching editions, and even moving workloads to containers, without requiring separate license purchases for each edition – everything is drawn from the common VPC pool.
The CIO should note that even with Cloud Paks, it’s crucial to track usage. IBM provides the IBM License Service for Kubernetes to measure VPC consumption in container environments.
Summary: In practice, most enterprises license WebSphere either by PVU (for on-premises traditional deployments) or via Cloud Pak VPCs (for cloud and containerized deployments). Base vs. ND vs. Liberty is a choice of edition: Base is the lower-cost option but cannot support federated clustering; ND is required for advanced scaling and management features; Liberty is lightweight and cloud-optimized, often used with Cloud Paks. Ensuring you have the correct edition license for the features you use (e.g., ND license if you use clustering) is an essential compliance point, which we will discuss later.
IBM MQ Licensing
Editions and Components:
IBM MQ (message queuing middleware) is offered in a Standard edition (sometimes just referred to as IBM MQ) and an Advanced edition. MQ Standard provides core messaging capabilities, including reliable queues, topics, and more.
At the same time, MQ Advanced includes additional features like built-in end-to-end encryption (MQ AMS), managed file transfer (MQ MFT), and the telemetry (IoT) extension. There are also add-ons, such as MQ Appliance (a hardware appliance form factor) and specific client or telemetry licenses. However, from a licensing management perspective, the server installations of MQ are the main focus.
Licensing Metrics:
MQ server software is predominantly licensed by Processor Value Units (PVUs), similar to WebSphere. Each server (or virtual machine) running an MQ queue manager must be covered by a sufficient number of PVUs based on its CPU core count and type. This applies to both the Standard and Advanced editions.
The Advanced edition has a different product identifier and a higher cost PVU, but the metric is still calculated per PVU. In virtualized setups, IBM allows sub-capacity PVU licensing (only counting allocated virtual cores rather than full physical machine) provided that IBM’s compliance tool is used (more on ILMT in the compliance section).
Notably, IBM does not license MQ based on the number of messages, transactions, or connections – it’s purely infrastructure-based licensing. There are a couple of special metrics for specific MQ components.
For instance, MQ Telemetry (for IoT and mobile messaging) can be licensed per installation or client device, and the MQ Managed File Transfer agents can also be licensed per client. These are niche cases; the majority of MQ deployments use PVU licenses for the server-side.
Development and Non-Prod:
IBM provides a free entitlement, MQ Advanced for Developers, which is a full-featured MQ (equivalent to the Advanced edition) that can be used at no cost in development and test environments, with the caveat that it cannot be used for production workloads. This is extremely useful for organizations to avoid consuming expensive licenses in non-production environments.
Additionally, IBM’s Passport Advantage agreement often allows the use of production licenses in a cold backup environment (or for limited testing). Still, many clients opt for the free developer edition for development and testing, staying clearly within bounds.
Cloud & Bundling Options:
IBM MQ is a key component of IBM Cloud Pak for Integration, a bundle that also includes IBM App Connect (Integration Bus), DataPower Gateway, API Connect, and more. With Cloud Pak for Integration, licensing shifts to the VPC model: you buy a block of Virtual Processor Cores that can be allocated across any of the integrated products, including MQ. If an organization is running MQ in Red Hat OpenShift or containers, this can be an effective way to license it flexibly.
IBM also offers MQ as a managed service on IBM Cloud and other clouds, which would be a subscription service rather than a license that the CIO manages directly. If you bring your license to run MQ on a public cloud VM, it is essentially the same PVU model as on-premises, counting the cloud VM’s cores. IBM provides PVU ratings for various public cloud VM instance types.
Summary: Most MQ deployments will count PVUs on each server or VM, and one should ensure that all installations that are actively running are included. The Advanced edition means you must purchase the Advanced PVUs if you use those advanced features.
For modern deployments, consider Cloud Pak for Integration’s VPC licensing if you use MQ alongside other integration products or in a containerized form. Always take advantage of the free developer license for non-production usage to conserve your paid entitlements.
IBM Notes/Domino Licensing
Product Scope:
IBM Notes and Domino (now sold and developed by HCL as of 2019) is a collaborative platform including mail, calendaring, and applications. Even though HCL now owns Domino, many organizations still have legacy IBM licenses or support contracts for Domino, and these licensing paradigms remain relevant. We will address both the traditional IBM models and the updated HCL model, as CIOs may be dealing with a transition period.
Traditional IBM Domino Licensing Models:
Historically, Domino licensing was primarily based on the number of users. An Authorized User license for Domino would entitle one person (typically a named user, such as an employee with a Notes ID and mailbox) to use the Domino environment.
Under this model, a company would purchase several user entitlements equal to the number of active Notes/Domino users. Those entitlements usually allowed the user to use any number of Domino servers (mail servers, application servers) – the license was tied to the user, not the server.
There were different flavors: for example, Messaging licenses (for email and calendar use only) versus Enterprise (full collaboration and application) licenses, and even an Express licensing option for small deployments (with a cap on the number of users and possibly limited clustering).
There was also a concurrent user model in some cases for Domino (e.g., for external web users or very large pools), but most enterprises used authorized user metrics. Additionally, IBM offered a Domino Utility Server licensing model, which was PVU-based. This allowed unlimited unnamed users to access Domino applications (not email) running on that server.
The Utility Server was used for Domino as an application platform (e.g., a web portal) when counting specific users wasn’t feasible; instead, you would license the server’s CPU. Some organizations may have this type of license for certain Domino application servers, while using per-user licenses for mail servers.
HCL’s Current Domino Licensing:
HCL has moved all Domino customers toward a unified user-based model called Domino Complete Collaboration (CCB) licensing. As of 2024, HCL announced the end of life for the old IBM licensing SKUs, consolidating everything into the CCB user model (with variations for external users or partners). Essentially, each employee or internal user who uses any Domino service requires a CCB license, which grants access to all Domino features, including mail, applications, and Traveler mobile access. The changes mean even if you previously had PVU-based Utility server licenses, HCL is phasing those out in favor of user-counting.
For organizations still under IBM contracts, you may have a renewal where IBM passes you to HCL’s model, or you negotiate new terms directly with HCL. The key takeaway for CIOs is that Domino is now fundamentally a user-centric license model, and historically, it was primarily user-counted for most use cases. PVU licensing for Domino is becoming legacy.
Implications:
With user-based licensing, accurately tracking the number of active users is critical. An “active user” usually refers to a unique person who is enabled in the system to use Domino. Suppose a user has multiple devices or Domino servers; that still counts as one user license, as the license follows the person.
But suppose you have 1,000 users in your Domino Directory. In that case, you need 1,000 licenses (even if only, say, 800 actively use mail and 200 are occasional or dormant – unless you formally archive or disable those 200 such that they are no longer allowed to access).
We will explore compliance issues around this, but it’s clear that managing the user list —promptly retiring accounts for departed employees or consolidating duplicate accounts —directly ties to license requirements.
Support Contracts:
One nuance: some organizations have chosen to continue paying IBM for Domino support even after HCL (through legacy agreements) or have opted for third-party support, rather than moving to HCL’s renewal.
During this transitional period, ensure you understand which license model you are beholden to. If you remain on IBM Passport Advantage with Domino, you must follow the IBM terms you originally had, which are likely Authorized User or PVU. If you moved to HCL’s contract, you’ll be on CCB.
The playbook’s recommendations on user counting apply in either case; the specific terms may differ slightly. Also note that the old IBM licenses (such as Utility and Enterprise Server) have official end-of-support dates. HCL set an End of Support Date for IBM Domino perpetual licenses in 2025. CIOs should plan a migration to HCL’s licensing model or an alternative collaboration platform to avoid running unsupported software.
Common IBM Licensing Metrics (Summary Table)
To summarize, below is a table of the primary licensing models and how they apply to our three products:
| License Metric | Description | Applicable Products | Usage |
|---|---|---|---|
| Processor Value Unit (PVU) | Capacity-based metric tied to processor cores (physical or virtual), weighted by processor type. | WebSphere AS (Base/ND), IBM MQ, Domino Utility Server (legacy) | Typical for server software installed on CPUs. Requires IBM’s PVU table to calculate per core. Sub-capacity (virtual) use requires ILMT tracking. |
| Virtual Processor Core (VPC) | Capacity-based metric for virtualized/cloud environments, counting virtual cores allocated. Often used in Cloud Paks. | WebSphere (via Cloud Pak/Hybrid Ed.), IBM MQ (via Cloud Pak for Integration) | Modern alternative to PVU in container or VM contexts. Simplifies licensing across cloud deployments; tracked by IBM License Service in clusters. |
| Authorized User (AU) | A unique individual authorized to use the software. License is per named user. | Domino (IBM and HCL models), Also applicable to other IBM software like Cognos, etc. (WebSphere/MQ usually not user-based) | Dominant model for Domino: each person with a mailbox or access needs a license. Not typically used for WebSphere/MQ. |
| Concurrent User | Licenses based on simultaneous users, not named individuals. For a pool of users where only a subset use the system at once. | (Rare for these products; Domino had some external concurrent models; WebSphere/MQ mostly not applicable) | Generally less common; possibly used for external web users on Domino or trial scenarios. IBM moved away from concurrent in favor of authorized user in recent years. |
| Install/Device | License per installation or device accessing. | IBM MQ Telemetry (per device), MQ MFT Agent (per install/client). Notes client licenses historically per install in some cases. | Specific use-cases. Not a factor for core WAS or base MQ server licensing. |
| Subscription (Monthly) | Subscription-based licensing (monthly or annual term licenses instead of perpetual). | All (IBM offers subscription licensing for most products now) | Not a metric per se, but a licensing model: you pay for term-based usage. Cloud Paks are essentially subscription licensing by VPC. HCL Domino CCB is subscription annual user licenses. |
CIO Tip: Ensure you know which metric applies to each component in your environment. For example, your WebSphere ND servers might be PVU-licensed, your Domino users are licensed as Authorized Users, and perhaps an MQ telemetry add-on is device-licensed—all within the same organization. Clear record-keeping of these entitlements is essential.
Common Compliance Challenges and Pitfalls
Even with a solid grasp of licensing models, organizations often encounter compliance issues when managing IBM middleware. IBM’s rules are exacting, and it’s easy to drift out of compliance through seemingly innocuous actions, such as expanding a server cluster or failing to monitor user accounts.
Below, we highlight some of the most common compliance issues for WebSphere, MQ, and Domino, along with insight into why they occur.
- Using WebSphere ND Features on a Base License: A common mistake is deploying WebSphere Application Server in a way that takes advantage of Network Deployment features without purchasing ND licenses. This can happen, for example, if an admin installs the ND version of the software (which includes the Deployment Manager and clustering capabilities) even though the organization only owns Base edition licenses. It might also occur if a team enables clustering or high-availability configurations, assuming it’s a technical configuration, not realizing these features require the ND edition entitlement. The compliance risk is significant: IBM’s auditors can detect ND binaries or the presence of an active deployment manager profile, and if your entitlement is only for Base, you effectively have unlicensed use of ND. The financial exposure here is that IBM would require you to purchase sufficient ND licenses (backdated to the deployment date) and pay support fees for those, which is far more costly than Base. Preventive measure: Segregate installations by edition; if you need ND features in some environments but not all, ensure only the proper machines have ND installed. Communicate to engineering teams that clustering, federated management, and certain advanced features are off-limits unless ND licenses are allocated. If cost is a concern, consider if those apps could run on multiple independent Base servers with external load balancing (a possible workaround to avoid ND) or explore WebSphere Liberty, which can form clusters under a different licensing model. The bottom line is to never assume an IBM feature is “free” – always verify if it’s tied to a specific edition or license.
- Over-provisioning PVU Licenses (Lack of Inventory Control): PVU-based licensing requires diligent tracking of where software is deployed and on how much hardware is used. A common compliance issue is simply using more PVUs than you have purchased. This overallocation often stems from poor visibility: new VMs or servers are spun up and run WebSphere or MQ without notifying the license management team, or additional CPU cores are assigned to existing VMs over time (e.g., a VM is given an extra vCPU for performance, which increases the PVU requirement). Another culprit is not using IBM’s License Metric Tool (ILMT) in virtualized environments. IBM’s sub-capacity licensing rules mandate that ILMT be installed and regularly report, if you want to license by PVUs on VMs rather than full physical capacity. If ILMT is not in place or not kept up to date, in an audit, IBM can choose to assume full hardware capacity licensing, which often results in a significant gap in entitlements. Many organizations also fail to reconcile decommissioned systems: you might have licenses for a retired server that could be reused elsewhere, but if not tracked, you might buy new licenses unnecessarily or, worse, accidentally use software without a license because you assumed you had free capacity. Preventive measure: Implement robust asset management and change management that includes license impact. Every time a new instance of WAS or MQ is deployed or an existing instance is allocated more CPU, it should trigger a review of license usage. ILMT (or its authorized alternatives) must be deployed on all relevant systems and configured to scan and report quarterly, as IBM requires. Review ILMT reports and compare against entitlements regularly. This way, if you’re creeping close to your PVU limits, you can true up via purchase or proactively reallocate resources. Over-provisioning is typically not intentional, but without automated tracking, it becomes almost inevitable over a long enough period.
- Undercounting Domino Users (Dormant Accounts): In a user-based licensing scheme like Notes/Domino, a very common issue is inaccurate user counts. This usually means the organization has more user accounts active than licenses. It often happens because of “dormant” users – for example, employees who left months ago but whose accounts were never fully removed or disabled in Domino Directory, or test accounts and service accounts that were created and never cleaned up. Each of those accounts technically represents an “Authorized User” that could use the software, and thus, IBM (or HCL) would consider them licensable users. Domino administrators sometimes also keep disabled IDs or old archives that still count toward the license in reports if not handled correctly. Another scenario is failing to regularly reconcile with HR records – if 100 new employees joined but license purchases were not adjusted, you could be over by 100 users. Preventive measure: Institute a strict joiner/mover/leaver process in IT that includes Domino accounts as part of the workflow. When someone leaves, their Domino account should be either deleted or marked inactive in a way that it no longer counts towards the active user license tally. Domino 11+ has features and tools, such as the DLAU tool from HCL, to help identify inactive users over a period (e.g., no login for 30 days), which can guide license true-up or reclamation. Regularly run reports of active users vs. licenses owned. Also, be mindful of functional IDs (such as an office mailbox or a system agent ID) – if these exist, they may also require licenses, unless your contract allows service IDs to be used free of charge. The goal is to always be audit-ready with a clean user list; you should be able to justify each active account as a licensed user or show that it has been inactive or disabled according to policy.
- Misconfigured High Availability for MQ (License Overlooked): High availability (HA) and disaster recovery setups can create licensing blind spots. IBM MQ is often deployed in HA pairs or clusters (e.g., an active queue manager and a standby on separate servers, or a multi-instance queue manager setup). IBM’s licensing policy for HA is not simply “only license the active one” without conditions. IBM offers special Idle Standby licenses for exactly this scenario: a standby MQ instance can be covered with a lower-cost license (typically charged at 20% of the full price) as long as it is truly idle, except during failover. If a company doesn’t know this and fails to license the standby, an audit will flag the standby installation as unlicensed. Alternatively, some customers license both active and passive options at full cost, which is compliant but may be a waste of money if a cheaper standby option existed. Another scenario: in active-active clusters (where both nodes are actively handling messages), both need full licensing – sometimes organizations mistakenly think that if each handles half the load, they only need one license, which is false. Preventive measure: Document your MQ HA design and ensure the licensing matches. If using an active-passive cluster, purchase the appropriate Idle Standby entitlement for the passive node, or verify that your Passport Advantage contract includes the 100% failover exemption for that product. IBM’s rules vary by product, but for MQ, the standby is typically not free without the special license. Configure ILMT to exclude the standby instance from PVU counting with a proper annotation that it’s a standby, if applicable. This way, ILMT reports to IBM won’t misleadingly show double capacity. If using mutual failover (two active MQs that can take over each other), essentially, both are active from a licensing view. The same logic applies to any WebSphere or Domino servers in high availability (HA): understand IBM’s policy. For example, WebSphere ND in a cluster – all nodes must be licensed; there is no standby concept since they typically run concurrently. Domino clustering: if you have two mail servers in a cluster serving the same users, generally each server needs its PVUs covered,d but you don’t double-count the users – you license users once and servers by PVU if server-based. It gets nuanced!) The key is not to assume anything about “secondary” servers being free – always check IBM’s licensing rules for cold, warm, or hot standbys.
- Mixing License Types Without Compliance Controls: Sometimes, organizations have a mix of licensing models due to mergers or changes in IBM’s bundling. For instance, you might have some WebSphere instances under a Cloud Pak (VPC) and others under PVU from before, all running in parallel. Or you have Domino under both IBM and HCL terms. These situations can lead to accidental non-compliance if not managed. An example: Suppose you purchased Cloud Pak for Integration with the intent to cover some new MQ container deployments, giving you, say, 100 VPCs of entitlement. But you also still run some MQ on VMs licensed by PVU. If you deploy more MQ instances, be careful to allocate them either against the remaining PVUs or the VPC pool, and importantly, ensure that you do not double-count or overlook which bucket they fall into. Some organizations mistakenly think that buying a Cloud Pak automatically covers all existing deployments. It does not, unless you formally convert those under the Cloud Pak through IBM’s agreement. Similarly, if you have partially migrated Domino users to a new model, ensure that those remaining on old licenses are adequately covered. Preventive measure: Treat each license pool separately and maintain a clear record of which servers and users are accounted for under each entitlement. You may even logically separate the environments (e.g., Cloud Pak-based deployments on a separate cluster or partition) to avoid confusion. During an audit, IBM will want to see proof of entitlements for each installation; you should be able to produce either the PVU PoEs (Proof of Entitlement) or the Cloud Pak entitlement that covers it. If you can’t map a given instance to a specific license purchase, you have a compliance gap.
- Non-Production Environments Not Properly Licensed: It’s worth noting a compliance issue that often surprises management: even non-production installations require licensing, unless a free developer edition or special non-production license is used. IBM does not automatically allow free usage of software in test or dev. Some companies erroneously run a full WebSphere or MQ in a lab or staging environment without accounting for it, thinking, “It’s not production, so it doesn’t count.” IBM’s view is clear: if it’s the full product and not a free express version, it counts. The only exceptions are if you have a specific non-production entitlement or if the vendor provides a developer copy, such as the free MQ Developer or a WebSphere trial. Preventive measure: Include all environments in your license tracking. Use the free editions where available for development and testing. WebSphere has a Developer Edition and Liberty Core; MQ has a Developer Edition. Domino is a bit different, as each user typically has a license that covers development use. If, for some reason, you must use production binaries in test (to replicate exact production conditions), consider obtaining an IBM non-production license (IBM offers some products with lower-cost “Non-Production PVU” licenses for this purpose) or ensure you have spare capacity in your entitlements to cover them. The worst outcome is an audit that finds 10 extra installations in a test lab that were never licensed – that is still a violation.
In summary, compliance issues usually arise not from malicious intent but from a lack of oversight and communication. The infrastructure team expands capacity, the dev team enables a feature, or accounts accumulate, all without license governance being involved.
CIOs should treat license compliance as an ongoing operational process, rather than a one-time true-up. Next, we’ll examine how these issues play out in some hybrid environment scenarios and what to look out for.
Licensing Scenarios in Hybrid Environments
Modern IT environments are rarely homogenous; you may have IBM middleware spread across on-premises data centers, private clouds, and public cloud services.
Hybrid architectures introduce new wrinkles in licensing.
Let’s explore a few representative scenarios a CIO might encounter and how to handle their licensing:
Scenario 1: IBM MQ On-Premises and in the Cloud
Context:
An organization runs IBM MQ in its on-premises data center for core integration between internal systems. Also, it deploys IBM MQ on a public cloud (e.g., on AWS or Azure VMs, or as a containerized MQ in a cloud Kubernetes cluster) to connect with cloud-native applications. There might also be an MQ instance in a disaster recovery site.
Licensing Approach:
For on-premises MQ, assume it is licensed via PVUs on physical or virtual servers under Passport Advantage. For the cloud deployment, there are a couple of options: (a) If using IaaS VMs, you can Bring Your License – meaning you count the vCPUs of those cloud VMs and cover them with your existing PVU entitlements (IBM provides guidance on how to calculate PVUs for different cloud VM types). (b) If you’re using containers (such as OpenShift on the cloud or another Kubernetes), you might cover those via Cloud Pak for Integration VPCs if you own them. Or (c) use IBM’s managed service “MQ on Cloud,” which is a subscription, and IBM as a service handles the license (that scenario removes license management for that portion, but you pay a service fee).
Key Considerations:
A major consideration is tracking usage across environments. On-prem, ILMT will track your PVU consumption. In containers or the cloud, IBM’s License Service (if Cloud Pak) will track VPC consumption. These two metrics (PVU and VPC) are not directly interchangeable—ensure you do not accidentally “double count.” For example, if you shift some workloads to containers, you might reduce the load on on-prem MQ (freeing some PVUs) but start consuming VPCs.
You cannot simply stop renewing PVUs unless you formally reduce your entitlement with IBM at renewal, or unless you have an elastic enterprise license. Some companies end up initially over-licensed during transitions, paying for both PVUs and Cloud Pak, which can be okay if budgeted. However, make sure to optimize once the transition stabilizes.
Another issue is license compliance in disaster recovery (DR): Suppose the on-premises MQ has a DR instance in the cloud on standby. If you treat cloud DR as an extension of on-premises, you might use the Idle Standby license for it, ensuring it’s only used during actual disaster recovery.
But if that DR is in a different environment, ensure your ILMT/monitoring covers it, or check if your contract allows for it not to be counted until failover. Communication with IBM is key in hybrid scenarios. Sometimes, they offer specific arrangements or flexible licensing if you explain your architecture. For instance, during cloud migration projects, IBM might grant temporary rights.
Audit Defense Angle:
During an audit, IBM will request deployment data. You need to show all MQ instances, whether on-prem or in any cloud. Sometimes companies forget that a quick PoC done in the cloud months ago (and never shut down properly) is still an installed instance, which an audit could discover through records or employee interviews. Keep a register of all environments: e.g., “3 queue managers on-prem on these servers (covered by PVU), two queue managers in Azure (covered by PVU), four containerized queue managers in OpenShift (covered by Cloud Pak, with x VPCs allocated).”
Then you can show you have entitlements for each category. Additionally, preserve evidence such as ILMT reports for on-premises and the IBM License Service report for Cloud Pak usage in case of an audit – these substantiate your calculations.
Cost Optimization:
A benefit of a hybrid could be cost optimization if done right. For instance, you might decide to eventually consolidate all MQ under Cloud Pak for Integration, which could simplify licensing if you also use IBM Integration Bus or API Connect, as one pool covers all. Alternatively, suppose cloud usage is temporary or seasonal. In that case, you might script deployments so that you only run cloud MQ when needed, possibly saving on licenses if it’s not running constantly. However, IBM licenses are not typically metered by time, except when using monthly container licenses on IBM Cloud.
The main cost lever is to avoid redundancy: don’t pay for the same capacity twice. If you reduce on-prem usage, renegotiate PVU counts down at renewal or shift those funds to cloud licenses accordingly.
Scenario 2: WebSphere Base in One Cluster, ND in Another
Context:
A company has multiple application teams. One team runs a small cluster of applications that don’t require advanced features – they use WebSphere Base Edition on two standalone servers behind a load balancer. Another team runs a large, mission-critical app that benefits from the full WebSphere ND capabilities – they have a cell with a Deployment Manager and four cluster members, spread across two physical nodes. Essentially, within the same organization, there is a mix of Base and ND usage.
Licensing Approach:
This scenario illustrates the importance of aligning edition with entitlement. The first cluster (using Base) should be licensed with WebSphere Base edition licenses, likely PVUs for the cores on those two servers. The second cluster must be licensed with WebSphere ND licenses (PVUs for the cores on those four cluster members, plus the Deployment Manager – note the DM is typically on one of those or a separate node, but if it’s separate and running on its server, that server’s PVUs need ND license as well).
If the organization had chosen Cloud Pak or Hybrid Edition licenses, it could cover both clusters under a single VPC (Virtual Private Cloud) pool. However, let’s assume they are using separate traditional licenses here.
Key Considerations:
Separation of environments is key to compliance here. There should be no “mixing” of Base and ND within the same cluster environment. For example, you wouldn’t federate a Base server into an ND cell, because technically, that Base server would then require an ND license (since the ND Deployment Manager is managing it).
Similarly, administrators should not use ND’s features on the Base cluster. One subtle example: WebSphere ND comes with “Intelligent Management” features (formerly an add-on called On Demand Router, etc.). If someone installed that feature pack on a Base server, it’s not allowed without ND.
From a management perspective, it might make sense to physically separate the two environments (different VLANs or at least named server sets) to avoid accidental license drift. Some companies in this scenario find it simpler to standardize on ND across the board (to avoid confusion) – but that can be expensive if you truly don’t need ND for some apps.
The cost difference might be justified if the risk of misusing ND features is high. However, with good governance, you can certainly run both. Ensure procurement records distinctly show how many PVUs of Base and how many of ND you own.
Audit Defense Angle:
In an audit, IBM might find it odd if you have some ND licenses and some Base – they will likely scrutinize whether any Base installations were running ND. It’s essential to maintain documentation that shows which servers are allocated to which edition. One useful practice is to document the feature usage: for instance, maintain an architecture diagram or spreadsheet that indicates “Servers A and B: WebSphere Base (used for X app, no clustering beyond OS load balancing). Servers C, D, E, F: WebSphere ND (used for Y app, in one cluster).” Also, keep installation logs or version info – the version of the package installed often indicates Base vs ND.
During audit discussions, be prepared to demonstrate that the Base servers were not part of any ND cell (show config files or the lack of ND processes). If you have Cloud Pak (VPC) covering both, then you don’t have to worry about Base vs ND entitlements separately – you show total VPC usage across them. But in that case, you must demonstrate you didn’t exceed VPCs and that the Cloud Pak metric accounted for both sets of servers.
Cost Optimization:
One obvious question is, is it cheaper to convert everything to ND or keep some Base? ND licenses cost more (since they include the extra functionality), but if you already own Base licenses, there’s no need to upgrade them unless you truly need ND. A CIO might consider negotiating an Enterprise License Agreement (ELA) that covers all WebSphere usage up to a certain limit. This could make the Base vs. ND distinction moot from a cost perspective and provide flexibility to use ND where needed. Alternatively, suppose certain apps on Base could be moved to WebSphere Liberty.
In that case, you might reduce costs because Liberty core or base licenses (or even using Liberty in a free runtime mode if possible) could replace full WAS Base instances. Each scenario is unique, but it’s worth periodically evaluating: are we paying for ND where we don’t use it, or conversely, risking compliance by not licensing ND where we use those features?
Scenario 3: Domino in a Mixed Environment (On-Prem and Cloud Service)
Context:
Suppose an organization uses Domino for applications internally, but has migrated email to the cloud. They might have 500 users who still use a Domino application (workflow database) on-premises, and another 200 users who were on Domino but now use Office 365 for email and no longer need Notes. However, the Domino server is still running for those 500, and the other 200 are just idle accounts, not really in use. Additionally, the organization might be evaluating an HCL Domino Cloud offering for the future.
Licensing Approach:
If under IBM licenses, they likely had, say, 700 Authorized User licenses originally. Now, only 500 are active. Ideally, they should reduce their entitlement at the next renewal to 500 (or whatever the peak active user count is) to save costs. If they have already moved to HCL CCB licensing, HCL will charge based on the actual users deployed; they may have a minimum from their last purchase that needs adjustment. In either case, the key is aligning licenses to actual usage and ensuring those 200 former users are not counted. This might involve cleaning up the Domino Directory to remove or formally inactivate those users. Domino can mark users as inactive or remove their ability to authenticate, which would mean they no longer require a license.
If the organization has both IBM and HCL licenses in effect (perhaps in year 1 of transition, with the IBM contract not yet fully ended), they must be careful not to double-license. Typically, one would either still be on IBM or switched to HCL, not both, except during a brief migration period. It’s advisable to clarify with IBM/HCL whether a transfer or conversion can be done for those licenses. Often, remaining IBM support is converted to HCL’s new licenses.
Key Considerations:
User Counting is the number one consideration. If any accounts are left active for the 200 ex-users (perhaps for archive access or legal hold), one must consider whether those need a license. Under IBM’s definition, if a user account exists and can log in (even just to an archive database), technically, that’s an authorized user. HCL’s CCB model is a bit more lenient, as it discusses reassigning licenses if a user is inactive for 30 days or more (especially for external users).
Still, for internal users, it’s assumed every defined user is consuming a license. A strategy could be to convert those 200 to “external” or inactive status in the tool, so they don’t count toward internal user license, but that depends on contract terms. From a compliance standpoint, you do not want an auditor to pull a user count from your server and find 700 entries when you only have 500 licenses. Ensure the discrepancy is resolved before that can happen.
Another consideration is server licensing if Domino is used purely as an app platform. Under HCL CCB, server PVUs are not counted separately (only users). Under IBM, if they have a Domino Utility Server for apps, they may still need PVU licensing for that server, in addition to user licenses for any user access. That could complicate things if, for example, the mail was user-licensed and the apps were PVU-licensed. In the mixed scenario described, it was likely all user-based.
Audit Defense Angle:
To defend in an audit (whether by IBM or HCL’s compliance team), have a clear report of active users. This could be a Domino log or a DLAU tool output (Domino License tracking tool) that shows several authenticated users over the last 30 days, etc. If you did reduce usage, show evidence of when those users were de-provisioned (for example, a change log or an HR exit list mapped to Domino). This demonstrates that you took proper action and are not knowingly keeping unused accounts. For any ambiguous accounts (such as service accounts), be prepared to explain their purpose and whether a license covers them.
If some accounts are just used for forwarding or data integration and not actual logins, perhaps your license agreement has a provision to not count them – if so, document that exception. Essentially, you want to walk auditors through your user management process to assure them that the number of users equals the number of licenses. If you have moved to HCL licensing, IBM wouldn’t audit Domino (HCL might, under their audit rights), but during any transition period, IBM could still review past usage.
Cost Optimization:
This scenario already highlights a cost-saving move: reclaim licenses from users who no longer use the system. That aside, consider whether those 500 remaining users really need all the functionality. HCL’s new licenses offer everything, but IBM had cheaper “messaging-only” licenses for users who only use email. If the mix of usage changed, perhaps a different mix of license types could save money (though with HCL consolidating to one type, that point might be moot going forward).
Additionally, if Domino usage is shrinking, a CIO might renegotiate for a smaller footprint or even look at third-party support instead of full support, if the environment is stable (though losing vendor support has its risks).
On the flip side, if Domino remains critical, it may be worth consolidating entirely to HCL’s model and potentially leveraging their cloud offering where licensing is part of the subscription – that could transfer some risk to HCL and simplify management (you’d pay per user per month or year, and HCL runs the service). The decision will hinge on whether Domino is strategic or legacy for the organization.
Scenario 4: Cloud Pak Integration of WebSphere & MQ
Context:
An enterprise is modernizing and decides to containerize some of its middleware. They choose IBM Cloud Pak for Integration for MQ and perhaps IBM Cloud Pak for Applications (or Hybrid Edition) for WebSphere, running on an OpenShift cluster. They still have some traditional deployments as well.
Licensing Approach:
In this scenario, they have bought a certain number of VPCs for Cloud Pak for Integration, which covers MQ (and potentially other integration products) in the container platform. Let’s say 50 VPCs. They deploy MQ queue managers in OpenShift, which consume, for example, 30 of those VPCs, calculated based on peak container usage.
The remaining 20 VPCs could be used for an integration broker or left as headroom. Separately, they have Cloud Pak for Applications VPCs for WebSphere Liberty containers. For any traditional deployments that haven’t been containerized yet, they continue to use PVU licenses. This means concurrently they have two license entitlements running: VPCs in the cloud pack and PVUs on legacy systems.
Key Considerations: Monitoring and Compliance:
Running Cloud Paks means you must install the IBM License Service on the OpenShift cluster. This tool will measure container usage and produce a report on VPC usage. It’s essentially the ILMT equivalent for containerized products. The organization needs to review those reports to ensure they do not exceed the purchased Virtual Private Clouds (VPCs). If they occasionally burst above 50 VPCs (perhaps scaling up at the end of the quarter), they either need to have purchased a buffer or be prepared to true up. IBM’s audits for Cloud Pak environments will revolve around those automated reports – manual counting is impractical.
At the same time, they cannot neglect the older PVU deployments. Now, there are two sets of tools (ILMT for VMs and License Service for containers) – maintaining both and consolidating a view is crucial. One risk is that if an application is moved from a VM to a container, but someone forgets to remove or decommission the old instance, you could inadvertently consume a license in both places for the same workload. Good DevOps practices and continuous configuration management can mitigate that.
Another consideration is the mix of products in a Cloud Pak: Cloud Pak for Integration includes multiple products. If you only use MQ, you might be missing out on some potential value, but if you start leveraging App Connect or API Connect, those will also consume the same VPC pool. This is fine as long as you size it accordingly, but it requires cross-team coordination, involving the integration team and the messaging team, who draw from the same license pool. Internally, treat the Cloud Pak VPCs as a shared resource – perhaps governed by a center of excellence that determines how many are allocated to each technology. Otherwise, you might find one team’s usage starves another or, worse, blows the budget.
Audit Defense Angle:
The good news in this scenario is that the tooling provides a lot of the evidence. For a container-based deployment, you would present the IBM License Service quarterly reports, which show peak VPC consumption and confirm it is within entitlement. It’s wise to archive those reports and also have screenshots or exports from the cluster showing which instances were running, to facilitate correlation. For the traditional side, the usual ILMT audit snapshots are needed.
One tricky part is that IBM might ask for reconciliation – e.g., “You bought 100 VPCs, show us how they are allocated.” You show 50 used in Integration, and maybe you have 50 unused (which is fine, you just haven’t deployed more yet). Or if you repurposed some PVU licenses into VPCs via conversion, show that contract paperwork. Essentially, clarity in how your entitlements map to installations remains crucial, even if some measurement is automated.
Cost Optimization:
Cloud Paks can be a double-edged sword from a cost perspective. They often come with a heavy price tag, but they consolidate many capabilities. If you fully utilize the Pak (i.e., use it for multiple products), you can realize cost savings versus buying each product’s PVUs separately. Also, containerization might lead to more efficient resource use (for example, you might run 5 MQ instances on one node that previously were on five separate small VMs, thus using fewer total cores). On the other hand, if you only use a small subset of the Pak and don’t use the rest, you might be overpaying compared to à la carte licenses.
CIOs should periodically review if their Cloud Pak investments are justified by utilization. One tactic is to right-size the Cloud Pak entitlement after a year of actual usage – maybe you initially over-provisioned to be safe. IBM tends to be flexible in letting you adjust (by buying more or sometimes reducing at renewal if not used).
Also, watch out for support costs: Cloud Pak support gives you all upgrades and support for included products, which is great, but if you keep some PVU licenses you’re also paying support on those – see if combining everything under the Pak support (or vice versa) is possible to streamline support fees.
Audit Risks and Defense Strategies
IBM software audits are a reality that CIOs must be prepared for. IBM aggressively protects its intellectual property revenue and regularly audits customers to ensure compliance.
An audit can be triggered randomly or due to specific risk factors, such as significant changes in your IBM usage or lapses in license tracking.
Below, we outline the main risks that audits uncover in WebSphere, MQ, and Domino environments, and provide strategies for audit defense, which begins long before you receive an audit notice.
Top Audit Risk Areas for IBM Middleware:
- Untracked Deployments: An auditor’s first step is often to compare the software discovered in your environment with what you have entitlements for. Undiscovered WebSphere or MQ instances (possibly set up by a department outside of central IT) will immediately be flagged as “unlicensed.” Domino user counts might be cross-checked against HR records or email records. A particular risk is if you have any IBM software running and have not deployed ILMT where required. IBM’s policy is that failure to run ILMT means they can consider your entire server capacity as needing licenses, which can dramatically inflate compliance gaps.
- Sub-Capacity Non-Compliance: Many IBM middleware installations utilize sub-capacity (virtualization) licensing. However, to qualify, IBM requires not just ILMT deployment but also that ILMT is functioning correctly and producing quarterly audit reports. If an audit finds that ILMT was never installed or was broken for the last year, IBM may claim you are out of compliance and owe full-capacity licenses. This often affects WebSphere, MQ, DB2, and other PVU products. It’s one of the most expensive audit findings because the delta between what you thought you needed (say 100 PVUs sub-capacity) and what IBM says you owe (maybe 400 PVUs full capacity) is huge.
- Edition Misuse: As discussed, using features from a higher edition on a lower edition license is another audit hotspot. IBM could ask for proof of what edition was installed. If you only bought WAS Base but an audit finds non-WAS components on your servers, they will demand that you purchase the corresponding non-WAS licenses. Similarly, for MQ, if you have MQ Advanced features enabled (e.g., AMS encryption, which is an Advanced feature) but only have MQ Standard entitlements, that’s a compliance issue. Domino audits might examine whether you used Enterprise server features, such as clustering, despite having only a lower Express license, etc.
- Excess Users: For Domino (and any user-based licenses), IBM auditors (or now HCL auditors for Domino specifically) will likely request logs or use tools to count the unique users. If your count exceeds entitlements, you’ll be found non-compliant. It’s not uncommon for audits to find “shelfware” users—people who left or duplicate accounts—pushing the count over the purchased number. IBM will typically bill for the difference and back support.
- Non-production environments: Auditors do include development and test servers in scope. If those weren’t licensed or not covered by a special entitlement, they will count them. Many audit reports surprise customers with “you have 10 extra WebSphere instances unaccounted for,” which turn out to be development systems that the team didn’t license separately. IBM’s stance is that unless it’s a free developer edition (which can be identified by version or SKU), a license is needed.
- Expired or Unsupported Versions: While using an old version isn’t a license compliance issue per se (licenses are typically perpetual for a version), if you stopped paying for support and continued using the software, IBM could argue that you are not entitled to upgrades or may be misusing the terms. Usually, audits focus on entitlements versus deployments, not whether you have support. However, running unsupported software is a business risk, as IBM might refuse to even audit a product that’s out of support until you renew, in order to then charge you for back support. It’s a bit tangential to compliance, but keep your support contracts in mind. Sometimes, organizations drop support to save money, only to get audited and be forced to buy back support, along with penalties, which wipes out those savings.
Audit Defense Strategies:
- Maintain an Internal License Audit Trail: The best defense is a good offense – conduct regular internal audits. At least once or twice a year, have your IT asset management (ITAM) team run a full reconciliation of IBM middleware. Use ILMT to generate a Sub-Capacity report and see if entitlements cover all PVU consumption. Have Domino admins produce an active user count and match it to licenses. By identifying discrepancies yourself, you can correct them (either by purchasing additional licenses or reducing usage) before IBM intervenes. Document these internal reviews; if audited, you can demonstrate to IBM that you actively manage compliance, which can sometimes influence their approach and show good faith effort.
- Ensure ILMT and License Tools are Running Properly: Given the criticality of ILMT to IBM audits, double-check that it is deployed everywhere it should be (on all VMware or virtualized servers with PVU software). Please update it to the latest version. IBM occasionally updates PVU tables and tool versions, and it expects you to have applied these updates. Set a calendar reminder to produce the quarterly ILMT reports and store them. Similarly, in container environments, check that the IBM License Service is configured and retaining data. If you find that ILMT was accidentally turned off on a server or missed, fix it immediately and have an explanation ready, as auditors may ask why data is missing for a period. In some cases, if ILMT wasn’t there, having historical data like VMware CPU assignment records or manual inventories might help plead your case, but it’s not a guarantee. It’s easier to avoid that debate by having ILMT evidence.
- Train and Communicate License Policies to Technical Teams: Often, audit issues arise because the people deploying or changing the software aren’t fully aware of the licensing implications. Conduct periodic training or, at the very least, issue guidelines for your middleware administrators. For example, publish a short “WebSphere License Use Policy” that states which features correspond to which licenses, and instruct that any changes (such as creating a cluster or enabling a feature pack) must undergo a license check. Similarly, educate the Domino team that every active person equals a license, so they are vigilant in user management. When teams know that BigFix/ILMT is scanning and that compliance is watched at the CIO level, they are more likely to pause before spinning up that extra MQ instance without asking. A culture of compliance can save a lot of pain in the long run.
- Centralized License Tracking and Procurement: Many compliance issues happen when different departments handle software independently. A CIO should centralize the oversight of IBM licenses. That doesn’t mean central IT must control everything, but there should be a single source of truth for how many licenses are owned and used. Use a SAM (Software Asset Management) tool or, at the very least, a spreadsheet that is updated whenever new IBM software is deployed or purchased. Tie procurement to deployment – e.g., you cannot deploy a new WebSphere server unless you confirm there is an available license or a purchase is made. Also, keep an eye on support renewal quotes. If IBM sends a renewal for 1000 Domino users and you know you only have 800 now, that’s an opportunity to adjust before paying unnecessary support (and also aligns with compliance).
- Simulate an Audit (Hire External Experts if Needed): It can be beneficial to have a third-party licensing expert do a mock audit. Firms that specialize in IBM licensing (including former IBM auditors or licensing partners) can often identify compliance issues you might miss. They can also tell you how IBM is likely to interpret ambiguous cases. This not only helps fix issues but also prepares you on how to respond if an audit happens. For example, an expert might point out that your ILMT is fine, but you overlooked a WebSphere add-on that you installed, which has a separate license metric. They should find it before IBM finds it.
- During an Audit – Be Organized, Transparent but Cautious: If you receive an audit notice, there are strategies in handling it. First, involve your legal and contract management team – an audit is a legal process governed by your contract’s audit clause. Respond within the required time and cooperate, but also manage the scope. IBM typically has auditors request a lot of data, such as server lists, user lists, and ILMT outputs. Provide what is requested, nothing more. Do not volunteer assumptions or interpretations; just factual data. It’s often wise to have a single point of contact, such as an IT asset manager, coordinate all responses to avoid inconsistent answers. Keep a professional tone and demonstrate your preparedness (e.g., “Here are the last four quarters of ILMT reports, as requested.”). If you have a Gartner analyst or licensing advisor service, use them for guidance and to sanity-check the auditor’s findings.
- Challenge and Negotiate Findings: It is common that auditors’ initial findings have errors or overcounts. Don’t be afraid to question their methods. For example, if an auditor counts 1,000 Domino users by scraping an NAB (Domino address book), but you know that 100 of those are service accounts, provide that clarification and documentation (perhaps those are marked as non-human accounts). If they claim a WebSphere instance is ND requiring a license, but you can prove it’s just Base with no ND features enabled, present that evidence. IBM’s auditors are not infallible; they may, for instance, count every PVU from ILMT, even if some are clearly for products that are no longer used – if you have removed the software but ILMT still shows it as installed last quarter, clarify that. Ultimately, any compliance gap that remains, you typically have to settle by purchasing the necessary licenses (often at list price, and sometimes with additional support or penalties). Negotiation here can sometimes waive penalties if you agree to a purchase quickly. Always review the final settlement figures with a fine-tooth comb or have an expert review it to ensure you’re not overpaying for something not required.
Special Mention – Audits after HCL Spin-off: For Domino specifically, since HCL now owns it, IBM audits on Domino may not occur (IBM can audit for the period when it was under IBM’s ownership, but now HCL will handle compliance for their licenses). HCL has been focusing more on selling new licenses than auditing, but that could change. In any case, maintain Domino compliance as diligently as you did when IBM owned it, because the contracts carry over.
Optimization Tactics for Cost and Compliance
Beyond avoiding compliance nightmares, CIOs should proactively seek to optimize IBM licensing costs. IBM software can be a substantial line item in IT budgets, and over-licensing “just to be safe” is not a financially prudent approach.
Here, we outline concrete tactics to right-size and optimize your IBM middleware licensing, which will both save costs and help you stay in closer compliance (since you’ll be aligning usage with your needs).
- Rightsize PVU Allocations: Treat CPU capacity as a controlled resource. Work with your infrastructure team to ensure that WebSphere and MQ servers are not oversized. Often, servers are given more cores than they truly need “just in case,” but each extra core might carry a hefty PVU cost. Use performance monitoring to identify the actual CPU utilization of your middleware servers. If an app never uses more than one core of CPU, running it on a 4-core VM is wasteful from a licensing perspective. You could reduce that VM to 2 cores (for headroom) and cut the PVU requirement in half. Similarly, if you have an underutilized physical server, consider consolidating multiple WebSphere instances onto fewer servers, but be mindful of fault domains. IBM licensing allows you to partition servers (soft partitioning via virtualization, or hard partitioning in some cases) – use those to your advantage to limit the number of cores accessible to IBM software. In cloud environments, choose instance sizes wisely: there’s no need to put an MQ broker on an 8-vCPU cloud VM if a 2-vCPU VM is sufficient. The cumulative effect of rightsizing can significantly lower the total PVUs you need to license. Just be careful to document any intentional limitations (e.g., a VMware policy that caps vCPUs for a VM) in case you need to show an auditor that, yes, the WebSphere VM had eight vCPUs on the host but was hard-limited to 4 vCPUs in configuration – thus you licensed four vCPUs.
- Leverage Non-Production Entitlements: As discussed earlier, IBM provides free or low-cost options for non-production use. Ensure your teams are using IBM MQ Advanced for Developers (free) for all MQ development and testing. For WebSphere, encourage the use of WebSphere Application Server for Developers (a free edition of WAS Base for development) or Liberty in development. Liberty is freely usable in developer mode, and even in production, there is an open-source Open Liberty, although with some differences. If your organization has an Enterprise License Agreement that covers development and testing, ensure everyone knows to deploy under that umbrella rather than using ad-hoc licenses. Also consider IBM’s Cloud Sandboxes or trial licenses for short-term needs – for example, if a team wants to evaluate a new MQ feature, they can use a trial license rather than installing from your licensed pool. By strictly separating production licenses from non-production ones, you avoid the “leakage” of licenses into test environments. Some IBM products come with a ratio of free non-production use (e.g., purchasing Domino licenses sometimes allows a separate development server without additional cost); check your specific agreements for such perks. And don’t forget to tag or label non-production systems in ILMT. ILMT can mark a server as “development,” which doesn’t exclude it from needing a license, but it helps with internal tracking and justifying why it’s there.
- Reclaim and Reuse Licenses: Regularly audit your license usage to find any “shelfware” or allocated but unused licenses. For PVU licenses, this could mean a server that has been decommissioned, but the PVUs are still counted in your entitlement. You may be able to reuse those on a new server without needing to purchase more. For user licenses like Domino, reclaiming means identifying users who no longer need access. Establish a process to harvest licenses from departing employees: when HR notifies IT of a termination, release the associated license. Some organizations even implement a license reclaim program, where, if a user hasn’t logged in for, say, 90 days, they are flagged and possibly removed, with business sign-off. That ensures you’re not paying annual support for users who don’t use the system. Another area is identifying redundant software: for example, if you have both IBM MQ and another messaging system running in parallel, and one is underutilized, consider standardizing and removing the other to reduce overall costs. Reclamation can also involve cancelling unnecessary maintenance: for instance, if you had 1000 PVUs of WebSphere but now only use 800 PVUs, at the next renewal you can attempt to reduce your support/license count to 800 (IBM rules on partial support drops can be tricky, but it’s possible especially if it’s a distinct part number or if you have excess that’s not deployed).
- Consolidate and Simplify Domino Footprint: Domino environments in some companies have grown organically over the years and may have multiple servers (mail clusters, app servers, etc.) that are now underutilized due to reduced usage. Consider consolidating Domino servers – eliminating each server could save PVU licenses (in the case of server licensing) or at least reduce operational overhead. If you have multiple domains or partitions, consolidating them can also reduce the total number of required servers. With HCL’s licensing, you no longer pay per server (just per user). However, reducing servers can still help indirectly by reducing support costs (hardware, admin effort) and focusing on your user counts. Also, suppose a significant portion of Domino usage is just for email, and you’ve moved to a different email solution. In that case, Domino can be entirely decommissioned or moved to a cheaper model, such as an archive server with a limited license. Consolidation might mean moving Domino apps to a single server or cluster that is fully licensed and shutting down the others. Just be careful to follow IBM/HCL rules for decommissioning – e.g., keep data accessible for audit proof if needed for a past period, but not as active users.
- Evaluate Cloud Paks or Bundled Licensing for Cost Efficiency: While we’ve cautioned about Cloud Paks from a compliance perspective, they can sometimes offer cost advantages if you’re using multiple IBM products. For example, if you currently license WebSphere, MQ, and IBM Integration Bus separately, the combined support might be more cost-effective than simply getting a Cloud Pak for Integration license to cover them all in one metric (especially if you plan to modernize on containers). IBM often prices Cloud Paks competitively to encourage adoption. A strategic move for a CIO is to approach IBM with a proposal: converting separate licenses into a single bundle (such as Cloud Pak or an ELA) at a discount. IBM might be amenable, and it could give you more flexibility. However, always analyze the numbers – you don’t want to buy a bundle that includes stuff you don’t need. If you go this route, also invest the time to use the modern features you’re paying for (e.g., if Cloud Pak for Apps provides Transformation Advisor, use it to plan modernization – you’ve paid for it!). Utilizing all components increases the return on investment (ROI) of the license spend.
- Take Advantage of Special IBM Pricing Programs: IBM offers various programs, such as Idle Standby licenses (as we covered, e.g., MQ standby at 20% off the cost). Ensure you’re using them where applicable – it’s an 80% cost savings for disaster recovery (DR) systems. IBM also sometimes offers sub-capacity licensing, even without ILMT, for specific situations. This is achieved via an exception called the “Container Affidavit” for certain container scenarios, but these are edge cases and are usually not worth foregoing ILMT. If you’re a large IBM customer, you might negotiate bundled discounts or credits – for instance, commit to a certain spend and get extra licenses at a reduced rate to cover growth. Another tactic is to consider third-party support. For Domino, some customers have moved to third-party vendors for support at a lower cost once the product became stable. However, HCL’s new features might entice you to stay current. For WebSphere/MQ, third-party support is available but less common. Still, if you plan not to upgrade and just run a stable version, it’s an option to save on maintenance fees, although there’s a trade-off in not receiving direct IBM support or upgrades.
- Monitor and Govern Usage Continuously: Optimization is not a one-time project. Implement ongoing governance, for example, by creating a monthly report for the CIO that shows current license utilization compared to entitlement for major IBM products. This keeps visibility high. If you notice a trend – say, MQ usage creeping up month by month – you can address it. Maybe it’s a new project ramping up, so plan your budget for additional licenses or see if they can use existing capacity more efficiently. On the Domino side, watch the user trend line; if it’s declining with people moving off, you might be able to drop licenses in the future, but ensure they stop using it. Encourage a mindset in the IT organization that licensing is part of the capacity planning for any system, just like you wouldn’t deploy servers without considering hardware costs. Don’t deploy software without considering license costs.
- Keep Software Updated (for Better Terms or Efficiencies): Surprisingly, keeping your software up to date can indirectly optimize your licensing. Newer versions of WebSphere and MQ often have better performance, meaning you can complete the same work with fewer cores, potentially requiring fewer PVUs. Also, IBM’s License Metric Tool must be up to date – using the latest versions of products ensures that ILMT recognizes them accurately. On the Domino side, HCL Domino v12/v14 features a new licensing model that may be simpler and potentially more cost-effective if you were previously paying for multiple IBM license types. By upgrading, you often qualify for the new model.Additionally, IBM has been known to change PVU ratings when hardware changes (though thePVU table is stable now, if new chip families come out, they might adjust PVUs). Using newer hardware can provide betterperformance per PVU. All this is to say, part of optimization is technological: use the best software and hardware combination to meet your needs with a minimal license footprint.
By employing these tactics, CIOs can often significantly cut down their IBM software expenses year over year, while also maintaining a cleaner compliance position. This is essentially “doing more with less” in the IBM licensing world – a hallmark of good IT stewardship.
Recommendations for CIOs
Strategic and Tactical Steps to Optimize IBM Licensing
Finally, we distill the above insights into clear recommendations. These are the steps and best practices a CIO should champion to reduce compliance risk and optimize costs for IBM WebSphere, MQ, and Domino licensing:
- 1. Establish a License Governance Program: Treat software licensing as an ongoing governance issue. Set up a dedicated team or designate an owner, such as an IT Asset Manager, for IBM license compliance. Have regular check-ins (quarterly is ideal) to review IBM software deployments, using ILMT and other tools. Make this team responsible for maintaining the single source of truth for entitlements vs usage.
- 2. Deploy and Maintain Compliance Tools (ILMT/License Service): Ensure the IBM License Metric Tool is installed on all applicable servers and that it’s regularly updated and scanning. Similarly, for any containerized deployments, configure the IBM License Service. Schedule the automated generation of compliance reports quarterly. This not only keeps you compliant with IBM’s sub-capacity terms but also gives you early warning of any usage overshoot. Treat these tools as mandatory infrastructure for any IBM middleware you run.
- 3. Enforce “No Deployment Without License” Policies: Institute a policy that no new instance of WebSphere Application Server or MQ is deployed, and no new Domino users are added, unless license availability is verified. Integrate this check into your change management or CI/CD pipeline. For example, a server provisioning script for MQ could have a step to decrement a license count or flag if none are available. Curb the habit of “shadow IT” spinning up software under the radar by requiring all IBM software installations to go through an approved process.
- 4. Educate Stakeholders on License Implications: Conduct training sessions for architects, system engineers, database administrators, and even procurement and finance teams on IBM licensing basics. People designing HA architectures should know that an active-passive MQ requires two licenses, one of which is discounted. Developers choosing an app server for a new project should know when to use Liberty (lighter, possibly cheaper) versus when they need full WAS ND (and the associated costs). By making licensing part of the architectural discussion, you prevent costly designs or, at least, budget for them appropriately.
- 5. Optimize Before You Buy More: When demand for capacity increases (more users, more throughput, new projects), resist the reflex to simply buy more licenses without analysis. First, evaluate if you can reallocate existing licenses or improve efficiency. Can that new application run on an existing WebSphere server rather than a new one? Can you increase a server’s workload instead of adding another? If you truly need to scale up, consider whether a different licensing model, such as Cloud Pak, would be more cost-effective at scale. Only purchase additional licenses once you’re sure the current ones are optimally used.
- 6. Keep Entitlements Documentation Organized: Maintain up-to-date documentation of all your IBM entitlements, including PVU counts purchased, user licenses purchased, proofs of entitlement, and the terms (such as which version or product each covers). Store contracts, IBM Passport Advantage agreements, and support renewal quotes in a readily accessible repository. In case of an audit or even an internal review, having these at your fingertips is invaluable. It also helps when renewing or negotiating – you know exactly what you have and what you might drop or need.
- 7. Leverage Vendor and Third-Party Expertise: Don’t go it alone if you’re unsure. IBM licensing is complicated and constantly evolving (e.g., changes following the HCL spin-off, new Cloud Pak models). Use your IBM account manager or IBM’s Licensing specialists to clarify doubts (keeping in mind they have a sales motive, but they can explain terms). Gartner analysts or independent licensing advisors can provide guidance tailored to your specific scenario and keep you updated on changes, such as new licensing models or audit trends. Having an expert review your IBM deployment annually can pay for itself if they find ways to reduce costs or avoid a penalty.
- 8. Plan for Audits as Inevitable: It’s wise to assume you will be audited at some point. Incorporate audit readiness in your IT planning. For example, perform a “mock audit” annually, as mentioned, and maintain an audit response plan (including who would coordinate, what data to gather, etc.). This way, if the letter arrives, your team isn’t scrambling; you’ll respond confidently and accurately. Also, maintain a professional relationship with IBM – sometimes proactively self-reporting a need to true up (and then purchasing the licenses) can help stave off a more serious audit, as it demonstrates a compliance mindset.
- 9. Consider Consolidation and Modernization from a Licensing Perspective: Align your IT strategy (cloud migration, data center consolidation, application modernization) with licensing optimization opportunities if you plan to move workloads to the cloud or containers. Factor in the switch to VPC licensing. If you plan to replace Domino with another solution, weigh the cost of maintaining it for archive purposes vs. migrating that data. When modernizing apps, possibly moving from WebSphere ND to Liberty can save future costs. In short, when making strategic tech changes, always include a workstream to evaluate the software licensing impact – it can significantly influence the project’s ROI.
- 10. Maintain an Ethical Compliance Stance: Last but not least, set the tone that your organization values proper licensing. This isn’t just to avoid penalties; it’s about ethical IT management. Using software beyond the scope of your license is essentially using something you haven’t paid for. By promoting a culture of compliance, you encourage teams to be honest and prompt about reporting mistakes. For example, if someone accidentally uses an ND feature on a Base license, they should feel comfortable bringing it up so it can be corrected, rather than hiding it. This culture will serve you well in the long run, both in vendor relationships and in establishing trust within the organization.
By following this playbook, CIOs can turn IBM middleware licensing from a risky cost center into a well-managed asset. The goal is to maximize the value your organization gets from IBM products by using them fully and smartly, while minimizing waste and risk by avoiding overbuying or falling out of compliance.
With the right oversight, you can support your company’s growth and innovation on these middleware platforms without fear of audits or budget overruns. In essence, treat IBM licensing management as seriously as you treat security and uptime – it’s part of responsible IT governance in the enterprise.
