IBM User-Based Licensing
Introduction: IBM offers multiple user-based licensing models – Authorized User, Concurrent User, and Floating User. On the surface, they seem straightforward, but in practice, each model carries hidden compliance risks, potential cost inefficiencies, and negotiation challenges.
CIOs, procurement managers, and IT Asset Management teams often struggle to optimize these licenses. Read our ultimate guide, IBM License Models: PVU, RVU, Cloud Pak, SaaS, and Beyond.
This guide, written from the perspective of an IBM licensing strategist, explains how each user-based model works and provides practical strategies to control costs, avoid pitfalls, and strengthen your negotiating position.
IBM’s user-based licenses tie software usage to people rather than hardware.
That alignment can be powerful for budgeting and accountability; however, without careful management, it can lead to shelfware (paid-for licenses sitting unused) or unexpected audit penalties.
We’ll break down the three main models – Authorized User, Concurrent User, and Floating User – including their definitions, cost implications, compliance risks, optimization approaches, and negotiation tactics.
By the end, you’ll know how to leverage each model’s advantages while mitigating its downsides.
Authorized User (AU) Licensing
Definition:
Authorized User licensing means each user who accesses the software needs their own license. It’s a named-user model – one license per person, assigned to a specific individual. This license cannot be shared among multiple people. Even if a person uses the IBM software occasionally and is authorized to do so, they require a license dedicated solely to them.
IBM commonly uses Authorized User licenses for products like DB2 databases, Cognos Analytics, and Planning Analytics (TM1), among others. For example, if 50 employees need access to an IBM Cognos system, you must have 50 Authorized User licenses, one per named person.
Cost Implications:
The cost in an AU model scales linearly with the number of users. It works well when you have a stable or predictably small user base that uses the software regularly. However, it can become cost-inefficient if licenses are not actively used.
Each license is paid for regardless of actual usage time. If you overestimate the number of people who need access, or if some users rarely log in, you end up with shelfware – licenses purchased but sitting idle. For instance, an organization might purchase 100 Planning Analytics user licenses but find that only 70 people use the tool actively; the 30 unused licenses represent a wasted budget unless they can be reassigned or reduced later.
Compliance and Management:
Managing Authorized User licenses requires diligent tracking of who has access to them. Because the software doesn’t usually enforce named user counts technically (it assumes you are complying), it’s on you to ensure you haven’t assigned more users than entitlements.
A common pitfall is failing to remove users who no longer need the software – e.g., employees who have left or changed roles – which can lead to non-compliance if new users are added without additional licenses. Also, sharing login credentials to “get around” license counts is strictly against IBM’s terms. Every distinct person using the program should have their own license. IBM audits can detect shared accounts or more users in the system than the number of licenses owned. The key is to maintain an accurate list of active users mapped to licenses at all times.
Negotiation Tips:
When dealing with Authorized User licenses, push for contract flexibility to reduce waste. Two important things to negotiate are true-down rights and reassignment rights. True-down rights allow you to reduce the number of licenses (and associated fees) at renewal if your user count drops. For example, in a three-year deal, if you start with 100 users but only 80 still use the software by year two, true-down provisions let you adjust and pay for 80 in the future instead of 100.
Without this, you’re stuck paying for the original quantity even if it’s no longer needed. Also negotiate flexible reassignment rules: by default, an Authorized User license is tied to one person, but you should have the right to reassign that license when someone leaves or their role changes.
Ensure the contract permits transferring an AU license to a new user (typically when the original user permanently departs or no longer requires access) without requiring the purchase of a new license. By securing these terms, you prevent shelfware and ensure your investment aligns with actual staffing needs.
Concurrent User Licensing
Definition: Concurrent User licensing limits the number of users who can use the software simultaneously, regardless of the total number of individuals who have access. In practice, you might enable many users to have accounts, but only a certain number can be logged in or active at the same time.
For example, you could have 500 employees with the software installed or accounts created, but with a 50-concurrent-user license limit, only 50 of them can use it at once. The 51st user attempting to use it would be blocked until someone else logs off (if the license is actively enforced by software), or would put you out of compliance if the software doesn’t enforce and you exceed 50 concurrent sessions.
IBM has offered concurrent user licensing for various products (a classic example is IBM SPSS Statistical software, which allows a maximum concurrent user count to be licensed, and some legacy IBM Cognos roles or IBM Business Automation products have concurrent user options).
Cost Implications:
The primary advantage of concurrent licensing is its cost efficiency for broad, yet infrequent, usage. It’s ideal in environments where you have a large population of potential users, but only a fraction need to use the software at any given moment. Rather than buying a license for every single user, you buy just enough to cover peak simultaneous demand.
This can significantly reduce the total number of licenses needed. For instance, if on average only 10% of your 500 users use the system concurrently at peak, you only need licenses for that 10%. However, the cost per concurrent license is often higher than that of a single authorized user license, as it provides more flexible usage.
You essentially pay a premium for the ability to share licenses among many users. The critical cost factor is your peak usage. If your usage exceeds expectations, you may need to purchase additional licenses to increase the concurrent cap, which can be costly if not anticipated.
Compliance Risks:
Concurrent models shift the focus to monitoring usage patterns. IBM will hold you accountable for the highest number of simultaneous users accessing the software.
A common compliance pitfall is exceeding your licensed concurrent count during peak times. IBM’s audit teams often examine log files or use built-in usage meters to find the maximum concurrent users that have occurred. If, say, you purchased 50 concurrent licenses.
Still, an audit finds that at one point, 65 users were on at the same time, IBM will consider you under-licensed and could demand back payments and additional license purchases for those overages. It’s essential to note that even a brief spike (e.g., a 10-minute window where more users logged in) can be considered non-compliance – IBM typically doesn’t average it out; instead, they look at the peak.
Therefore, organizations must maintain careful logs of usage. Use license manager tools or software features to enforce the limit if possible (some IBM products will simply not allow user 51 on, which is good for compliance). If the software doesn’t strictly enforce it, you need internal controls (like an in-house monitoring script or policy to restrict access).
Usage Strategy: To get the most value from concurrent licensing, closely monitor and manage your concurrent usage. Regularly analyze usage reports to understand typical and peak concurrent user counts. If you consistently stay well below your licensed limit, you may have room to reduce your licenses at renewal to save costs.
Conversely, if you’re hitting the cap and users are getting turned away (or you see occasional breaches of the limit), you should address it proactively – either by acquiring a few more licenses or by scheduling user access (for example, encouraging heavy users to operate in different time windows) to avoid simultaneous peaks.
Additionally, clarify the contract regarding how concurrency is measured. Ideally, have it specify the measurement interval or tool (e.g., peak hourly concurrent users per month) so you’re on the same page with IBM. This avoids ambiguity that IBM could exploit in an audit.
Finally, try to negotiate a fair resolution process for any overage: for example, agree that if an occasional peak exceeds the limit, you will true-up by purchasing additional licenses at standard rates, rather than facing punitive fees. Having this understanding in writing can prevent “surprise penalties.”
Read how PVU licensing works, IBM PVU Licensing Explained: Processor Value Units, Costs, and Compliance Risks.
Floating User Licensing
Definition: Floating User licensing is very similar to concurrent licensing, but with an emphasis on dynamic allocation from a shared pool. In a floating model, you purchase a pool of licenses that are not assigned to specific named users; instead, any user who needs the software can draw a license from the pool while they’re using it, and when they finish or log off, that license returns to the pool for someone else to use.
Technically, floating licenses are usually enforced by a centralized license server (such as IBM’s License Key Server or common tools like FlexLM), which ensures that the number of active licenses in use never exceeds what you purchased.
Many IBM software products in engineering and development domains utilize floating licenses. For example, IBM Rational engineering tools often employ floating licensing, allowing a team of 50 engineers to share approximately 20 floating licenses. The license server distributes keys as engineers launch the application.
Best Use Cases: Floating licensing is excellent for environments with project-based or shift-based usage. If you have multiple teams or users who only need the software at certain times (and not all at once), a floating pool maximizes utilization. For instance, consider a global team of consultants who use an IBM modeling tool: if consultants in New York finish their work for the day and log off, their licenses become available for consultants in London or Tokyo starting their day. Likewise, within a single location, if not everyone needs the software simultaneously – say users A, B, C use it in the morning and users X, Y, Z use it in the afternoon – a smaller pool of floating licenses can cover them all. This flexibility often means fewer total licenses are required than if each person had their own dedicated license.
Risks and Challenges:
The primary risk with floating licenses is unintended overuse beyond the purchased pool, particularly if the license control mechanisms are not strict or if they are circumvented. Generally, a properly configured license server will prevent more than the licensed number of users from running the software at once (the 21st person simply won’t get a license if you have 20 floating licenses).
However, issues can arise if, for example, multiple license servers are deployed (accidentally allowing more total concurrent use than the entitlement allows) or if the software can operate in an “offline” mode without checking out a license for a period. IBM auditors will challenge any situation where they believe the peak number of simultaneous users exceeded your entitlements, even if this is due to a technical glitch or improper setup.
Tracking and documentation are crucial; you need logs from the license server or monitoring tools to show how licenses were issued and that you did not exceed the limit. Without solid tracking, IBM might assert that “overuse” occurred – and it can be hard to refute without data.
Management Strategy:
To stay safe and optimized with floating licenses, use monitoring tools and set internal policies. Ensure the IBM license server (or whatever mechanism manages licenses) is implemented and all users/apps point to it – this prevents unmonitored usage. Regularly review the license server’s reports to see peak usage and frequency. If you find that the pool is often fully utilized, it may be time to consider increasing the pool size or managing usage more actively. If the pool is never fully used, you might have more licenses than necessary.
Another tip: negotiate acceptable usage thresholds or burst capacity with IBM. In some cases, clients negotiate terms for short-term bursts (for example, the right to exceed the floating license count by 10% for up to 30 days in a year, with a pay-as-you-go fee). IBM won’t offer that by default, but enterprise customers sometimes get creative terms, especially if usage patterns are unpredictable.
At a minimum, the contract should clearly define how usage is measured and specify that the official license server logs are the source of truth. This way, if IBM ever claims you were over, you can rely on a mutually agreed-upon measurement to verify compliance.
Cost Drivers in User-Based Licensing
Multiple factors influence the total cost of IBM’s user-based licenses. It’s not just “number of users × price” – the way you manage and negotiate these licenses can significantly impact your budget.
Below are key cost drivers to consider:
| Cost Driver | Impact on Costs |
|---|---|
| Number of Users / License Quantity | This is the most direct cost driver. In Authorized User models, more named users mean more licenses purchased – costs scale directly with headcount. In Concurrent or Floating models, the cost correlates with the peak number of users needing access at once. Accurately forecasting how many users truly need the software (and at what times) is crucial to avoid over-purchasing. |
| Usage Pattern & Peak Demand | How users use the software affects cost efficiency. If usage is sporadic, concurrent/floating models let you buy fewer licenses, lowering cost – provided that peak concurrent usage stays within your license pool. However, if your peak demand spikes unexpectedly (e.g. everyone logs in during a critical period), you may need to buy additional licenses to cover that, or face compliance penalties. Essentially, the closer your peak usage is to your average usage, the less benefit you get from sharing licenses and the more you’ll end up paying for sufficient capacity. |
| Shelfware from Turnover or Changes | In a per-user model, staff turnover and role changes can lead to “shelfware.” You might have licenses tied to users who no longer use the software, but you continue paying support on them. Unless you reclaim and reuse those licenses promptly, you’re overspending. Similarly, buying a large block of user licenses upfront for a project that then scales down leaves you carrying excess entitlements. These unused licenses inflate costs without providing value. |
| Annual Support & Renewal Uplifts | IBM typically charges annual Software Subscription & Support (S&S) fees around 20% of the license price, and often applies yearly price uplifts (5–7%) on those renewals by default. Over a multi-year period, these increases compound and can significantly raise costs even if your user count remains static. If not negotiated, a $100K annual user license spend can turn into $115K+ in a couple of years due to uplifts. Always factor maintenance costs and planned uplifts into the total cost of ownership. |
| License Model Selection | Choosing the wrong model for your usage pattern can drive up costs. For example, licensing 500 users as Authorized Users when only 100 ever use the system concurrently means you paid for 400 unnecessary licenses. Conversely, if you opt for concurrent licensing but in practice all users use the system heavily (meaning concurrency is close to total users), you might have been better off with per-user pricing or a capacity model. Evaluate which model (or mix of models) yields the lowest cost per actual active user. IBM’s flexibility can be limited once a model is chosen, so get this right up front or at renewal. |
| Purchase Volume & Timing | IBM offers volume discounts on larger purchases. Buying 1000 licenses in one go will get you a better per-unit price than buying 200 at a time over five periods. If you anticipate growth, it can be cheaper to negotiate a bigger block of licenses now at a discount tier (with perhaps provisions to drop some later) than to add piecemeal. Timing large purchases to align with IBM’s end-of-quarter or end-of-year can also improve discount leverage. On the flip side, last-minute or unplanned purchases (such as an urgent true-up after an audit) are usually at list price – a costly scenario to avoid through better planning. |
Bottom line: Manage these cost drivers by aligning license counts with actual need and locking in favorable terms.
Always model different scenarios – e.g., compare the 3-year cost of 100 Authorized Users vs. 50 Concurrent Users for a given usage pattern, including support fees and potential growth. By understanding what truly drives your IBM user license spend, you can make informed decisions to prevent budget surprises.
Compliance Risks
IBM’s user-based licensing comes with a web of rules that can trip up even diligent organizations. Non-compliance can result in hefty back-charges or forced purchases during an audit.
Here are common compliance risks to watch for and mitigate:
- Misaligned User Definitions: Be very clear on how “users” are defined in your IBM contract. If the contract language is vague, IBM might interpret it in its favor during an audit. For example, are contractors or external users included in your count? Does a generic service account count as a user? If you have an Authorized User license, each unique person (with a unique login) should be counted as one; however, if your system has multiple accounts per person or shared accounts, this can confuse. Mitigation: Negotiate and document precise definitions. Ensure the License Information (LI) documents or contract notes specify how to count unique individuals and cover scenarios such as test accounts or inactive accounts. Clarity upfront prevents disputes later.
- Reassigning Licenses Without Approval: In an Authorized User model, reassigning a license from one person to another improperly can break compliance. IBM’s standard terms typically say an Authorized User license is for one individual and can only be transferred to a new individual in specific circumstances (like the original user leaves the company) and not on a whim. If you frequently rotate one license among many people (beyond what the contract allows), IBM could flag it as unlicensed usage for those not officially assigned. Mitigation: Follow contract rules for reallocation. If you anticipate needing to reassign staff frequently (due to rotating teams or project-based assignments), negotiate for that flexibility. Keep a log of any reassignments (including who had the license and when it was moved) to demonstrate to auditors that you complied with the permitted processes.
- Not Tracking Concurrent/Floating Usage: Failing to monitor actual usage with concurrent and floating licenses is a risk. You might think you comply if no one complained about access, but it’s possible you had occasional peaks over the limit that went unnoticed. IBM audits will seek out those peak overages. Mitigation: Utilize license management software or built-in monitoring to track the maximum concurrent users. Set up alerts if usage approaches the licensed limit. Keep historical records of usage – these will serve as evidence in an audit to demonstrate that you stayed within bounds (or to proactively true-up if you notice consistent overages). Never rely on an honor system or user self-reporting; have automated logs.
- Lack of Documentation: In any user-based model, being unable to produce good documentation can turn an audit in IBM’s favor. For example, IBM might request a list of all users with access to a specific software to compare against your entitlements. If you cannot readily produce a clean, current list (and show how you manage changes to that list), the auditor may assume the worst-case scenario. Similarly, for concurrent licenses, they may ask for usage logs. If you don’t have them, you can’t contest whatever number IBM claims. Mitigation: Maintain up-to-date records, including lists of authorized users, records of when users were added or removed, and license server logs for floating usage, among others. Conduct internal audits so that when IBM shows up, you already have the numbers on hand (and ideally have corrected any discrepancies).
- User Account Sharing or Multiplexing: It’s worth reiterating the compliance threat of account sharing. If two or more people share a single login to circumvent license limits, it constitutes a violation. Additionally, use an intermediary system (such as a proxy or multiplexer) that allows multiple people to access the software as a single technical user. IBM will count each individual as an actual user. Mitigation: Enforce unique user IDs for anyone accessing IBM software. If a shared account is necessary for some technical reason, discuss it with IBM and obtain written approval for how it will be treated licensing-wise (don’t assume you can proceed without approval).
- Contract Ambiguities (Environments/Clustering): Sometimes it’s unclear whether each environment requires separate licenses (e.g., non-production/test environments) or how failover users are counted. If not specified, IBM may count every account across all environments. Mitigation: Clarify in the contract how non-production or backup environments are licensed for user counts (IBM might allow non-prod usage without extra licenses if not actively used, but get it in writing). Also, clarify whether a user needs a license for each environment or just one license covers them for all. Typically, one AU license covers a person for any number of instances of that software, but ensure that’s stated.
Staying compliant requires proactive management and clarity. Internally, treat user licenses as you would physical assets: keep an inventory, know who “has” each license, and track its usage. Externally, make sure IBM’s rules of play are well-defined and documented in your agreements.
Remember, IBM audits are likely not a question of “if” but “when” – so having meticulous records and adherence to terms will make that process far less painful.
Optimization & Cost Reduction Strategies
After understanding the risks and cost drivers, the next step is to optimize your IBM user-based licenses to minimize costs and waste.
Here are practical strategies to get more value out of your Authorized, Concurrent, and Floating licenses:
- Conduct Regular Usage Audits: Don’t wait for IBM to audit you – audit yourself. Quarterly reviews are a good practice: check how many users are actually using each software and how often. Compare this against what you’re entitled to. This internal audit will highlight immediate optimization actions (e.g., 20 licenses assigned to people who haven’t logged in all quarter – those could be reallocated or dropped). Regular monitoring also means you’ll enter annual renewals with data to adjust license counts to actual needs, thereby avoiding over-purchasing.
- Reclaim and Reuse Authorized Licenses: For Authorized User licenses, implement a process to reclaim licenses from departing or inactive users. For example, coordinate with HR so that whenever an employee leaves, IT is alerted to free up any IBM software license assigned to them. Similarly, if certain users haven’t used the software in a long time, consider removing their access (after confirming they no longer need it) and reassigning that license to someone else who does. This avoids buying new licenses unnecessarily. Essentially, treat licenses as transferable assets: if Person A no longer needs it, give it to Person B rather than it sitting on Person A forever. Ensure that any transfer aligns with the contract terms (negotiate those terms as discussed).
- Optimize Concurrent/Floating Pool Size: For concurrent and floating licenses, use the data from your monitoring tools to right-size the pool. If your peak concurrent usage over the last year was 50 and you have 70 licenses, you might be able to safely reduce to, say, 55 or 60 licenses and save on support costs – with minimal risk of disrupting users. On the other hand, if peak usage is hitting your cap and causing delays, maybe a small incremental investment in a few more licenses would smooth operations and still cost less than moving everyone to named licenses. Always balance the cost of additional licenses against the value of user productivity and compliance safety. One technique is to simulate “what-if” scenarios: e.g., how would costs change if we switched 50 light users to concurrent instead of authorized, or vice versa? IBM and third-party tools can often help simulate these models. Conduct this analysis before renewals to determine if switching models or adjusting counts yields savings.
- Consider Alternative Licensing Models: Be aware that IBM often offers multiple licensing options for the same product. Suppose user-based licensing isn’t efficient for a particular case. In that case, you might consider evaluating a capacity-based model (such as PVU or Virtual Processor Core licensing) or bundled offerings like IBM Cloud Paks, which include the software under a different metric. For example, if an IBM product is causing you high user counts, consider whether licensing by CPU power is more cost-effective for unlimited users. Conversely, if you have a Cloud Pak that includes various software, moving users onto that entitlement may reduce the need for separate user licenses. You typically can only change metrics at renewal or with IBM’s agreement, but it’s worth analyzing. Smart enterprises periodically re-evaluate each IBM software to ensure they’re on the optimal metric.
- Limit Unnecessary License Growth: Vendors love to sell more than you need “just in case.” Be wary of over-allocating user licenses. Set up a governance where any request for new licenses is justified by data (e.g., “we’ve added 10 new employees who will use this tool” or “our concurrency is at 90% capacity during peak hours, time for five more licenses”). Avoid “blanket” purchasing without analysis. By keeping license counts tight and based on demonstrated need, you reduce excess spending.
- Track and Adjust for Organizational Changes: Mergers, divestitures, new projects, or technology changes can all affect license usage. If you retire an old system, you may be able to reduce user licenses; if you onboard a new team, concurrent usage may increase. Integrate license management into IT’s change management process. For instance, if switching from an on-prem tool to IBM’s SaaS equivalent, ensure you end the old license agreement to avoid paying double. Agility in managing licenses in response to business changes will prevent wasted spend.
Every quarter or at least before any IBM negotiation, ask yourself: “Are we using what we’re paying for? And are we paying for the right model?”
By continually optimizing, you can often find double-digit percentage savings on IBM user licensing costs without harming any capabilities for your end users.
Negotiation Tactics for User-Based Deals
When it comes to negotiating with IBM, information and leverage are your best friends. User-based licensing deals have their own nuances that can be exploited.
Here are strategic negotiation tactics to employ:
- Secure True-Down Rights: IBM’s standard agreements often lock you into a set number of user licenses for the term, with no refunds or reductions if usage drops. Insist on true-down provisions, especially for multi-year deals or Enterprise License Agreements. True-down rights allow you to reduce the number of user licenses (and the associated cost) at specified intervals or upon renewal to match actual usage. This protects you if your user count decreases due to layoffs, project completions, or the adoption of alternative systems. For example, negotiate the ability to reduce up to, say, 10% of user licenses per year with a corresponding cost reduction, or at least the right to drop to the current usage level at renewal without penalty. Getting this in writing ensures you “pay for what you use” over time, not for shelfware.
- Cap Renewal Uplifts and Setting Multi-Year Rates: Don’t Accept the Default Maintenance or Subscription Uplift Blindly. A savvy procurement professional will negotiate price caps on year-over-year increases. If IBM plans a 7% annual uplift, push back to cap it at 3% or less, or even 0% for a certain period. In some cases, you can negotiate a fixed price for a 2-3 year term (no increases at all). Also, if you foresee needing more user licenses in the future, negotiate an add-on rate protection – for instance, any additional Authorized User licenses you buy in the next year will be at the same discounted price as the initial purchase. This prevents IBM from charging you a higher rate later once the initial deal is signed. The goal is to eliminate unpleasant cost surprises during renewals and growth.
- Benchmark and Leverage Alternatives: Come to the table armed with benchmarks and alternatives. IBM’s per-user pricing can sometimes look expensive when compared to other licensing metrics or even competitor products. Research what similar customers are paying (if possible) and conduct internal calculations comparing the cost per user to the cost per PVU or to a Cloud Pak bundle. Use these numbers in discussions: e.g., “At this price, it would be cheaper for us to license by processor cores, or even consider moving to Cloud Pak for Data, which covers this product.” If IBM knows you have done the math and are willing to switch metrics or architectures to save costs, they’re more likely to offer a better discount or deal on the user licenses to keep you on that model. Metric flexibility is a key lever – for instance, you might negotiate that at renewal you can convert some of your Authorized User licenses to an equivalent in PVUs or to IBM SaaS subscriptions, possibly with credits for what you’ve already paid. That wa,y IBM still retains the customer, but you get a model that might be more cost-effective.
- Bundle User Licenses into Bigger Deals: If you’re negotiating a broader IBM agreement (such as an Enterprise License Agreement or a large bundle purchase), use that scope to your advantage on user licenses. When user-based licenses are part of a larger deal, you have more leverage to get concessions. For example, you might tie an order of user licenses to a large middleware purchase and negotiate an extra discount on the user licenses or more lenient terms (such as reassignment rights or true-down, as we discussed). IBM sales teams have overall revenue targets – if adding your user licenses helps meet their goals, they may be willing to be more flexible on those. However, ensure that bundling actually benefits you: sometimes IBM will throw in “unlimited” user licenses for a product as part of a bundle, but at a premium cost that you wouldn’t have paid otherwise. Always evaluate the bundle versus standalone. If you do bundle, clearly document the specific terms for each component in the contract (don’t rely on friendly verbal assurances). The upside of a bundle is better pricing and a simplified contract; the downside is that you might pay for things you don’t need. So, negotiate to include only what you intend to use, and secure the per-unit economics for transparency.
In all negotiations, maintain a bit of healthy skepticism. IBM’s initial quotes and terms often favor IBM (naturally). It’s your job to question them. Request justification for how the price was determined. Challenge vague contract language and refine it. Use timing to your advantage (IBM representatives may have quarterly incentives – the end of the quarter can be a good time to press for that last bit of discount or a contract rider in your favor).
And, importantly, always have a walk-away alternative – whether it’s a competitor or an internal workaround – so that IBM understands you have options. With solid data and a firm stance on key points like true-down and pricing caps, you can turn IBM’s user-based licensing from a cost center rife with risk into a manageable, predictable investment.
Read about SaaS licensing, IBM SaaS Licensing: Structure, Pricing, and Compliance Guide
Checklist – Managing IBM User-Based Licensing
Use this quick checklist to ensure you’re covering the bases in managing and negotiating your IBM user-based licenses:
☐ User definitions clarified in contract – All terms (Authorized User, Concurrent User, etc.) are explicitly defined so there’s no ambiguity in who or what counts as a user.
☐ AU entitlements tracked and reclaimed – You maintain an up-to-date list of Authorized Users and have a process to remove or reassign licenses when people leave or no longer need access.
☐ Concurrent user logs monitored – You regularly monitor concurrent usage statistics to ensure you stay within limits and adjust license counts if needed.
☐ Floating license usage documented – For floating pools, you have license server reports or audit logs saved to prove compliance and to analyze utilization trends.
☐ Renewal uplifts capped – Your contracts include caps or fixed rates on maintenance/subscription price increases, so you won’t be caught off guard by rising costs each year.
☐ Flexibility to switch metrics negotiated – You have negotiated options to change the licensing model (e.g., move from user-based to CPU-based or to cloud subscriptions) if it would benefit your organization in the future.
By ticking off these items, you establish a robust governance framework for IBM user licensing, thereby reducing both cost leakage and compliance risk.
FAQs
Q: What is an IBM Authorized User license?
A: It’s a per-person license for IBM software. An Authorized User license is tied to a single named individual, granting them access rights. The license cannot be shared among multiple people. You can transfer it to another user only if your contract permits (for example, when the original user leaves the company and you reassign that license to a replacement, subject to IBM’s terms).
Q: What’s the difference between concurrent and floating users?
A: They are closely related concepts. A Concurrent User license limits how many users can be using the software at the same time (simultaneous logins), regardless of who those users are. A Floating User license is a type of concurrent license managed by a central license server that dynamically allocates a pool of licenses to any user who needs one. In essence, concurrent licensing is about the count of simultaneous usage, and floating is the mechanism that makes those licenses shareable across users by “floating” licenses to whoever is online and reclaiming them when they log off.
Q: Can Authorized User (AU) licenses be reassigned?
A: Yes, but only under certain conditions – and you should negotiate those conditions upfront. By default, an Authorized User license is intended for one person and isn’t freely transferable. However, most organizations negotiate the ability to reassign AU licenses when someone leaves or their role changes. Typically, the contract may allow for reassignment to a new user permanently (rather than frequent swapping) and may require the original user to cease using the software. Always ensure your agreement clearly states that you can reallocate the license to avoid paying for new licenses while old ones remain unused.
Q: Which user licensing model is most cost-efficient?
A: It depends on your usage patterns. Concurrent user licensing tends to be most cost-efficient if you have a large population of occasional users – it lets you buy a smaller number of licenses and share them, covering many people who use the software infrequently or in turns. Authorized user licensing can be more cost-effective when you have a stable team of users who each regularly use the software (so you don’t mind paying per user) or when concurrency is high enough that you’d end up needing nearly as many concurrent licenses as there are users anyway. In short, concurrent (or floating) licenses save money for broad, sporadic usage, whereas authorized users are efficient for smaller or steady, active user bases. It’s wise to analyze your actual usage data to make this decision.
Q: Can user-based licenses be converted to IBM’s PVU or Cloud Pak models?
A: Often, yes – but it requires negotiation, typically at a renewal or major contract change. IBM will typically allow you to convert from a user-based metric to a different metric (such as PVU, VPC, or Cloud Pak entitlements) if it makes sense for both parties, but you must request it. For example, if you’re moving your infrastructure to IBM Cloud Paks (which use virtual processor core licensing) or you determine a processor-based license would be cheaper, you can negotiate to transition your entitlements accordingly. Timing is key: the best opportunity to do this is at renewal or when you’re undertaking a major upgrade. When pursuing a conversion, try to get credit for the investment you’ve already made – e.g., have IBM apply the value of your existing licenses toward the new model. This flexibility is a powerful negotiation lever; IBM may be open to it ,especially if it aligns with their strategic products (like encouraging Cloud Pak adoption) or if it prevents you from considering non-IBM solutions. Always get the conversion terms and any pricing adjustments in writing to ensure a smooth switch.
Read about our IBM Licensing Assessment Service.
