IBM requires licensing for virtually every installation of its software, including development, test, QA, staging, and disaster recovery environments. This guide explains IBM’s non-production licensing rules in detail, covering the hot, warm, and cold standby definitions for disaster recovery, the 90-day temporary use migration policy, sub-capacity requirements through ILMT, Cloud Pak VPC provisions for non-production deployments, and practical strategies for minimising costs while maintaining full compliance.
IBM’s fundamental licensing rule is that every installation or instance of IBM software requires a licence entitlement, regardless of whether the environment is classified as production, development, testing, QA, staging, or any other designation. Unlike some vendors that offer blanket non-production exemptions, IBM treats a running installation as a licensable instance whether it processes live business data or serves only internal testing purposes.
This principle applies across all IBM licence metrics — PVU, VPC, user-based, and employee-count licensing — and is the single most important rule to understand when planning non-production environments. Failure to licence non-production installations is one of the most common compliance findings in IBM audits, often because organisations assume that development and test environments are exempt by default.
The practical implication is that when budgeting for any IBM software deployment, organisations must account for all environments where the software will be installed — not just production. A typical enterprise application deployment might include production, development, system integration testing, user acceptance testing, staging, performance testing, and disaster recovery environments. Each of these may require licensing unless a specific contractual exemption, product-level allowance, or IBM policy applies.
Understanding which exceptions exist and how to leverage them is essential for controlling costs without creating compliance exposure. For IBM licensing fundamentals, see: IBM Licence Information — Everything You Need to Know.
Development and test environments typically require the same licensing as production unless a specific exception applies. Organisations have several options for covering these environments, each with different cost and compliance characteristics.
The most straightforward approach is using standard production licences — purchasing additional PVUs, VPCs, or user entitlements to cover non-production installations at the same per-unit cost as production. This is the default and most common approach, but it is also the most expensive since there is no discount for the non-production nature of the usage. For PVU-based licensing, this means licensing every core allocated to the non-production virtual machine or container at the same PVU rate as production. For user-based licensing, it means counting every user who accesses the non-production system against the same entitlement pool.
IBM does offer specific non-production or development licence SKUs for certain products, typically at a reduced cost compared to production licences. These non-production SKUs carry restrictions — they cannot be used to process live business data, cannot serve end users, and are limited to internal development and testing activities. Availability varies by product and is not universal across the IBM portfolio.
When purchasing any IBM software, organisations should explicitly ask whether a development or test licence SKU exists for the specific product, as using these where available can significantly reduce non-production licensing costs. Additionally, IBM provides trial licences (typically 30 to 90 days) at no cost for evaluation and proof-of-concept purposes. These are full-featured but time-limited — continuing to use the software after the trial period expires without purchasing a licence constitutes non-compliance regardless of the environment classification.
A financial services organisation runs IBM Db2 on eight cores in production (licensed at PVU rates) and maintains a four-core user acceptance testing environment. Both environments require licensing under IBM’s rules.
The organisation could purchase additional PVUs at standard rates for the test environment, use a Db2 Non-Production licence SKU if available at reduced cost, or use Db2 Developer-C edition (free for development use with capacity limitations). The choice depends on the test environment’s requirements — Developer-C may suffice for development but might not support the data volumes needed for realistic UAT.
Key principle: Always account for non-production licensing needs in the initial budget. Many compliance issues arise when organisations licence only production and overlook test installations that auditors will count.
For disaster recovery and high availability configurations, IBM uses a temperature-based classification system that determines whether a standby instance requires separate licensing. Understanding these definitions precisely is critical because the classification directly determines whether the organisation needs to purchase additional licences for DR infrastructure — a decision that can represent hundreds of thousands of dollars in licensing costs for large IBM estates.
A hot standby server runs simultaneously with production, receiving live data updates in real time and capable of taking over workload instantly (active-active or active-passive with immediate failover). IBM requires full licensing for hot standbys because the software is actively running and can serve the production workload at any moment.
In an active-active cluster where both servers handle live requests, both must be fully licensed at their respective capacities. There is no discount or reduced rate for hot standby instances — they are treated as production installations for licensing purposes.
A warm standby server is installed with the IBM software running, but it is not actively handling production requests or processing business transactions. It may receive periodic data synchronisation or log shipping to maintain readiness for failover.
IBM’s general position is that warm standbys do not require separate licensing because they are not carrying a production workload. However, if the warm system runs the software (even idle), strict interpretation might consider that licensable use. Organisations should obtain written confirmation from IBM for their specific warm standby configuration.
A cold standby server is powered off, or the IBM software is not started until a disaster occurs. It is essentially an installed copy or a machine ready for deployment that remains inactive during normal operations.
IBM does not require licensing for cold standbys because the software is not running or consuming resources. When activated for production use during a disaster or DR test, IBM expects the organisation to either transfer existing licence entitlements to the DR server or limit usage to the temporary period allowed under IBM’s policies.
Organisations should formally classify every DR instance as hot, warm, or cold in their architecture documentation, licence inventory, and CMDB records.
During an IBM audit, the ability to demonstrate that a DR server was classified as cold or warm — supported by monitoring data showing it was not running production workloads — is the primary evidence that justifies the absence of a separate licence. Without this documentation, auditors may default to treating all installed instances as requiring full licensing.
IBM recognises that strict per-installation licensing can be impractical during migrations, infrastructure refreshes, and disaster recovery testing. Several built-in policy provisions allow temporary concurrent use without requiring additional licence purchases.
90-day temporary additional use (migration). IBM’s Passport Advantage agreement includes a temporary additional use provision that permits running two instances of the same software concurrently for up to 90 days during migration, data centre relocation, hardware upgrade, or similar infrastructure transition activities. After 90 days, the original instance must be decommissioned, or both instances must be licensed. Extensions beyond 90 days require IBM’s explicit written approval.
DR testing allowances. Organisations that maintain cold or warm (unlicensed) DR systems need to periodically activate them to validate failover procedures. IBM’s policies generally allow short-term DR testing activation without triggering a licensing requirement, provided the testing is documented, limited in duration (typically a few days), and does not involve serving actual production workloads beyond the scope of the failover test.
Licence reassignment during disaster. When a genuine disaster occurs and the DR site is activated, IBM expects the organisation to transfer licence entitlements to the DR servers or have equivalent entitlements available. IBM is generally reasonable about licensing during unplanned emergencies and will not penalise organisations for using software on secondary sites during a genuine disaster, provided the situation is normalised promptly.
Negotiated non-production allowances. During large purchases or ELA negotiations, organisations can negotiate explicit non-production provisions — such as one non-production installation per production licence at no additional cost, a percentage discount for non-production licences, or a blanket DR allowance. These negotiated provisions, when documented in the contract, provide definitive audit-safe coverage. For IBM ELA negotiation guidance, see: IBM ELA Renewal Service.
Non-production environments can multiply the total cost of IBM software ownership if not actively managed. A production deployment that requires licensing across development, system integration testing, user acceptance testing, staging, performance testing, and DR environments could effectively require five to seven times the production licence count if each environment is independently licensed at full capacity.
| Strategy | Approach | Potential Savings |
|---|---|---|
| Environment rationalisation | Consolidate multiple non-production environments onto shared infrastructure; eliminate environments no longer actively used | 30–50% reduction in non-production licence count |
| Right-size non-production | Allocate fewer cores to non-production VMs than production; use sub-capacity licensing via ILMT to licence only allocated cores | 40–70% per-environment reduction versus production sizing |
| Developer editions | Use free or low-cost developer editions (e.g. Db2 Developer-C) for development environments where capacity limits are acceptable | Up to 100% savings for qualifying development use |
| Cloud Pak VPC provisions | Deploy non-production workloads under Cloud Pak VPC licensing with reduced capacity allocations; some Cloud Paks allow non-production at fractional VPC counts | 20–50% versus full VPC allocation |
| Consolidate test environments | Run multiple teams testing on a single shared instance with logical separation rather than separate licensed instances per team | 60–80% reduction when consolidating 3–5 team environments into one |
| Cold standby for DR | Classify DR environments as cold standby (software not running) to avoid separate licensing requirement entirely | 100%: no licence required for cold standby |
Combined strategies can reduce non-production licensing costs by 50–80% compared to licensing every environment at full production capacity.
IBM sub-capacity licensing allows organisations to licence only the cores allocated to virtual machines running IBM software rather than all physical cores on the host server. This requires deployment of the IBM Licence Metric Tool (ILMT) across every server where sub-capacity rights are claimed. This requirement applies equally to production and non-production environments.
If an organisation claims sub-capacity licensing for a non-production virtual machine but does not have ILMT deployed on the host server, IBM policy requires full-capacity licensing for that installation. This can potentially multiply the licensing requirement by a factor of five or more depending on the ratio of allocated to total physical cores.
Despite this requirement, many organisations deploy ILMT only on production hosts and overlook non-production servers. This creates a specific and well-known audit risk: IBM audit teams identify a non-production VM running IBM software on a host without ILMT, apply full-capacity licensing rules, and generate a compliance finding that can be orders of magnitude larger than the actual sub-capacity usage.
The solution is straightforward. Deploy ILMT agents on all physical and virtual servers where IBM software is installed, regardless of environment classification. ILMT also provides the benefit of discovering unknown or forgotten IBM installations in non-production environments, which helps maintain accurate inventory. For IBM audit defence guidance, see: IBM Audit Defence Service.
IBM Cloud Paks use Virtual Processor Cores (VPCs) as the licensing metric and offer some specific provisions for non-production environments that can reduce costs compared to traditional per-product licensing. Under Cloud Pak licensing, the total VPC pool covers all deployments across all environments, and non-production deployments consume VPCs from the same pool as production.
Some Cloud Paks allow organisations to designate certain deployments as non-production, which may consume fewer VPCs than equivalent production deployments. For example, IBM Cloud Pak for Integration allows non-production designations that count at reduced VPC rates against the total entitlement pool.
Because Cloud Pak VPC licensing is based on total allocated capacity at any given time across all environments, organisations can optimise by right-sizing non-production container deployments to the minimum resource allocation needed for testing purposes. Allocating two VPCs to a non-production deployment rather than the eight VPCs used in production reduces the licence consumption proportionally.
The VPC model also enables dynamic scaling: non-production environments can be scaled down or suspended when not in active use, reducing the peak concurrent VPC consumption that determines the licensing requirement. For Cloud Pak licensing in detail, see: IBM Analytics and Data Platform Licensing.
One server active and fully licensed; one server powered off or with IBM software not started. The passive node accepts no traffic and runs no IBM processes. When failover occurs, the licence transfers to the activated node.
This is the most licensing-efficient DR configuration. Organisations must ensure the passive node genuinely remains cold \— no background processes, no scheduled batch jobs, no data synchronisation that involves running the IBM application. Monitoring data confirming the server was inactive provides audit evidence.
One server active and fully licensed; one server running IBM software in an idle or synchronisation-only state. The warm node receives data replication or log shipping but does not process business transactions or serve users.
IBM generally does not require separate licensing for warm standbys, but organisations should confirm this for their specific product and configuration. The distinction between warm and hot can be nuanced \— if the warm node performs any processing beyond passive data receipt, it may cross into licensable territory. Written IBM confirmation is strongly recommended.
Both servers run IBM software and can handle production workloads simultaneously, even if one normally handles a reduced share. Active-active configurations require full licensing on both servers at their respective capacities.
This includes database clusters with read-write capability on both nodes, application server clusters with load balancing across both nodes, and geo-redundant deployments where both sites serve live traffic. There is no DR discount for active-active configurations.
Non-production compliance is one of the most frequently overlooked areas in IBM licence management, and audit findings in this area are common because organisations focus their licensing governance on production environments while treating non-production as an afterthought.
The foundation of non-production compliance is a complete inventory that includes every installation of IBM software across all environments \— production, development, test, QA, staging, training, sandbox, and disaster recovery. Discovery tools should scan the entire network for IBM installations, including developer workstations, cloud instances, container environments where IBM software may have been deployed for temporary purposes and forgotten, and CI/CD pipeline environments where ephemeral IBM instances may be spun up for automated testing.
Each discovered installation should be classified by environment type, matched against licence entitlements, and either confirmed as licensed or documented as qualifying for an exception (cold standby, trial period, developer edition, negotiated non-production allowance).
This inventory should be reviewed quarterly to catch new installations deployed without licensing approval, decommissioned environments that still have IBM software installed, developer workstations where IBM products were installed for a project and forgotten after completion, and changes in DR classification that affect licensing requirements \— such as a warm standby reconfigured to handle batch processing that now qualifies as hot.
Organisations should implement a formal software request process requiring licensing impact assessment before any IBM product is installed in any environment, ensuring non-production installations are tracked from deployment rather than discovered retrospectively during audits. For IBM licensing assessment support, see: IBM Licensing Assessment Service.
IBM non-production licensing requires the same rigour and systematic management as production licensing. The fundamental principle is straightforward: every installation requires a licence unless a specific exception applies.
The cost optimisation opportunity lies in understanding precisely which exceptions apply (cold standby provisions, developer editions, trial periods, negotiated non-production allowances, Cloud Pak VPC provisions) and structuring non-production environments to take maximum advantage of them while maintaining documentation that demonstrates compliance to auditors.
The most effective approach combines environment rationalisation (eliminating unnecessary non-production environments), right-sizing (allocating minimum necessary capacity to reduce PVU or VPC requirements under sub-capacity licensing), comprehensive ILMT deployment across all environments, formal DR classification with supporting documentation, proactive lifecycle management (decommissioning IBM installations when projects complete), and negotiated contractual provisions secured during ELA and Passport Advantage renewals.
Organisations that implement these practices systematically typically achieve 50 to 80 percent reductions in non-production licensing costs compared to the default approach of licensing every environment at full production capacity, while simultaneously improving their audit readiness position and reducing the risk of unexpected compliance findings.
For comprehensive IBM licensing guidance, see: IBM Licensing Knowledge Hub. For IBM negotiations support, see: IBM Negotiations Service.
Yes. IBM requires licensing for all installations of its software, including development, test, QA, and staging environments. There is no blanket exemption for non-production use. Organisations must either purchase standard licences, use product-specific non-production SKUs (where available at reduced cost), use free developer editions (where available and capacity limits are acceptable), or negotiate explicit non-production allowances in their IBM agreements. The licensing metric (PVU, VPC, user-based) applies identically to non-production installations unless a contractual exception exists.
No. IBM generally does not require separate licensing for cold standby servers where the IBM software is not installed in a running state or where the server is powered off during normal operations. When the cold standby is activated during a disaster, the organisation is expected to transfer existing licence entitlements to the DR server or operate within the temporary use provisions. Organisations should document the cold standby classification and maintain monitoring evidence confirming the server was inactive for audit purposes.
IBM's Passport Advantage agreement includes a temporary additional use provision that allows organisations to run two instances of the same software concurrently for up to 90 days during migration, hardware upgrade, data centre relocation, or similar infrastructure transition activities. After 90 days, the original instance must be decommissioned or both instances must be licensed. Extensions beyond 90 days require IBM's explicit written approval.
Yes. If the organisation claims sub-capacity licensing for IBM software running in virtualised non-production environments, ILMT must be deployed on the host servers. Without ILMT, IBM's policy requires full-capacity licensing, which means licensing all physical cores on the server regardless of the cores allocated to the virtual machine. This can increase the licensing requirement by five times or more.
IBM Cloud Paks use Virtual Processor Core (VPC) licensing, where the total VPC pool covers all deployments across all environments. Some Cloud Paks allow non-production deployments to be designated at reduced VPC consumption rates. Because VPC licensing is based on total concurrent capacity, organisations can optimise by right-sizing non-production container deployments to minimum resource allocations and scaling them down when not in active use.
IBM's policies generally allow short-term DR testing activation without triggering a full licensing requirement, provided the testing is documented, limited in duration, and does not involve serving actual production workloads beyond the scope of the failover validation. Organisations should document DR test schedules, durations, and scope internally to demonstrate that any observed system activity was planned testing.
Hot standby involves running IBM software actively with the capability to handle production workloads at any time, which requires full licensing. Warm standby involves running IBM software in an idle or synchronisation-only state (receiving data replication but not processing business transactions), which generally does not require separate licensing. The distinction is critical because misclassifying a hot standby as warm can create significant audit exposure. Organisations should document their specific configuration and obtain written IBM confirmation.
Redress Compliance provides independent IBM licensing assessment, audit defence, ELA renewal advisory, and contract negotiation. No IBM partnerships, reseller relationships, or referral arrangements.