Top 10 IBM License Compliance Issues
IBM software audits are notorious for triggering unexpected multimillion-dollar fees. Why? IBM’s complex licensing rules make it easy for organizations to slip up.
Most compliance failures, however, are avoidable mistakes – often caused by unclear contracts, poor tracking, or a lack of internal oversight.
Below, we outline the top 10 IBM license compliance issues and, crucially, how to prevent each one before an audit catches you off guard.
Read our guide IBM License Compliance: Avoiding Audit Risks and Over-Licensing.
Introduction
IBM’s licensing and audit practices can put even the most prepared IT teams on edge.
A single oversight—such as a missing usage report or an ambiguous contract clause—can result in hefty back-charges. The good news is that these pitfalls are well-known and can be avoided with the right strategies.
This guide details the ten most common IBM compliance issues faced by CIOs, IT asset managers, and compliance officers, along with practical steps to mitigate each risk.
By addressing these areas proactively, your organization can stay one step ahead of IBM audits and maintain control in license negotiations.
1. Not Deploying ILMT for Sub-Capacity
The Issue:
IBM requires the deployment of its IBM License Metric Tool (ILMT) for any software licensed by Processor Value Unit (PVU) under virtualized “sub-capacity” conditions.
If you run IBM software on virtual machines or cloud partitions without ILMT tracking usage, IBM’s default stance is to charge for the full capacity of the underlying physical server.
In other words, failing to install or configure ILMT correctly can result in a significant bill. For example, running an IBM application on two cores of a 32-core server without ILMT could result in IBM licensing all 32 cores—a massive, unexpected cost.
Why It Happens:
Some organizations delay or overlook ILMT installation, or they install it but don’t reconcile the data. ILMT can be seen as burdensome to maintain, and if it’s not actively monitored, it may not capture accurate usage. IBM’s sub-capacity rules are unforgiving: no ILMT means no sub-capacity rights. Even if you intended to only use a fraction of a server, without ILMT’s official reports, IBM assumes full use.
Mitigation:
Deploy ILMT properly and use it! Ensure ILMT is installed on all relevant servers within 90 days of any PVU-based product deployment.
Configure it to scan and collect data continuously. Reconcile ILMT reports at least quarterly – this means reviewing the usage ILMT reports (peak PVUs used) and comparing them against your entitlements. Archive each quarterly report and keep it for at least two years.
Having a history of ILMT records is critical evidence in an audit. Additionally, keep ILMT updated to the latest version and apply any fixes IBM releases.
By diligently running ILMT and retaining its reports, you’ll preserve your sub-capacity licensing rights and avoid full-capacity charges.
Read our IBM Software License Compliance Checklist.
2. Misunderstanding Sub-Capacity Rules on Mainframe
The Issue:
IBM mainframe environments (such as z/OS) have their own sub-capacity licensing rules, which are enforced through the Sub-Capacity Reporting Tool (SCRT).
If you’re running IBM mainframe software under Monthly License Charges (MLC) and are eligible for sub-capacity pricing, you must generate and submit SCRT reports regularly (usually monthly).
Misunderstanding or neglecting this requirement can lead to IBM billing you at full machine capacity or issuing penalties. In simple terms, an incorrect or missing SCRT report means IBM assumes the worst-case usage.
Why It Happens:
Mainframe licensing is a complex process that is often handled by a separate team. Organizations sometimes miss a month’s SCRT submission, use incorrect configurations, or assume someone else handled it.
There may be confusion between hardware capacity and the rolling 4-hour average usage that SCRT measures. If SCRT data isn’t aligned with your contracts (for example, not reflecting a capping agreement or missing an LPAR), you could be out of compliance without realizing it.
Mitigation:
Automate and double-check SCRT reporting to ensure accuracy.
Make SCRT part of your monthly mainframe operations routine: schedule the tool to generate reports monthly and ensure they’re sent to IBM (if required) or retained in accordance with your agreement. Verify each report for accuracy – check that all LPARs and sub-systems are included and that the usage aligns with expectations.
It’s wise to have a secondary review of SCRT outputs by a licensing specialist or capacity planner.
Also, ensure your contract explicitly includes sub-capacity licensing for mainframe products (IBM typically requires a signed agreement or addendum for sub-capacity MLC terms).
By staying on top of SCRT, you prevent unpleasant surprises and avoid penalties for non-compliance with reporting requirements.
3. Over-Licensing Dev/Test Environments
The Issue:
Many assume that non-production environments (such as development, testing, QA, and staging) don’t require full licensing.
In IBM’s world, however, every installed instance of their software is subject to licensing unless you have a specific exemption. This means that a failure to license software in development and test environments constitutes a compliance violation.
On the other hand, some organizations purchase full licenses for development and testing environments, unaware that they could have negotiated special terms – effectively overpaying for software that isn’t generating business value. The result is either an audit exposure (if under-licensed) or wasted budget (if over-licensed).
Why It Happens:
IBM’s standard license agreements make no distinction for non-production use – an installation is an installation.
Companies often deploy IBM tools in labs or test servers without restriction, only to have an audit reveal that those installations are unlicensed.
Conversely, cautious organizations might double-license everything (production and non-production), incurring a significant cost, because they were unaware that IBM might agree to reduced terms for non-production. Dev/test setups are usually fluid and numerous, so they slip through tracking.
Mitigation:
Clarify and negotiate development and testing licensing upfront.
During contract negotiations or renewals, request a dev/test carve-out – for example, permission to use certain software in non-production environments at either no cost or a significantly reduced rate. IBM sometimes offers “Authorized User Developer” licenses or lower-cost PVU options for non-production, but you must secure them in the contract.
If a carve-out isn’t granted, budget for a minimal set of licenses to cover those environments and stay compliant. Keep a record of where IBM software is installed outside of production, and if possible, use tooling to restrict or monitor such installations.
The goal is to either eliminate unnecessary non-production deployments or ensure they’re licensed under a more favorable agreement. By doing this, you avoid audit findings in your test lab and prevent overspending on software that’s not mission-critical.
4. Disaster Recovery Licensing Missteps
The Issue:
Many organizations maintain disaster recovery (DR) setups or cold backup servers for IBM software, mistakenly assuming those backup systems don’t need licenses as long as they’re idle.
The reality: IBM’s default policy often requires a license for any installed instance, even if it’s just for disaster recovery, unless your contract explicitly provides an exception. Simply put, your DR environment could be a compliance landmine.
Suppose a backup server is ever fired up (even for a periodic test or during an emergency). In that case, you might suddenly be out of compliance and facing license fees for that “secondary” system.
Why It Happens:
It’s common to think of DR infrastructure as insurance – you only use it in a disaster, so it shouldn’t incur cost until needed. Some software vendors allow a cold standby for free, but IBM’s terms vary by product and agreement. IBM does have a concept of “cold, warm, hot” backups with differing rules, but these nuances are often buried in contract fine print.
Organizations might set up replication or clustering to a DR site and not realize that, from IBM’s view, if the software is installed and ready to run, it may require licensing. During audits, IBM will inquire about any copies of the software on DR or backup servers, and without a pre-negotiated exemption, these could be considered full installations.
Mitigation:
Negotiate DR licensing terms explicitly.
Don’t leave disaster recovery arrangements to assumption. In your IBM agreements, include clauses for DR that spell out what is allowed. For example, consider negotiating a right to maintain one cold standby instance per production license, which can be used only during a disaster (and perhaps for limited testing) without incurring an additional license fee.
If you have a hot or warm standby (where IBM software is running concurrently or updated regularly), consider a special licensing agreement, such as a discounted second-use license.
Document these terms clearly. Internally, maintain an inventory of all DR installations of IBM software and track their status (cold/off, warm, etc.).
Ensure everyone on the IT continuity team knows that adding IBM software to a DR site requires checking the license implications. By planning DR licensing, you’ll avoid nasty surprises when you actually need to use those backups.
Read more, IBM Compliance in Virtual and Cloud Environments: Avoiding Costly Mistakes.
5. BYOL Portability Gaps
The Issue:
“Bring Your Own License” (BYOL) to the cloud is a popular strategy to save costs – you take an IBM software license you already own and deploy the software on a cloud platform (such as AWS, Azure, or Google Cloud) instead of on-premises.
The compliance pitfall is that IBM’s standard licenses don’t automatically grant the right to use their software in all cloud environments, or the metrics might change.
If you move IBM workloads to the cloud without explicit portability rights, you might unintentionally be running unlicensed software. For instance, using your on-prem IBM WebSphere license on AWS might violate terms if not covered by your contract, leading to an audit finding of unlicensed usage.
Why It Happens:
Cloud migrations often happen quickly, driven by business needs, and the assumption is “we paid for the software so that we can run it anywhere.” However, IBM may have specific cloud licensing programs or require that you inform them of such moves.
Sometimes, the cloud’s virtual cores have different PVU values, or IBM may require the use of IBM Cloud Paks or other container licenses for cloud deployments.
Without careful review, a workload that was compliant on-premises can become non-compliant in the cloud due to a lack of BYOL provisions. Additionally, IBM sales representatives may encourage you to repurchase licenses as SaaS or cloud-subscription offerings instead of BYOL.
Mitigation:
Secure explicit BYOL clauses for each cloud provider you use.
When negotiating licenses, state clearly that you intend to deploy on AWS, Azure, Google Cloud, IBM Cloud, etc., and get IBM’s agreement in writing that your existing entitlements cover those deployments.
Ensure the contract specifies how usage in the cloud will be counted (for example, mapping cloud vCPUs to PVUs or using a container-based metric).
IBM has offerings like Cloud Paks, which are essentially bundles with cloud-friendly licensing metrics – you might negotiate a conversion of some traditional licenses to Cloud Pak licenses if that fits your cloud strategy. Internally, always involve your licensing or procurement team before moving an IBM product to any external cloud.
Conduct a compliance check to determine if the move is permitted and if additional licenses are required. By proactively addressing portability, you can confidently move workloads to the cloud without stepping into a licensing trap.
6. Metric Misalignment (PVU vs. AU vs. vCPU)
The Issue:
IBM offers multiple licensing metrics, including Processor Value Unit (PVU), Authorized User (AU), and Virtual Processor Core (VPC), which are often used to track containers, concurrent users, and installation counts, among others.
A common compliance issue is misaligned metrics: you deploy or count licenses under the wrong metric. This can happen if you misunderstand your contract or if a product’s metric has changed in a new version.
The result is either over-deployment (you use more than you’re entitled to because you were counting differently) or over-spending (buying too many licenses of one type when the usage didn’t require it). In either case, during an audit, IBM will recalibrate usage to the correct metric – possibly exposing a shortfall.
Why It Happens:
IBM’s product portfolio is vast, and each software product may have a unique licensing method. For instance, IBM Middleware may be licensed per core (PVU) on-premises, but if you switch to a Cloud Pak version, it may be licensed per Virtual Processor Core. Some security or analytics products are licensed per Authorized User (named user) or per concurrent user. If an organization assumes one metric applies but the contract says another, they might count incorrectly.
A typical scenario: You purchase an IBM software, thinking it’s licensed for unlimited users as long as you cover the servers’ PVUs, but it turns out it was an Authorized User license – suddenly, the 500 users accessing it put you over the entitlement. Conversely, you might have bought a license for 500 users when you only needed to license a small server, thus wasting your budget. Metric confusion also arises when consolidating licenses or migrating to new IBM offerings.
Mitigation:
Confirm and document the licensing metric for each product, aligning it with your deployment approach. Review your IBM entitlements and note the corresponding metric (e.g., PVU, AU, VPC) for each software title.
Ensure that your technical teams and IT asset managers are familiar with these key metrics.
If you’re planning a change – such as moving an on-premises app to a container or increasing the user count – revisit whether a different metric would be more applicable or more efficient.
If needed, negotiate metric flexibility: for example, if you foresee shifting from a PVU model to a user model (or vice versa), obtain IBM’s agreement on a conversion formula or swap rights in advance.
It’s also smart to use IBM’s official tools or formulas to count your usage in the correct units regularly (e.g., have ILMT report PVUs, or have an internal process to count authorized users).
By eliminating metric misunderstandings, you ensure you’re neither under-licensing (risking audits) nor over-licensing (wasting money).
7. Shelfware in Bundled Deals
The Issue:
IBM often sells software in large bundles – think Enterprise License Agreements (ELAs) or the newer Cloud Paks bundles, which package many products under a single license.
The pitfall is that these bundles frequently include more software or capacity than an organization actually uses, resulting in expensive “shelfware” (licenses purchased but never deployed). While having extra entitlements isn’t a direct compliance violation (not using software is not illegal), it is a financial risk.
Companies often end up overpaying millions for shelfware, and those unused licenses can become a compliance issue if someone later deploys them in unintended ways.
Moreover, when renewal time comes, IBM may not automatically allow you to drop the unused parts – locking you into ongoing support costs for software you no longer need.
Why It Happens:
Bundled deals are tempting. IBM might offer a steep discount (say 50% or more off the list price) if you buy a broader suite or a higher quantity than your current needs require. Procurement leaders may accept large bundles to secure a discount or to appease various stakeholders with an “all-in-one” package.
Over time, however, some projects are canceled or certain products in the bundle are never implemented. Those licenses sit idle (shelfware), yet you’re paying maintenance on them annually.
Additionally, large bundles can obscure areas where you might be underutilizing entitlements, and IBM could leverage that in future negotiations (“you bought 1000 PVUs but only use 500 – clearly you can deploy more, or we won’t allow reductions”).
Mitigation:
Negotiate swap and true-down rights for bundled purchases. Before signing an ELA or Cloud Pak deal, scrutinize what’s included. Only commit to what you have a realistic plan to use.
Where possible, include contract terms that allow for future adjustments: for example, a swap right enables you to exchange unused licenses or products for other IBM software of equivalent value that you actually need.
A true-down clause gives you the right to reduce the quantity of licenses (and associated support costs) at certain intervals (like annually or at renewal) if your actual usage is lower.
These provisions protect you from paying perpetually for shelfware. Also, treat shelfware as a red flag internally – conduct regular usage reviews on any enterprise bundles.
If you identify shelfware early, approach IBM to see if you can re-balance those entitlements toward more useful areas (sometimes IBM will accommodate mid-term swaps if it leads to you adopting more of their portfolio).
The goal is to ensure every license you pay for either delivers value or can be trimmed, keeping your software investment efficient.
8. Renewal Uplift Compliance Risks
The Issue:
Even after you’ve purchased IBM software, the way you handle renewals can introduce compliance risk and cost surprises. IBM often ties favorable renewal terms to being in good compliance standing.
Furthermore, IBM maintenance renewals can come with steep uplift charges – increases in annual fees – especially if your original deal had a big discount. If your contract doesn’t cap these uplifts, you might face a budget shock at renewal time (e.g., a 10-20% jump in costs).
Now add compliance to the mix: if an audit or IBM’s observations suggest that you’re using more than you’ve purchased, IBM might condition your renewal on purchasing additional licenses or forfeiting discounts. In short, an out-of-compliance environment weakens your negotiating position, and a lack of price protections can lead to punitive renewal pricing.
Why It Happens:
Many organizations focus on the initial purchase discount and forget about the back end (renewals). IBM sales teams are aware of this and may offer a great first-year deal, then rely on their standard policy to increase fees in subsequent years.
If an audit finds you non-compliant right before a renewal, IBM knows you need to renew support (to keep systems running and stay legal), so they use that leverage to demand a costly true-up as part of the renewal.
Additionally, some IBM contracts explicitly state that certain discounts or special terms are void if you are found non-compliant. Without careful review, a customer might unknowingly agree to terms that let IBM increase prices significantly if any compliance issue arises.
Mitigation:
Negotiate renewal caps and stay audit-ready before each renewal. When you sign any license or support agreement, include a clause limiting annual renewal price increases – for example, “maintenance fee uplift not to exceed 3% per year” or tied to an inflation index. This prevents surprise hikes and keeps long-term costs predictable.
Also, ensure your discounts carry forward: if you received 50% off in the initial purchase, state that renewals and future purchases of that software should be based on the discounted price, not the full list price. Separately, plan for renewals by doing an internal compliance review well in advance.
A year (or at least a few months) before a big renewal, thoroughly audit your IBM deployments vs entitlements. If you discover you’re over-deployed, you have time to correct it or purchase needed licenses quietly, rather than under the gun of an official audit.
Being clean at renewal means IBM has no “gotcha” to force concessions. In negotiations, keep compliance discussions separate from pricing discussions – if IBM knows you’re prepared and aware, you can renew on your terms.
By controlling renewal terms and preemptively fixing compliance gaps, you turn renewal time from a risk into an opportunity (potentially to even negotiate better deals or product swaps).
9. Lack of an Entitlement Repository
The Issue:
One surprising way companies fail audits is simply not being able to prove ownership of the necessary licenses. Over the years of IBM purchases, especially across different departments or mergers, entitlement documents can get lost.
When IBM audits you, they will ask for proof of entitlement (PoE) for every deployment – basically, evidence (like license certificates, Passport Advantage records, or contracts) that you purchased sufficient licenses for the software you’re using. If you can’t find the paperwork, IBM may treat it as unlicensed use even if you did buy it.
A disorganized license history thus weakens your defense and can lead to paying again for something you actually had rights to. It also makes internal compliance hard to assess if you don’t have one clear view of all entitlements.
Why It Happens:
IBM licensing spans many products and decades, and documentation is often siloed. Perhaps procurement handled some purchases, IT handled others; records might be in emails, PDFs, or with a reseller. Passport Advantage (IBM’s portal) maintains a history of purchases, but it may not include special terms or older agreements outside of that program.
Without a central repository, it’s easy to overlook an entitlement or to assume something was purchased when it wasn’t (or vice versa). In an audit scenario, the clock is ticking – if you scramble to find proof for 100 software installations scattered across contracts, any missing piece becomes a potential non-compliance finding.
A lack of a repository also means you may over-buy licenses because you weren’t aware that you already had spare capacity available.
Mitigation:
Maintain a centralized entitlement repository. Treat your IBM license entitlements as you would financial records – store them securely and accessibly. This can range from a formal IT asset management tool to a simple, well-organized shared folder or spreadsheet, as long as it’s comprehensive.
Include every proof-of-license: Passport Advantage reports, License Key documents, purchase orders with part numbers, IBM license certificates, ELA contracts, and any amendment that grants special terms (like DR rights or unlimited use periods).
Ensure this repository is regularly updated with new purchases and changes. Equally important, align entitlements with deployments: map what software is deployed on which machines and which entitlement covers it. If you retire software or reallocate licenses, update the records.
During an audit, being able to quickly pull up proof for each product and version in use is invaluable – it demonstrates to IBM that you’re in control and can reduce the audit scope. It also helps internally; you can answer “are we licensed for this?” in minutes, and you avoid buying things you already own. In summary, good documentation is a quiet but powerful defense against compliance issues.
10. Ignoring Audit Preparation
The Issue:
Perhaps the most strategic mistake is failing to prepare for an IBM audit until the auditors are at your door. IBM audits are a matter of “when,” not “if,” for most customers. If you have no internal audit-readiness – no regular self-checks, no defined process for responding to an audit – you end up in a reactive scramble.
This reactive stance often results in more findings (because you didn’t catch issues beforehand) and a weaker negotiation position (because IBM dictates the timeline and terms when they catch you off guard). In contrast, companies that treat audit preparation as an ongoing process can significantly reduce both the stress and cost of actual audits.
Why It Happens:
Day-to-day IT and procurement tasks take priority, and audit prep feels hypothetical until that official notice arrives. Some organizations also operate under optimistic assumptions: “We haven’t been audited yet, maybe we never will,” or “Our software tools would alert us if something were wrong.” There may be a lack of expertise in-house on IBM’s arcane rules, so people avoid the issue.
Unfortunately, when IBM’s audit letter arrives (often giving just a few weeks to start), an unprepared company might hurriedly pull data that hasn’t been vetted, inadvertently exposing more compliance gaps than necessary. Also, without a plan, companies can be overly transparent or share incomplete information, which IBM can then interpret in the worst light.
Mitigation:
Conduct regular internal license audits and have an audit response plan.
Proactively reviewing your IBM license compliance every quarter is ideal. This involves checking each major product’s usage against entitlements (utilizing tools like ILMT for PVU products, scripts for user counts, etc.), and resolving any discrepancies (by reallocating licenses, trueing up, or retiring excess usage) well before IBM might notice. Keep a log of these internal audits – it helps track improvements and serves as evidence of good-faith compliance efforts.
Equally important is preparing an audit playbook —a documented plan for handling an IBM audit. This playbook should define roles (e.g., who in your organization speaks to auditors, who gathers data), outline what data is collected (and how to verify it before sending to IBM), and include communication guidelines (for example, you may want all auditor inquiries to go through a single point of contact, and you might involve legal or an outside licensing expert to vet responses).
Practice this plan with tabletop exercises or dry-run audits. By being prepared, you transform an IBM audit from a panicky fire drill into a managed project.
You’ll address the auditors’ questions efficiently, correct course on any minor issues before they escalate, and negotiate from a position of knowledge. In short, the best time to fix compliance issues is before the auditors arrive – not after they’ve found them.
IBM Compliance Issues & Fixes (Summary Table)
Sometimes it helps to see the problems and solutions at a glance. Here’s a quick reference table highlighting a few critical IBM compliance issues and how to fix or prevent them:
| Issue | Risk Impact | Mitigation Strategy |
|---|---|---|
| No ILMT for sub-capacity | Full-capacity billing (huge extra cost) | Deploy ILMT; do quarterly reconciliation of usage and archive reports |
| BYOL gaps (no cloud license rights) | Unlicensed workloads in cloud | Secure explicit cloud portability clauses in contract before moving to AWS/Azure/etc. |
| DR licensing missteps | Extra license costs for backup systems | Negotiate DR carve-outs (e.g., free cold standby rights in contract) |
| Shelfware in ELAs/Cloud Paks | Overpaying for unused software | Include true-down and swap rights to remove or repurpose unused entitlements |
In the table above, each issue (left column) can lead to a significant risk or cost (middle column). The right column summarizes a key mitigation strategy to address the issue. These are not the only fixes, but they are primary actions that significantly reduce compliance risk.
Checklist – Staying Compliant
Use this quick checklist to fortify your IBM license compliance management.
Regularly verify each item to ensure you’re staying on top of IBM licensing pitfalls:
☐ ILMT deployed & maintained – Install IBM’s License Metric Tool on all virtualized environments and review its reports quarterly.
☐ SCRT reports automated – Set up automatic Sub-Capacity Reporting Tool runs for mainframes and submit them as required.
☐ DR & test licensing clarified – Document your disaster recovery and non-production (dev/test) entitlements; negotiate exceptions where possible.
☐ BYOL clauses in contract – For any cloud plans, ensure your IBM contracts allow license portability to third-party clouds.
☐ Renewal uplifts capped – Have agreements in place to limit maintenance fee increases and unlink discounts from audit surprises.
☐ Entitlement repository maintained – Keep a centralized, up-to-date record of all IBM licenses and contracts, and align it with current deployments.
☐ Quarterly internal compliance reviews – Proactively audit your own IBM license usage and address gaps long before IBM does.
By regularly ticking off these items, you create a culture of compliance that will make IBM audits far more manageable—and perhaps even uneventful.
FAQs
Q: What’s IBM’s #1 compliance pitfall?
A: The number one pitfall is failing to deploy IBM’s License Metric Tool (ILMT) for sub-capacity environments. Without ILMT in place, IBM will bill you for the full physical capacity of your servers, rather than their actual usage, which often results in dramatically higher license charges.
Q: Do disaster recovery environments need IBM licenses?
A: Yes, typically they do – unless you have an explicit exemption in your contract. IBM generally requires that any instance of its software that is installed be licensed. A cold DR server isn’t automatically free; you must negotiate or clarify in your license agreement if you want to run IBM software on standby systems without additional licenses.
Q: Can IBM audit me without notice?
A: Yes. IBM license agreements typically include audit clauses that permit IBM to audit your software usage at any time, with minimal notice. In practice, IBM will provide a formal audit notification (often giving a few weeks to start), but you won’t get much warning beyond what the contract stipulates. This means an audit can come unexpectedly, so it’s wise to always be prepared.
Q: How can I reduce shelfware risk with IBM deals?
A: Reduce shelfware by negotiating flexibility in your contracts. For example, you can include swap rights to exchange unused IBM licenses for other products your organization needs, and true-down rights to reduce the number of licenses (and associated support costs) at renewal if certain entitlements remain unused. These provisions ensure you’re not stuck paying for software that isn’t delivering value.
Q: Is compliance negotiable during an IBM audit?
A: Yes, usually there’s room to negotiate. IBM audit findings are not set in stone; in fact, IBM often prefers to reach a settlement rather than impose full list-price penalties. This means you can typically negotiate a resolution, such as purchasing additional licenses or subscription credits (sometimes at a discount), to cover any shortfall, rather than simply paying a massive penalty. The key is to engage constructively and, if possible, leverage upcoming purchases or renewals as part of the settlement discussion to get a more favorable outcome.
Read about our IBM Licensing Consulting Services
