How IBM audits follow mergers turns on a feature of IBM licensing that buyers often miss: the licensable quantity depends on how workloads run, not only on what is installed. IBM counts much of its software in processor value units, and the count is sensitive to the cores a product can use. A merger moves workloads across combined infrastructure, which moves the counts, and if the sub capacity position is not maintained throughout, IBM can revert to a far more expensive full capacity calculation. This page explains the mechanics, as a child of the cluster on M&A software audit risk.
How IBM audits follow mergers through the processor value unit metric
IBM licenses a large part of its middleware and data products in processor value units, or PVUs. The principle is that a customer licenses the processing capacity available to a product, calculated from the processor type and the number of cores the software can run on. In a stable estate this is manageable, because the hardware does not change. A merger destabilises it. Workloads are moved, servers are consolidated, and virtual machines are repacked onto new hosts, and each of those changes can alter the cores a product can reach. The PVU requirement follows the cores, so a consolidation that improves utilisation can quietly raise the licensable quantity. IBM, aware that ownership changed and the estate is in flux, has a clear reason to review.
Sub capacity licensing and the ILMT requirement
The most important concept for a buyer is sub capacity licensing. IBM allows many products to be licensed against the virtual cores a product actually uses rather than the full physical capacity of the server, which can reduce the requirement dramatically on a virtualized estate. The relief comes with a condition: the customer generally must deploy the IBM License Metric Tool, known as ILMT, and report sub capacity usage regularly. If ILMT is not deployed, not current, or does not cover part of the estate, IBM can disqualify the sub capacity treatment and calculate the licenses on full physical capacity. After a merger, the combined estate often contains hosts that ILMT never tracked, which is precisely where full capacity exposure appears.
Where the merged estate breaks the position
The points of failure in a merged IBM estate are specific and recurring. The target may never have deployed ILMT, so its servers enter the combined estate with no sub capacity record at all. The acquirer may run ILMT but not extend it to the newly acquired hosts in time. Workloads may move onto clusters that ILMT does not yet see, breaking the chain of evidence IBM requires. And entitlement records, scattered across two organisations, may not add up to the deployed footprint. Any one of these can be enough for IBM to challenge the sub capacity treatment. The remedy is unglamorous: extend ILMT coverage to the entire combined estate as early as possible and keep the reporting continuous through the integration, not after it.
| Area | What IBM checks | Why a merger raises it |
|---|---|---|
| ILMT coverage | Every host running PVU products reported | Target hosts never tracked, or added late |
| Sub capacity eligibility | Continuous, current sub capacity reporting | Reporting gaps during integration |
| PVU counts | Cores a product can use by processor type | Workloads repacked onto denser hosts |
| Entitlements | Owned PVUs against deployed PVUs | Records split across two organisations |
| Bundled products | Components deployed beyond bundle rights | Inherited stacks with undocumented use |
Key takeaways
- IBM counts much of its software in processor value units that follow the cores a product can use.
- A merger moves workloads across infrastructure, which moves the PVU counts even when functionality is unchanged.
- Sub capacity licensing needs ILMT deployed and reporting, or IBM can revert to full capacity pricing.
- Untracked target hosts and reporting gaps during integration are the most common ways the position breaks.
- Extending ILMT to the whole combined estate early is the single most effective protection.
The bundling trap and inherited stacks
A further IBM risk in acquisitions is bundling. Many IBM products ship as parts of larger stacks, where certain components are licensed only for use within a specific solution. Inside an inherited estate, administrators may have deployed a bundled component as a standalone tool, or used it beyond the rights the bundle grants. Because the deployment looks identical whether or not it is licensed correctly, only a review of usage against the bundle terms reveals the gap. A buyer that inherits IBM middleware should treat the bundle rights as part of diligence, because this is exactly the kind of latent item that becomes a finding once IBM counts it, a pattern shared across the cluster and developed in how latent under licensing becomes an eight figure claim.
How a buyer gets ahead of IBM
The defence is to protect the sub capacity position from the first day of integration. Before consolidation moves a single workload, the buyer should confirm that ILMT covers every host across both estates, verify that sub capacity reporting is current, and reconcile owned PVUs against deployed PVUs. Where the target never ran ILMT, deploying it and establishing a clean baseline is the priority. Where consolidation is planned, the licensing impact of the target host design should be modelled before workloads move. With a maintained position and a complete record, an IBM review becomes a confirmation rather than a surprise, and the buyer keeps the sub capacity treatment that makes the estate affordable. The general approach to assembling that evidence is set out in building an audit defensible license position after close.
Recommendations for buyers
- Extend ILMT to the whole estate first. Cover every host running PVU products before consolidation begins.
- Keep sub capacity reporting continuous. Avoid the gaps during integration that let IBM revert to full capacity.
- Reconcile owned against deployed PVUs. Combine entitlement records from both organisations into one position.
- Model consolidation before moving workloads. Check how the target host design changes the PVU counts.
- Review bundle rights on inherited stacks. Confirm components are used within the rights the bundle grants.
The Passport Advantage angle and renewal timing
Most IBM licensing sits inside Passport Advantage, the programme that governs entitlements, subscription and support, and the audit rights IBM relies on. Two features of it matter in a merger. First, the agreement carries verification rights that let IBM check compliance, so the audit is not a surprise tactic but a contractual entitlement the buyer accepts when it inherits the estate. Second, subscription and support renewals are a natural reconciliation point, because lapsed support on part of the estate or a renewal that does not match the deployed footprint both reveal the gap. A merger often leaves two Passport Advantage sites with different anniversary dates, different price levels, and different product sets, and consolidating them is both an opportunity to rationalise and a moment IBM will look closely at the numbers. A buyer that maps the two sites, aligns the renewal dates deliberately, and confirms support coverage across the whole estate enters that conversation in control rather than reacting to a quote that doubles as a compliance check.
How IBM audits follow mergers, in one line
How IBM audits follow mergers comes down to a metric that follows the hardware and a relief that depends on a tool. Processor value units move when a merger moves workloads, and sub capacity treatment survives only if ILMT covers the whole combined estate without a gap. A buyer that extends ILMT early, keeps reporting continuous, and reconciles entitlements turns a potential full capacity claim into a maintained, manageable position. We do that work on the buyer side only, paid solely by the acquirer.