IBM Non-Production Licensing
Enterprises often focus on production licenses, but IBM’s licensing requirements for non-production environments, including development, testing, QA, and disaster recovery, are equally crucial for compliance and cost optimization.
This article provides CIOs and IT asset managers a clear understanding of IBM’s rules and best practices for non-production licensing.
We cover scenarios like setting up development/test servers, using IBM software in staging environments, and maintaining DR (backup) servers. Importantly, we explain IBM’s concepts of hot, warm, and cold standby in disaster recovery and how licensing applies to each.
Readers will learn strategies to minimize costs (for example, leveraging IBM’s allowance for cold backups and the 90-day migration rule) while ensuring compliance outside the production realm.
Licensing Development and Test Environments
IBM generally requires a software license for every installation or instance of its software, including development and test environments, unless a specific exemption or special license type exists.
Key points to consider:
- Using Regular Licenses: Companies often use their normal production licenses to cover dev/test installations. For example, if you have an IBM WebSphere Application Server instance for production and another for testing, each needs a license entitlement. Some IBM license metrics are user-based or PVU-based, regardless of environment, meaning you count users or PVUs in test the same way as production.
- Non-Production Specific Licenses: IBM does offer specific non-production or “Authorized User – Dev/Test” licenses for some products. These often come at a reduced cost but with restrictions (e.g., not allowed to process live business data, only for internal testing). Availability varies by product – a notable example is IBM Cloud Pak sandbox or trial licenses that allow limited non-prod use. Always inquire if a dev/test license SKU exists when purchasing IBM software; it could save cost if you qualify.
- IBM Sandbox and Trial Periods: For experimentation or short-term testing, IBM provides trial licenses (typically 30-90 days) at no cost, which are full-featured but time-limited. For instance, IBM might allow a 60-day trial of an analytics software for evaluation in a test environment. Leverage these for proof-of-concept. Just be careful: continuing to use the software without purchasing is prohibited once the trial expires.
- Cloning Production for Testing: Often, testing involves copying production data or setups. Suppose your test environment mirrors production (just not handling live end-users). In that case, licensing requirements technically remain the same as if it were production, unless IBM’s terms say otherwise. There’s no blanket “50% discount” or similar for test systems – you have to license them or negotiate something with IBM. Some IBM customers negotiate a test environment allowance in their contract (for example, an extra set of licenses at no charge or a discount specifically for non-prod use). This is something to consider during large deals or ELA negotiations.
Example: A bank has four cores of IBM Db2 database running in production and four cores in a non-production environment for user acceptance testing. Both environments require licenses under PVU licensing.
The bank could choose to fully license all eight cores. Alternatively, if offered, the bank might buy four cores of a lower-cost “Db2 Non-Production” license for the test environment. If no such SKU exists, they might also use regular licenses for testing.
It’s critical to account for these needs in budgets. Many compliance issues arise when companies license only production and forget that test installations count, too.
IBM’s Hot, Warm, and Cold Standby Definitions (Disaster Recovery)
For disaster recovery (DR) and high availability setups, IBM uses a temperature analogy to define licensing requirements:
- Hot Standby: A hot backup server runs simultaneously with production, receiving live data updates and can take over instantly (essentially an active-active scenario). IBM requires full licensing for hot standbys since the software is actively running and can serve the workload at any time (even if it is just in replication mode). In practice, if you have an active cluster of two servers running IBM software in parallel, both must be fully licensed.
- Warm Standby: A warm server is installed and running, but not actively handling requests unless production fails. It may mirror data or be kept in sync periodically. It’s quicker to activate than cold, but normally idles in processing. IBM’s policy generally has been that warm standby does not require a separate license as long as it’s truly not serving a production workload. However, the details matter: if the warm system is turned on and the software is running (even idle), IBM’s standard rules might consider that “use.” IBM’s official stance, as per their guide, is that warm and cold configurations do not require a license in general, but with caveats. It’s wise to get clarity in writing for your specific setup. Often, IBM’s License Information documents for a product will explicitly allow one cold or warm backup installation without charge.
- Cold Standby: A cold server is powered off, or the software is not started until a disaster occurs. Essentially, it’s just an installed copy (or a machine ready to install) that is not running unless needed. In most cases, IBM does not require licenses for cold backups, since the software isn’t active. When you activate it for production use (during a disaster or a DR test), IBM expects you to promptly license it or limit its use to a temporary period, as allowed (see next point about temporary use).
DR Example: A retailer runs an IBM Middleware application on a production server. They maintain a second server as a DR backup. It syncs with nightly data, but its application is kept offline (cold) unless disaster strikes.
Under IBM rules, they do not need to purchase a second license for that backup instance, provided it remains unused except in emergencies. Suppose they kept it in sync (warm) to enable quicker failover.
In that case, IBM still generally doesn’t charge for that scenario, but licensing is required if they route traffic to it concurrently (hot). The retailer documents that the DR server is a cold standby in their records in case of an audit.
IBM’s Temporary Use and Backup Policies
IBM recognizes that strict licensing for every copy can be burdensome in DR or migration situations, so there are some built-in exceptions/allowances to take advantage of:
- 90-Day Temporary Use for Migrations: IBM’s Passport Advantage agreement includes a Temporary Additional Use policy. This permits you to run two instances of the software (like old and new environments) concurrently for up to 90 days, for migration, data center move, hardware upgrade, etc., without needing extra licenses for the second instance during that period. For example, if you are migrating an IBM Cognos server to new hardware, you can run the old and new in parallel testing for up to 90 days. After 90 days, the old one must be decommissioned, or you must license both if you keep both running. CIOs should plan major migrations within this 90-day window or coordinate with IBM for an extension if needed (extensions are possible in special cases, but require IBM approval).
- Testing Your DR Environment: Many businesses want to periodically start up their DR systems to ensure they work (simulating a failover test). If your DR setup is cold or warm (thus unlicensed normally), you might wonder if starting it up for a test violates compliance. IBM’s policies generally allow short-term testing of DR systems. A common guideline is keeping such tests under a certain duration (for example, a few days) and not using them for actual production load beyond testing. It’s wise to inform IBM in writing when you plan a DR test, or at least document the test timeline and scope internally. During an audit, if logs show the DR environment was active, you can show it was during a planned test within the allowed policy (IBM’s official guide doesn’t state a specific hour/day limit for tests, but the 90-day rule might implicitly cover one-time needs).
- Non-Production License Discounts: Although not formally in policy, IBM sales often provide discounted licensing for non-production environments when negotiating deals. They might bundle a 50% discount on QA/test environment licenses, or include several free dev/test licenses if you purchase prod ones. These are negotiation points rather than standard policy. If you get such concessions, have them written into the contract or purchase order to avoid confusion later (auditors will go by what entitlements you own on paper).
Cost Optimization Strategies for Non-Prod
Non-production environments can multiply the cost of software if not managed. Here’s how to keep costs in check:
- Environment Rationalization: Not every project needs a full stack of IBM software in dev, test, staging, etc. Assess how many environments are truly necessary. Maybe development and testing can share a single environment or use scaled-down instances (fewer cores, less capacity), which, in PVU terms, means fewer licenses are needed. For user-based licensing, perhaps only certain testers need access, not the entire user base. Scaling non-prod environments smaller or limiting user access can reduce license counts.
- Use Cheaper Editions for Dev/Test: IBM often offers different editions or license types that are cheaper but sufficient for non-production. For example, IBM might have a community edition or developer edition of a tool (sometimes even free) that could be used for development work. These often have limitations (like watermarks, lower performance, or not allowed for production data). They can save a lot if they meet your dev/test needs. An example is using IBM Db2 Developer-C edition instead of a full Db2 Enterprise license (Developer-C is free for development use with limits on cores/usage). Always ensure that using such editions aligns with their license terms.
- Leverage Cloud for Test/Dev: Consider using IBM’s cloud services or lighter-weight containerized deployments for non-production. IBM Cloud (or AWS/Azure with IBM software images) can sometimes be more cost-effective for transient testing environments, especially if you can shut them down when not in use (pay-as-you-go). IBM’s licenses in containers via Cloud Pak might allow deploying dev/test instances at reduced VPC counts (IBM has introduced the concept that non-production deployments of Cloud Paks might consume fewer license units). For example, IBM Cloud Pak for Integration allows you to designate certain deployments as non-production, costing fewer VPCs in your entitlement count. Check if such provisions exist and take advantage of them.
- Consolidate Test Environments: If multiple teams or applications use the same IBM software, see if their testing can be consolidated on one shared instance instead of each having its own. While separation is sometimes needed, consolidation can drastically cut duplicate license needs. For instance, rather than each of 5 dev teams running their own IBM WebSphere test server (5 licenses), maybe run a single shared test server where they each have separate test domains, requiring just one license (with potentially more capacity, but still likely less than five separate servers).
- Scheduling to Reuse Licenses: If using floating licenses or tokens (as discussed in the previous article) in non-prod, you can schedule testing so that you don’t need to license peak usage for all teams simultaneously. For example, if European testers use the system in the morning and U.S. testers at a different time, the same floating license pool could serve both at different times. This might avoid needing double the licenses for two regions’ testing teams. It requires coordination but can save money.
Ensuring Compliance in Non-Production
Compliance in non-production is often overlooked. Some tips to ensure you don’t get caught off guard in an audit:
- Maintain an Inventory: Document all installations of IBM software, including those “not in production”. It’s easy to forget a QA server or a developer’s local VM with IBM software installed. Use discovery tools to scan for IBM installations in your network, and make sure each is accounted for in your license count or is identified as a trial (with evidence of IBM’s trial authorization).
- License Library for DR: Keep clear records of which licenses cover your DR instances. If you rely on policy (no license needed for cold standby), keep architecture diagrams and failover documentation that classify each instance as hot/warm/cold. During an audit, you may need to explain your DR setup. Showing you have a well-architected DR plan with clearly defined standby types lends credibility that you’re following IBM’s rules.
- Regular Compliance Drills: Just as IT might do DR drills, do a licensing compliance drill for your non-prod environments. For example, simulate an IBM audit internally: can you quickly produce the proof that your dev/test servers are either licensed or qualify as unlicensed cold backups? Are your administrators aware that installing an IBM product for a test requires going through asset management for a license? Building this discipline avoids the common audit finding: “We found 10 instances of IBM software in test environments with no corresponding license.”
- Isolate Trial Software: If using any IBM trials or developer editions, isolate them to avoid accidental use beyond their intent. For instance, don’t mix trial-licensed software in the same environment as production data – an auditor might argue it was being used for real work. Use trials on separate machines or mark them. Remove or purchase them once the trial period ends.
- Negotiate Bundled Non-Prod Rights: If you have a large IBM agreement, negotiate for written non-production rights upfront. For example, include a clause that allows one non-production installation per production license at no additional cost or a blanket allowance for cold DR. IBM sometimes agrees to such terms for big deals to simplify things. Having it in the contract means pointing to the clause during audits and clarifying any findings. Without it, you rely on a generic policy, which can be open to interpretation.
Disaster Recovery Scenarios and Licensing
Let’s delve a bit more into how to approach some common DR setups with IBM software:
- Active/Passive Cluster: One server active (licensed), one passive (idle). This is classic hot/cold. You license only the active node. The passive node should not accept traffic or processing. If a failover happens, you switch the license to that node, or simply know that now that node is the licensed active one, and the other becomes passive. IBM is fine with this one-for-one as long as both aren’t actively running production load simultaneously.
- Periodic DR Drills: Suppose you activate your DR site twice a year and run from there for a week (perhaps for compliance or to offload during maintenance on the primary site). In that week, technically, both sites might be running (even if the primary is in maintenance, it might not be fully off). To be safe, either schedule a complete switchover (primary off, DR on, so still one active at a time) or get a short-term license for that period if both might be on. If needed, IBM sells short-term licenses (or again, the 90-day rule could be interpreted to cover planned DR use). It’s best to ensure no concurrent active use beyond testing allowances. Document these activities as non-production testing.
- Geo-Redundant Active-Active (Hot/Hot): This is tricky – if two active data centers handle live load (for example, an active-active database replication where both serve read/write), IBM expects both to be licensed. Sometimes, companies overlook the fact that their “DR” is active-active. Unfortunately, there’s no discount for that scenario in standard terms; you need full licensing for both. In such cases, one strategy is to consider sub-capacity licensing if possible (maybe each runs at half capacity) or explore if IBM offers a special deal for a secondary site (not common, but negotiating doesn’t hurt).
- Cloud Disaster Recovery: Some enterprises use cloud (IBM Cloud or others) as a DR target, only spinning up IBM software in the cloud when needed. If you have a bring-your-own-license (BYOL) arrangement, the same rules apply – you can keep images ready (no license consumed until activated). If disaster strikes, you could port your licenses to the cloud instances. If using IBM’s own Disaster Recovery as a Service, check the terms – IBM might include the licensing in the service cost for idle DR instances until failover. Clarity here can ensure you’re not double-paying.
Recommendations
For CIOs/CTOs managing IBM licenses in non-production contexts, consider these recommendations:
- Map Your Environments: Create a map of all environments (Prod, Dev, Test, QA, Staging, DR) for each IBM software. Mark those that are licensed and rely on an exception (like cold DR). This visual aid helps auditors and internal teams communicate where licensing is and isn’t covered.
- Formalize DR Classifications: Clearly define internally what constitutes a cold, warm, or hot standby and ensure IT operations adhere to it. For instance, if a “warm” standby accidentally starts processing a batch job occasionally, it might cross into “hot” territory and need a license. Formal instructions should say that warm/cold systems must not be used for active processing except for testing failover.
- Budget for Non-Prod in Advance: When approving a new IBM software purchase, always budget for production licenses and any necessary non-prod. It’s easier to negotiate and get approval for that up front than to come back later during implementation and ask for more because “we forgot the test environment.” It also avoids cutting corners, such as using unlicensed installations due to budget constraints.
- Use IBM’s Guides and Get Confirmation: IBM publishes licensing guides for specific scenarios (like the PDF excerpt we saw on Non-Production and DR). Use them to educate your team and even during audits to show you follow IBM guidance. Don’t hesitate to ask IBM for a written clarification if something is ambiguous. For example, email your IBM rep: “We have a QA environment for WebSphere identical to prod – do we need separate licenses or can we use our prod licenses under any test allowance?” Getting a response (and keeping it) can be evidence of due diligence.
- Monitor Non-Prod Usage: If possible, use monitoring to ensure non-prod environments aren’t unintentionally serving production. For instance, no external users should access test systems, and transaction volumes should be low. If you spot heavy usage on a system that’s supposed to be non-prod, investigate – someone might have pointed a live workload there by mistake. Licensing aside, that could be a risk. From a licensing view, heavy sustained usage on a “test” system might raise flags in an audit that it was a production instance.
- Plan for Audits with DR in Mind: When preparing for an IBM audit, consider how you’ll demonstrate compliance for DR and test systems. Have architecture diagrams ready, failover documentation that matches your claim (e.g., “Server B is cold standby – see, it’s powered off in this monitoring screenshot”). Auditors appreciate clear, honest explanations of environmental roles. If you proactively provide this context, you can often avoid misunderstandings that lead to compliance issues.
- Retire Unused Environments: It’s common for projects to spin up a test environment and then forget about it after go-live. Periodically do housekeeping – if a test or dev instance isn’t needed, shut it down and uninstall the IBM software. This reduces risk (security and compliance) and potentially frees up licenses if they were counted. A quarterly review of all instances can catch these and ensure your licensing reflects current usage, not old leftovers.
- Explore IBM Cloud Sandboxes: IBM and third-party vendors sometimes offer sandbox environments for learning and development (for example, IBM might have a cloud-based trial environment for certain products). If appropriate, use these instead of deploying your own licensed instance for training or exploratory development. It’s often free or included in support subscriptions (IBM Software Access Catalog for partners, etc., provides some of this). It can offload the need to license local dev instances for tinkering or training purposes.
Read IBM Floating and Token-Based Licensing: Maximizing Shared License Models.
FAQ
Q: Do we need separate QA/test server licenses if it mirrors production?
A: Generally, unless you have an agreement or the product has a special test license. IBM requires licenses for all installations. It should be licensed if your QA server runs the IBM software, even for internal testing. Some customers cover this by allocating some of their purchased PVUs or user licenses to non-prod. Others negotiate test allowances. Always verify – don’t assume non-production use is free.
Q: IBM documentation says warm/cold standbys don’t need licenses. How do I ensure our standby is considered warm or cold?
A: IBM’s general stance is that warm/cold backups are not separately charged because they are not actively carrying a workload. To ensure your standby is viewed as warm/cold, it should not be accessible to end-users or running actual production transactions. It can run and sync data (warm) or turn it off (cold). If an audit happens, show that any usage on it was either for syncing or failover testing. Keep it out of load balancers or user DNS, except when it becomes the primary due to an incident.
Q: We have an IBM WebSphere ND cluster with three active nodes and a fourth idle for failover. Should we license the fourth?
A: In an ND cluster, if the 4th node is truly idle (cold) and only starts when another fails, you likely do not need a separate license for it. You should, however, ensure your WebSphere licenses are based on the capacity of the active nodes. When the 4th takes over, the license is transferred as it replaces one of the others. It’s good practice not to run all four concurrently beyond testing. If you ever have all four running (even briefly) for extra capacity, that requires licensing for all.
Q: Can we temporarily use our licenses on a DR site during an emergency without an extra purchase?
A: Yes. IBM allows you to reassign licenses to a DR machine as part of disaster recovery. If a disaster happens and you activate your DR site, you are expected to transfer the license entitlement or have equivalent licenses there (for hot). But practically, IBM isn’t going to penalize you for using your software in an unplanned emergency on a secondary site, as long as once things stabilize, you either return to normal or true-up if the DR becomes the new prod. Communicate with IBM after a disaster if your DR will be running long-term – they tend to be reasonable in such situations, often giving a grace period.
Q: How do IBM Cloud Paks handle non-production environments?
A: IBM Cloud Paks (which use Virtual Processor Cores, VPCs, as the metric) sometimes include provisions for non-production. For instance, IBM Cloud Pak for Data might allow a certain number of lower-cost or free VPCs for dev/test clusters. Also, some Cloud Pak licenses allow usage of an instance for development without consuming full capacity counts (like counting a smaller fraction for non-prod deployments). These rules are specific to each Cloud Pak; you’d need to check the terms. But generally, IBM has recognized the need for flexibility – e.g., they might let you deploy a non-production environment using the same pool of VPC licenses but with an understanding that it should be small relative to prod. It’s best to explicitly confirm with IBM or in the license info document for that Cloud Pak.
Q: We want to use IBM software in our software development pipeline (CI/CD) for testing. Do those ephemeral instances need licenses?
A: If you spin up IBM software (like an IBM MQ instance or an IBM DB2 instance) temporarily in a pipeline (say for running automated tests) and then destroy it, it technically was an installation/instance during that time. IBM doesn’t have a specific policy for ephemeral containers or instances yet, so by the letter, even those need licensing if they exceed any trial allowances. However, many companies handle this by using developer edition licenses (if available) for such ephemeral use or by counting the maximum concurrent instances that might run and covering that with licenses. One approach is to ensure no more than 2 test instances run simultaneously, then purchase two licenses for that purpose. Containerized deployments via IBM Cloud Pak might simplify this, since the license is based on total VPC used at any given time across all environments.
Q: Can I use my production license on a development server when it’s not being used?
A: This is a common question, like “floating” a license between prod and dev. Generally, IBM licenses are not floating; they’re tied to a machine, user, or capacity. You cannot simply “move” it freely back and forth unless you reallocate the software. However, if you have an unused capacity in production (like extra PVU capacity not utilized), you could install a dev instance using that headroom. However, that’s tricky and not officially sanctioned – an auditor would count both if they’re installed. It’s better to formally allocate some of your entitlements to dev (e.g., of 100 PVUs bought, say 20 PVUs are designated for dev machines) or get separate dev entitlements. Remember, licenses aren’t typically used concurrently across environments; each installation is considered a potential use.
Q: Are there any license metrics that inherently cover non-production use?
A: Some IBM metrics like User Value Unit (UVU) or Employee count licensing implicitly cover all use by those users or within that scope, regardless of environment. For example, if IBM licenses something per employee count, those employees can use the software in any environment. Another case: if you license an IBM middleware by PVUs on a server and that server hosts multiple environments (like logical partitions for dev/test), as long as it’s the same physical machine licensed, you might be covered for all partitions on that machine. Always confirm metric definitions. However, typically, metrics don’t distinguish environments; they focus on capacity or users, which means non-prod counts, too.
Q: We found old IBM software installed on a developer’s PC that was used for a project, but forgotten. What should we do?
A: Immediately include it in your inventory and determine if it’s properly licensed. If not, uninstall it or obtain a license. Old forgotten installations are risky in audits. The best approach is to have a policy that developers must get approval to install IBM software, even for short-term use, so that it can be tracked. Clean up and remind the team of the process if it’s already happened. Being proactive here can prevent a small compliance gap from turning into a larger issue if auditors find it running (even if not used, an installed instance can count as needing a license depending on the product and audit team).
Q: How does IBM ILMT factor into non-production environments?
A: IBM’s License Metric Tool (ILMT) is mainly required for sub-capacity (virtualized) licensing, irrespective of prod or non-prod. So, if you run IBM software in VMs and only license sub-capacity, IBM mandates ILMT to track usage, even in a test VM. In practice, some companies only deploy ILMT on prod hosts. But strictly speaking, if you want sub-capacity rights in a dev environment, you should include that environment in ILMT. It’s generally low overhead to add those systems. Moreover, ILMT can help you discover unauthorized installs in non-prod. So it’s a good idea to use ILMT or another SAM tool across all environments, not just production.
Do you want to know more about our IBM Licensing Services?
