Contents
Key takeawaysHow MQ is licensedMQ versus MQ AdvancedSub capacity and ILMTWhere Advanced is neededContainers and the applianceWhat we see in auditsContract terms to ask forWhat to do nextFAQIBM MQ is licensed per core in PVU or VPC. Sub capacity with current ILMT reports, and MQ Advanced bought only where its features run, decide most of what a virtualized MQ footprint costs.
- Two metrics, one rulebook. Older MQ entitlements count Processor Value Units, newer ones count Virtual Processor Cores, and holding both without a clear mapping creates audit findings.
- Sub capacity depends on evidence. Licensing only the virtual cores given to MQ requires ILMT installed within 90 days and reports no more than a quarter apart.
- Missing reports mean full capacity. Without ILMT data, IBM counts every physical core on each host where MQ runs.
- Advanced is a per queue manager decision. Managed file transfer, AMS, RDQM and Native HA need MQ Advanced, and most queue managers use none of them.
- Standby and client installs cost less or nothing. Automatic failover nodes take a cheaper HA Replica license, manual failover nodes and client only machines need none.
- Containers use License Service. MQ on OpenShift counts the CPU limits on its containers and reports through IBM License Service instead of ILMT.
- The appliance caps the bill. The MQ Appliance swaps per core counting for a fixed hardware unit, and the M2004 is now the current model.
How is IBM MQ licensed today?
IBM MQ on distributed platforms is licensed per processor core, in Processor Value Units (PVU) or Virtual Processor Cores (VPC). Both allow sub capacity licensing, where you pay for the cores MQ can use rather than the whole server, if ILMT reports back the claim. The MQ Appliance is the exception, sold as a hardware unit.
Older MQ entitlements are mostly PVU, which rates each core by processor type. The IBM PVU table puts most two socket Intel Xeon and AMD EPYC cores at 70. Newer entitlements tend to be VPC, a flat count of one unit per virtual core. IBM lists both options on the IBM MQ product page.
| Metric | How it is counted | Sub capacity | Where you see it |
|---|---|---|---|
| PVU | Cores times the PVU rating for the processor type | Yes, with ILMT | Legacy entitlements, much of the installed base |
| VPC | One unit per virtual core, or per physical core on an unpartitioned server | Yes, with ILMT on virtual machines and IBM License Service in containers | The current model, and the unit for containers and Cloud Pak for Integration |
| Appliance | A fixed hardware unit with MQ firmware installed | Not applicable | Predictable cost for a dedicated messaging tier |
MQ for z/OS is outside this guide. It follows mainframe metrics, which our MSU and MIPS guide covers.
Which metric should new deployments use?
New MQ deployments generally land on VPC, which is simpler to count and the only metric for containers. Check the ratio IBM offers per product before swapping existing PVU lines. On larger Power servers rated at 100 or 120 PVUs per core, that ratio decides whether a conversion saves money. Our PVU to VPC transition guide works through the cases.
How do you reconcile mixed PVU and VPC entitlements?
Map every queue manager to its host, its edition and the entitlement line that covers it. A queue manager licensed under PVU running on a host your records count in VPC creates a reconciliation gap, and that gap is what an auditor looks for first.
- One inventory. List each installation with host, cores, edition, metric and Passport Advantage part number.
- Separate pools. Keep PVU and VPC entitlements in separate columns of your records and never net one against the other.
- Tag conversions. Where IBM converted a PVU line to VPC, keep the conversion document next to the entitlement it changed.
- Check the order history. Your IBM Passport Advantage account shows which metric each part was sold under.
The IBM Audit Is the Sales Call: Timing and ILMT Hygiene Decide It
What is the difference between IBM MQ and MQ Advanced?
MQ Advanced is the higher priced edition. It adds managed file transfer, Advanced Message Security and the replication based high availability options to the base messaging product. Base MQ covers queue managers, clustering, the clients and standard TLS security, which is enough for most application messaging.
IBM sold MQ Telemetry, Advanced Message Security and Managed File Transfer as separate products until 2015, then folded them into MQ Advanced. The replication features came later. The Advanced entitlement now covers these:
- Managed File Transfer (MFT). Agent based file movement over MQ, with audit and scheduling.
- Advanced Message Security (AMS). End to end signing and encryption of message content.
- Replicated Data Queue Managers (RDQM). High availability and disaster recovery replication on Linux.
- Native HA and cross region replication. Replicated queue managers without shared storage.
- MQ Telemetry. MQTT connectivity for devices.
Which MQ components need no entitlement of their own?
IBM's license measurement methodology for MQ excludes the MQ client from license counts, so a machine with only the client installed needs no MQ license. For MQ Advanced, the methodology also lists the MFT agent, MQ Telemetry and the IBM Aspera fasp.io Gateway as components that do not by themselves require an entitlement when installed alone.
IBM MQ Advanced for Developers is free, but its terms limit it to internal development and unit testing on a developer machine. Shared test, performance and integration environments therefore need a paid license, usually a non production part.
How are standby and non production queue managers licensed?
A failover server that takes over automatically, and has no other active MQ use, needs a High Availability Replica license, the part IBM used to sell as Idle Standby. If failover is manual and the server has no other active use, IBM's methodology says no license is required.
Mark each installation so ILMT classifies it correctly. The command setmqinst -l hareplica -e yes flags a replica, and setmqinst -l nonprod -e yes flags a non production installation for non production entitlements. Our guide to IBM non production licensing covers how those parts are priced.
IBM Audit Defense Kit
The metric, ILMT and edition checks to run on MQ and the rest of your IBM software before an auditor does.
Get the white paper →How does sub capacity licensing cut IBM MQ cost?
Sub capacity allows you to license only the virtual cores allocated to MQ on a virtualized host. IBM requires the IBM License Metric Tool to claim it. Without current ILMT data, IBM licenses MQ at the full physical capacity of the host. On a large virtualized cluster the gap runs to thousands of PVUs, as the example below shows.
The conditions sit in the Passport Advantage sub capacity terms:
- Deploy ILMT on time. Install it within 90 days of the first sub capacity deployment, or lose sub capacity rights.
- Cap allocations. Pin MQ virtual machines to defined vCPU counts and to a named host group inside the cluster.
- Report quarterly. Quarterly is the longest gap IBM allows between reports, so schedule a monthly review and a missed run does not break compliance.
- Keep the evidence. Retain the reports and supporting records for at least two years for audit.
Our ILMT sub capacity guide covers deployment and the common scanner gaps.
Worked example: six MQ virtual machines on two hosts
Say MQ runs on six virtual machines of 4 vCPUs each, spread across two VMware hosts. Each host has two 16 core Xeon processors, so 32 cores rated at 70 PVUs. The table compares the claim with and without ILMT evidence.
| Basis | Cores counted | PVUs at 70 per core | VPCs |
|---|---|---|---|
| Sub capacity, ILMT current | 24 (6 VMs at 4 vCPUs) | 1,680 | 24 |
| Full capacity, ILMT missing or stale | 64 (2 hosts at 32 cores) | 4,480 | 64 |
| Gap IBM can claim | 40 | 2,800 | 40 |
The full capacity figure is about 167 percent above the sub capacity one. If those six machines can migrate across a four host cluster, the full capacity count doubles to 128 cores, which is why host groups matter as much as the tool.
Do you need IBM MQ Advanced on every queue manager?
No. Most queue managers do plain messaging and never touch MFT, AMS or replicated high availability. Licensing Advanced across every queue manager when only some use those features is a common source of waste on MQ. Fix it in three steps:
- Identify which queue managers actually use managed file transfer, AMS, RDQM or Native HA.
- License Advanced only on the cores behind those, and base MQ on the rest.
- Re benchmark at renewal as feature usage changes.
On units alone, the split is simple to size. A hypothetical 80 VPC MQ footprint where 24 VPCs sit behind queue managers using AMS or MFT needs 24 VPCs of Advanced and 56 of base. The saving is 56 times the per VPC price gap between the two editions on your quote.
Why we advise against buying Advanced everywhere for simplicity
Resellers often say that buying MQ Advanced across the board simplifies licensing and protects you at audit. We disagree. In roughly 15 of the 25 plus IBM environments we benchmarked, Advanced covered every queue manager when only a fraction used managed file transfer or Advanced Message Security. The simplicity argument hid a steady overpayment.
A single edition also does nothing for audit exposure, because IBM audits core counts and reporting evidence whatever the edition mix. Split base and Advanced by actual feature use and put part of the saving into keeping ILMT current. Advanced everywhere makes sense only when most queue managers really do run Native HA, RDQM or AMS.
Current ILMT reporting, more than any premium edition, decides whether IBM bills MQ at allocated cores or at full host capacity.
How is IBM MQ licensed on containers and OpenShift?
MQ in containers on OpenShift or Kubernetes is licensed in VPC, counted from the CPU limits allocated to the MQ containers. IBM publishes the container terms in its MQ documentation.
- Count allocated cores. License the CPU limits set on the MQ containers. A container with no limit can be counted at the capacity of its worker node.
- Check Cloud Pak for Integration. Your MQ entitlement may already come through a Cloud Pak for Integration purchase, which our Cloud Pak licensing guide explains.
- Run IBM License Service. Container deployments are reported by IBM License Service, not ILMT, and IBM's standard MQ operator sets the annotations it reads. Custom deployments must set those annotations by hand.
Applying full host or full cluster licensing to container deployments is a frequent overpayment. Missing CPU limits or missing License Service data is the usual cause, and both are fixable before an audit.
What changes with the MQ Appliance?
The MQ Appliance puts MQ capacity on a fixed hardware unit, so there are no per core software counts and no sub capacity tracking. That suits a dedicated messaging tier where predictable, capped spend matters more than flexibility.
Check the model before you plan around it. IBM will withdraw the M2003 from marketing on October 14, 2026, and supports it to September 30, 2031. The M2004 replaces it, with two 16 core processors: the M2004A has all 32 cores enabled, and the M2004B has 8 cores with a software upgrade to full capacity.
What have we seen in recent IBM MQ audits and renewals?
Across roughly 25 to 35 IBM engagements Fredrik Filipsson advised between 2024 and 2025, sub capacity compliance was the largest single factor in MQ cost. Three patterns came up again and again.
- Stale ILMT data. Environments without current ILMT reports faced full capacity charges that inflated exposure by 30 to 200 percent.
- Advanced everywhere. MQ Advanced was licensed on every queue manager when only 20 to 40 percent of them used its features.
- Mixed metrics. PVU and VPC entitlements that did not reconcile to deployments surfaced in 1 in 3 audits.
If IBM has opened a review, our white paper on how to settle an IBM audit without overpaying covers the settlement stage, and the IBM audit process guide covers each step before it.
How to check your own MQ position before IBM does
- Run dspmqver on every server. It shows the version and installation details. Then look for Advanced use: MFT agents, AMS policies listed by dspmqspl, and RDQM or Native HA configurations.
- Pull the ILMT audit snapshot. Check the last full quarter for MQ entries, the processor type and PVU rating per host, and any servers reported at full capacity.
- Review the setmqinst flags. Confirm that replicas and non production installations carry their flags, or ILMT will count them as production.
- Check License Service. For each OpenShift cluster, confirm reports exist for every quarter since MQ went live in containers.
- Reconcile to Passport Advantage. Compare deployed cores by edition and metric with the entitled quantities on each part.
What the IBM account team will say, and what to say back
- "Standardize on MQ Advanced and the compliance risk goes away." Reply that audit risk comes from missing ILMT evidence, and ask IBM to price base and Advanced separately by queue manager.
- "Your ILMT reports have gaps, so we have to use full capacity." Ask which periods and servers are affected, and offer to supply the records that cover them before any figure is agreed.
- "Move to Cloud Pak for Integration and you are covered for containers." Ask for the entitlement ratio for MQ and which other Cloud Pak products you would actually deploy before comparing it with stand alone VPC.
- "The PVU to VPC conversion is like for like." Ask for the ratio per product and per server family in writing, and compare the annual support cost of each line before and after.
What contract terms should you ask for at an MQ renewal?
Ask for terms that fix the basis of the count as well as the price. These are the ones that matter most on MQ:
- Edition split by queue manager. Separate line items for base MQ and MQ Advanced, so you can reduce one without touching the other.
- Written conversion ratios. Any PVU to VPC conversion stated per product in the order itself.
- High Availability Replica parts. Replica pricing for standby nodes, so failover capacity is never quoted as full production.
- A remediation window. Time to fix an ILMT gap before IBM applies full capacity, which keeps a reporting error from becoming a license claim.
- A price hold for growth. A capped unit price for MQ cores added during the term, so growth after a reduction is not billed at a new list price.
Put these requests to IBM with the inventory in hand, three to six months before the renewal date. Our MQ pricing brief covers where MQ quotes usually land.
What to do next
- This month. Inventory every MQ queue manager with its edition, entitlement metric and host.
- Before the next ILMT cycle. Separate PVU and VPC entitlements clearly in your records and tag every conversion.
- This quarter. Deploy or refresh ILMT, retain quarterly reports, and set the setmqinst flags for replicas and non production installations.
- Before renewal. License MQ Advanced only where managed file transfer, AMS or replicated high availability is used.
- For containers. Verify that every MQ container has CPU limits set and that License Service is reporting for each cluster.
- At every renewal. Re benchmark editions and sub capacity, and ask for the contract terms above in writing.
Want a second opinion on your IBM position? Our IBM licensing consultants are ex IBM insiders who now work only for buyers.
Frequently asked questions
How is IBM MQ licensed?
Per processor core on distributed platforms, in Processor Value Units for older entitlements or Virtual Processor Cores for newer ones. Both allow sub capacity counting with ILMT. The MQ Appliance is the alternative, with capacity bought as a fixed hardware unit, and MQ for z/OS follows mainframe pricing.
What is the difference between PVU and VPC for MQ?
A PVU entitlement weights each core by processor type, so the same core can cost 70 or 120 units depending on the server. A VPC entitlement counts one unit per virtual core whatever the hardware. Most new MQ purchases, and all container deployments, use VPC.
Why is ILMT mandatory for IBM MQ?
ILMT is the evidence IBM requires for a sub capacity claim on virtual machines. Passport Advantage terms make it a condition of the lower count, so after an unreported quarter IBM can bill every physical core on the affected hosts for that period.
How much does sub capacity save on MQ?
It depends on how small the MQ virtual machines are relative to their hosts. In our engagements, losing sub capacity through missing ILMT data raised exposure by 30 to 200 percent. Dense clusters with a few small MQ machines sit at the top of that range.
Do we need MQ Advanced everywhere?
Usually not. Only 20 to 40 percent of queue managers in the environments we reviewed used Advanced features. Buy Advanced for the cores behind those queue managers, base MQ for the rest, and recheck the split each renewal as teams adopt or drop MFT and AMS.
How is MQ licensed on OpenShift or Kubernetes?
In Virtual Processor Cores, counted from the CPU limits on the MQ containers and reported by IBM License Service. The entitlement can be stand alone MQ or part of Cloud Pak for Integration. Missing CPU limits are the usual reason container counts come out too high.
What is the MQ Appliance licensing model?
You buy the appliance as a hardware unit with MQ firmware installed, so there are no per core software counts and no ILMT tracking for it. The M2004B ships with 8 of its 32 cores enabled and can be upgraded, so you can start smaller and pay for capacity later.
What triggers an IBM MQ audit finding?
Most findings come from gaps in ILMT reporting, PVU and VPC entitlements that do not match deployments, and Advanced features running on queue managers licensed as base MQ. Standby nodes and test servers without their setmqinst flags also show up as unlicensed production.