What are Oracle EBS Concurrent Licenses?
Executive Summary: Oracle EBS concurrent licenses are a legacy licensing model for Oracle E-Business Suite that limits usage based on the number of simultaneous users, rather than named individuals.
This means you purchase the right for a maximum number of users to be logged into EBS simultaneously. While this approach can reduce costs for organizations with many infrequent users, it has been largely phased out.
Today, Oracle requires per-user or enterprise metrics instead. Understanding Oracle EBS concurrent licenses is important for IT asset managers handling older contracts, ensuring compliance, and planning transitions to modern licensing models.
Understanding Oracle EBS Concurrent Licenses
Oracle EBS concurrent licenses (also referred to as concurrent user licenses) enable a pool of users to share a limited number of license “slots” based on simultaneous usage.
In practice, if you owned 50 concurrent user licenses for Oracle E-Business Suite, any 50 users out of your total user base could be logged in at once.
The 51st user attempting to access EBS would exceed the limit unless another user logged off.
Key characteristics of concurrent licensing:
- Peak Usage Based: You license the maximum number of users active at one time, not every individual. For example, 200 employees might use EBS, but if only up to 50 are on concurrently, you would license 50 concurrent users.
- Floating Access: Licenses are not tied to specific names. Any authorized user can occupy a license as long as the total number of logged-in users stays under the purchased number.
- Dynamic Allocation: As users log out, their license slot becomes free for others. This is ideal for shift-based work or global teams where usage is staggered across time zones.
- Management Overhead: You must monitor active sessions to ensure the concurrent license count isn’t exceeded, since compliance depends on real-time usage. Tools or audit logs are needed to track the number of active EBS users at any given moment.
Simply put, an Oracle EBS concurrent license is about sharing licenses among many users, constrained by a headcount cap on simultaneous logins.
This was once a popular method for optimizing costs for large enterprises with distributed or part-time user communities.
Read Oracle EBS Licensing: Professional User vs. Employee User.
A Legacy Metric in Oracle’s Licensing History
Concurrent user licensing for EBS is a legacy metric, meaning Oracle offered it in the past but no longer does. In the 1990s and early 2000s, Oracle E-Business Suite modules could indeed be licensed by concurrent users.
Many long-time Oracle customers still have these terms in older agreements.
However, Oracle retired the concurrent model over a decade ago as part of its modernization of licensing.
- By the mid-2000s, Oracle began standardizing on named-user (per individual) licensing for its applications and database products. The Concurrent User metric for EBS was gradually phased out.
- Today, you cannot buy new Oracle EBS concurrent licenses. Oracle’s price lists and contracts now utilize metrics such as Application User (named user per module) or Enterprise (e.g., per Employee or Revenue) for E-Business Suite.
- Grandfathered Use: If your organization already owns EBS concurrent user licenses from years past, you are typically allowed to continue using them (with active support). Oracle honors legacy entitlements on current software versions as long as you keep paying support maintenance. This means an old 50 Concurrent User license for EBS can still be used on the latest EBS release – but only within the originally licensed scope.
- No Mix-and-Match Additions: If you need additional EBS licenses now, Oracle will insist on the modern metrics for those new licenses. You can’t directly purchase more concurrent user licenses to expand capacity. This sometimes forces a mixed environment or, more commonly, a conversion of the legacy licenses into the new model during a renewal or upgrade.
In summary, Oracle EBS concurrent licenses belong to a past era of Oracle licensing. They underscore how Oracle’s policies have evolved.
ITAM professionals dealing with legacy contracts must interpret these older terms carefully, since they don’t align with Oracle’s current standard metrics.
Concurrent vs. Named User Licensing in EBS
Understanding the difference between concurrent user licensing and the modern named user licensing (often referred to as Application User in EBS) is crucial.
The table below compares these two models in the context of Oracle EBS:
| Licensing Metric | How It Works | Use Case | Current Status |
|---|---|---|---|
| Concurrent User (legacy EBS) | Licenses a maximum number of users who can be logged in at the same time. For example, 50 concurrent users allow any 50 people out of a larger pool to use EBS simultaneously. | Historically useful for large user bases with relatively few active concurrently (e.g. global companies with users in shifts or time zones). It minimizes license count when many users only occasionally log in. | Retired metric – no longer sold. Only available in older contracts. New expansions require converting to a current model (named user or enterprise). |
| Application User (Named User) | Licenses each individual person authorized to use a specific EBS module, regardless of how often they use it or concurrent access. For example, 50 Financials Application Users means 50 specific named individuals can access the Financials module (all 50 could log in at once if needed). | Suitable for organizations where many or all users are regularly active. Simplifies compliance tracking since every user is counted upfront. No concern about simultaneous usage limits – all licensed users can use the system anytime. | Standard metric today for Oracle EBS. Required for new licenses. Concurrency does not apply (licenses are per named user per module). |
In practice, under named user licensing, if you have 200 users who need EBS access, you must purchase 200 user licenses (even if only 50 users use the system at a time).
Under a concurrent model (if it still existed), you could license just the peak 50.
This illustrates why concurrent licenses were financially attractive in some scenarios. However, named user (Application User) licensing is far simpler for Oracle to audit and administer.
Operational differences:
- Compliance Tracking: With Application User licenses, compliance is a straightforward count of user accounts per module. With concurrent licenses, compliance involves monitoring the peak concurrent login count and ensuring it never exceeds the licensed number – a constantly changing target.
- Unused Accounts: Named user licensing charges for every account, even infrequent ones, which often leads ITAM teams to purge or deactivate idle accounts to optimize costs. In a concurrent scheme, having extra user accounts isn’t a direct cost issue as long as they aren’t all active at once (though too many users increases the risk of hitting concurrency limits unexpectedly).
- Cost Profile: Concurrent licensing can be cost-efficient if usage is low relative to the total number of users, but each concurrent license historically costs more than a single named-user license. Oracle priced concurrency at a premium because one concurrent license could cover multiple people’s usage (just not simultaneously). For example, one legacy concurrent user license might have been equivalent in price to ~2 or more named user licenses. Thus, organizations had to analyze their user patterns to see if concurrency truly saved money.
Why Oracle Retired Concurrent Licensing
Oracle moved away from Oracle EBS concurrent licenses for several strategic and practical reasons:
- Auditability and Control: Concurrent usage is harder for Oracle to track. It relies on peak usage logs rather than static user counts. By shifting to named user and processor-based models, Oracle can more easily audit compliance (simply by requesting user lists or hardware specs). The concurrent model introduced uncertainty – Oracle had to trust customer-provided usage reports for peak counts, which is less straightforward than counting licenses against HR rosters.
- Revenue and Predictability: With named user licensing, Oracle ensures that every potential user is licensed, which often results in increased total license sales. Concurrent models, while customer-friendly, could reduce Oracle’s revenue if only a fraction of users are ever on at once. By eliminating concurrency, Oracle encourages organizations to focus on metrics that typically require higher license quantities or fees, resulting in more predictable and sometimes higher revenue streams for Oracle.
- Complexity of Modern Use: As enterprise systems grew, distinguishing simultaneous usage became more complex. Web and mobile access, integration jobs, and global 24/7 operations mean usage patterns aren’t confined to 9–5 shifts. In many companies, a large percentage of users might be connected throughout the day, eroding the benefit of a concurrency cap. Oracle addressed this by favoring per-user or per-employee metrics that assume broad usage.
- Alignment with Technology Changes: Oracle’s licensing updates coincided with new technology.
- Multi-Core Servers: Oracle introduced processor-core licensing (and Named User Plus for databases) as multi-core CPUs became common. Charging per core or user made more sense than per concurrent session, especially for backend systems. In Oracle EBS (which runs on Oracle DB), limiting by concurrent users was somewhat orthogonal to the real driver of usage – the underlying database and app server load.
- Oracle Fusion & Cloud: Oracle’s newer cloud offerings and Fusion applications all utilize subscription models with named users or consumption-based metrics. Concurrency doesn’t fit SaaS models where each subscription is per user or resource. Oracle’s roadmap encourages customers to migrate from EBS to Oracle Cloud ERP, standardizing on non-concurrent metrics.
- Portfolio Consolidation: Following the acquisition of companies such as PeopleSoft, JD Edwards, and Siebel, Oracle sought to standardize its licensing terms. Each had its legacy metrics (some also offered concurrent user licensing). Oracle EBS concurrent licenses were phased out as part of creating a unified licensing framework across Oracle’s product line.
From Oracle’s perspective, retiring concurrent licenses simplifies license management and reduces loopholes. For customers, it removed a flexible option, but in exchange, Oracle often offers volume discounts or enterprise metrics for large implementations.
Understanding this shift helps ITAM professionals negotiate more effectively: for instance, if concurrency is desired for cost reasons, one might negotiate an enterprise metric deal (such as an unlimited user license or an employee-based license) as an alternative, since pure concurrency caps are off the table.
Compliance and Audit Considerations
For organizations still using Oracle EBS concurrent user licenses, compliance management is critical.
Oracle’s License Management Services (LMS) or Global Audit (GLAS) teams can audit your EBS usage to ensure you never exceed the allowed concurrent user count. Non-compliance (even unintentional) can result in hefty back-license fees.
Here’s what to watch:
- Monitoring Peak Usage: Implement real-time monitoring to track the number of active EBS users. This can involve:
- System Logs & Scripts: Use Oracle EBS administrative reports or database queries to capture concurrent session counts. For example, querying Oracle’s system tables for active user sessions over time can identify the maximum concurrent users in a given period.
- License Monitoring Tools: Some third-party ITAM tools or Oracle’s management packs can be configured with your concurrent license limit and alert you when usage nears/exceeds the threshold.
- Auditor Methods: Be aware that Oracle auditors may request evidence of your user counts. They could run scripts during an audit that log user session activity or ask for historical usage data. It’s wise to maintain an audit trail, such as archived logs or screenshots of monitoring dashboards, to demonstrate that concurrent usage remained within the licensed limit.
- Peak vs. Average Trap: Don’t assume compliance because “on average” you only have a certain number of users. Licensing is based on the peak concurrent count, even if a spike happened briefly. One busy end-of-quarter day where 55 users logged in (against a limit of 50) technically puts you out of compliance. Design processes to prevent or quickly remediate such spikes:
- Limit the creation of new user accounts or concurrent sessions once the cap is reached (some companies use soft limits or manual oversight during critical periods).
- Encourage users to log out when not actively using the system, especially if licenses are limited. Idle sessions can eat up a concurrent slot.
- Legacy Contract Nuances: Review the exact definition of “Concurrent User” in your contract. Some legacy agreements had specific conditions (e.g., excluding certain read-only accounts or specifying internal versus external users). Understanding these details can be vital. For instance, a contract might have allowed only internal employees under concurrent user licenses, while external parties had to be handled differently.
- Audit Negotiation: Interestingly, the ambiguous nature of concurrency can sometimes give customers wiggle room. Unless Oracle has clear evidence (such as automated logs) of an overage, there may be debate on whether a violation occurred. That said, it’s risky to rely on ambiguity. A safer approach is to stay well below your limit or formally migrate to a clearer licensing model before any contention arises.
Bottom line: treat the concurrent user limit as a hard cap. Proactively monitor and govern usage to ensure compliance even during peak periods.
This may involve strict internal controls, such as temporarily blocking additional logins once the limit is reached, or scheduling heavy activities (like batch jobs or data entry blitzes) to avoid overlap.
Cost Implications and Optimization Strategies
Oracle EBS concurrent licenses were attractive because they could significantly lower costs in the right scenario. If you had a large user base with intermittent access needs, concurrency meant you didn’t pay for all those occasional users.
However, with Oracle’s shift to named user licensing, enterprises must find new ways to optimize costs:
- Cost Trade-Off: If your organization once saved money via 50 concurrent user licenses instead of, say, 200 named user licenses, losing that model could raise costs. It’s important to quantify this. Calculate how many named user licenses would be needed if you migrated, and compare it to your current support costs for the concurrent licenses. Often, Oracle may offer a conversion deal (e.g., a credit or a formula like 1 concurrent user = 2 named users), which you need to evaluate against your actual usage pattern.
- No Auto-Reduction: Please note that with named user metrics, you are charged for every user, regardless of usage. There’s no automatic reduction in cost if many users are inactive. This makes periodic user true-ups important – remove or reassign licenses from users who no longer need access. An active user management process can prevent overspending.
- Enterprise License Options: For very broad but light usage (for example, thousands of employees who might only occasionally use self-service functions), consider Oracle’s enterprise metrics:
- Employee-based licensing: Pay per total number of employees. This covers everyone in the organization at a fixed rate. It eliminates tracking individual usage and might be cost-effective if essentially all employees benefit from the system in some way.
- Revenue-based or other metrics: Less common in EBS, but some deals are licensed based on a business metric (e.g., revenue, or number of orders processed). These can sometimes substitute for concurrent style usage by decoupling the cost from user count altogether.
- These enterprise metrics shift costs to a broad measure and allow unlimited concurrent users, at the expense of tying costs to company growth (if your headcount or revenue grows, costs also rise).
- Modular Approach: Optimize on a module-by-module basis. Perhaps not all parts of EBS need full user licenses. For example, if you have an iExpenses module (employee expense reports), Oracle might allow licensing that module per number of expense reports annually instead of per user. In a sense, that’s akin to concurrency or usage-based licensing. Leverage such options for modules where user counts are very high but individual usage is low.
- Negotiating Concessions: If migrating off a concurrent model, you can negotiate with Oracle for price protection. For instance:
- Request grandfathering credit: value the licenses you have already paid for and apply that value toward the cost of new licenses.
- Tiered pricing or bundles: Oracle may bundle multiple modules or offer volume discounts when you switch to named user licensing for the entire suite. Use the fact that you’re giving up a favorable legacy metric as leverage to secure a better discount.
- Limit support increase: Ensure that if your license count multiplies when converting to named users, the annual support (typically ~22% of license cost) doesn’t skyrocket unexpectedly. Try to negotiate caps on support fee increases as part of the conversion.
- When concurrency is not missed: In some cases, usage has grown so much that a concurrent cap would no longer save money. If nearly all users are active daily, moving to named user or processor licensing could make sense operationally. Evaluate your current usage patterns honestly – you might find that what was once a cost saver (concurrent) is now a constraint (if you’re constantly at the limit, it’s risky and not saving much). In such cases, transitioning to a more scalable metric can be beneficial, provided it’s negotiated well.
In essence, optimize within Oracle’s current rules. While Oracle EBS concurrent licenses are effectively a thing of the past, the goal of cost optimization remains.
ITAM professionals should use a combination of strict user management, alternative metrics, and savvy negotiation to achieve a similar outcome under the named-user regime.
Recommendations
Here are practical tips for IT asset managers dealing with Oracle EBS licensing (including any concurrent license legacy situations):
- Inventory Your Licenses: Begin by determining if your Oracle EBS contract includes concurrent user licenses or other legacy metrics. Knowing what you have is the first step to managing it.
- Review Contract Definitions: Read the fine print on how “Concurrent User” is defined in your Oracle ordering documents. Ensure you understand any conditions or exceptions specific to your agreement.
- Monitor Regularly: Implement continuous monitoring of EBS usage to ensure optimal performance. Use scripts or monitoring tools to track the number of active sessions, and get alerts when usage approaches your licensed limit (e.g., 80% of concurrent capacity).
- Enforce Logout Policies: Educate users and enforce policies to prevent sessions from remaining idle. Consider implementing session timeouts or manual processes to clear inactive logins, thereby preventing them from consuming license slots unnecessarily.
- Plan for Peak Scenarios: Anticipate peak usage events (financial closes, seasonal spikes, etc.). If a surge might exceed your concurrent license count, plan mitigating actions in advance or obtain temporary rights if possible (Oracle may offer short-term licenses, though not for concurrency specifically – but you could add some named users temporarily).
- Engage Oracle Proactively: If you foresee needing more user capacity than your legacy licenses allow, engage Oracle early. Proactively negotiating a conversion or expansion deal will go smoother than a last-minute scramble during an audit or a system lockout.
- Negotiate Conversion Favors: When converting legacy concurrent licenses to modern metrics, negotiate aggressively to ensure a favorable outcome. For example, push for conversion ratios that favor you (e.g., one concurrent = multiple named users) and seek discounts to offset any cost increase.
- Leverage Enterprise Metrics: Evaluate whether an enterprise metric (like licensing by employee count) could be more cost-effective for your usage profile. If yes, bring this up in negotiations as an alternative to licensing every single user by name.
- Stay Informed on Policy Changes: Oracle licensing rules can evolve. Stay updated via Oracle’s official licensing documents or advisor communities, so you know if any new licensing models or audit practices emerge that could impact your EBS environment.
- Document and Archive Usage Data: Keep records of your concurrent usage monitoring. In a dispute or audit, having historical data showing you remained within limits is invaluable. It demonstrates good governance and can be used to challenge any inaccurate claims.
Checklist: 5 Actions to Take
- Locate Legacy Metrics in Contracts: Review your Oracle E-Business Suite license agreements and identify any line items or metrics labeled “Concurrent User” (or other legacy terms, such as “Professional User”). Create an internal summary of these entitlements (module, number of concurrent users licensed, etc.).
- Measure Your Current Usage: Work with your DBA or EBS administrator to gather data on peak concurrent usage. For example, over the last 3-6 months, what was the highest number of simultaneous EBS logins observed? Compare this peak to your licensed concurrent user count to assess compliance headroom or risk.
- Implement Usage Controls: If not already in place, set up mechanisms to control usage.
- Enable monitoring scripts or tools to track active sessions.
- Enable session timeout settings in Oracle EBS to automatically log out inactive users after a specified period.
- Inform end-users about the importance of logging out when finished.
These steps ensure you stay safely below your concurrency cap and can act quickly if usage spikes.
- Develop a Contingency Plan: What if your business needs suddenly increase (e.g., adding new EBS users or a spike in access)? Formulate a plan with management.
- Could you restrict some users’ access during peak times to stay compliant?
- Is there budget and approval to convert to named user licenses if necessary? Obtain a rough conversion quote from Oracle to understand the financial impact in advance.
- Identify any non-essential usage that could be limited or scheduled during off-peak hours.
Being prepared will help avoid panic or non-compliance if usage grows.
- Engage in License Optimization Talks: Proactively reach out to Oracle or a licensing consultant to discuss optimization. Explain your usage pattern (e.g., “We have 500 total users but never more than 50 at once”) and explore options. Oracle might propose an alternative licensing scheme or a custom agreement. Use this dialogue to your advantage—aim to maintain cost efficiency while aligning with a supported metric. Any changes you agree on should be documented in a contract amendment to protect your organization’s rights.
By following this checklist, you’ll have a clear understanding of your Oracle EBS concurrent license situation and be prepared to manage or transition off it with minimal risk.
FAQ
Q: Does Oracle still offer concurrent user licenses for E-Business Suite?
A: No. Oracle no longer sells concurrent user licensing for EBS. It’s a retired model. All new Oracle EBS licenses must use current metrics, such as per Application User (named user) or an enterprise metric. If you see “concurrent licenses” in a new proposal, it’s likely a mistake or a custom negotiation; by default, Oracle will not provide concurrency-based pricing today.
Q: We have some Oracle EBS concurrent licenses from years ago – can we keep using them?
A: Yes, if you already own them and remain on support, you can continue to use those licenses under the original terms. Oracle permits grandfathered use of legacy licenses. This means even on the latest EBS 12.x release, your old concurrent user licenses are valid. However, any additional licenses you need (for more users or new modules) will have to be on the modern metrics. Be cautious: if you make significant changes (such as a major upgrade or merging contracts), Oracle may attempt to migrate you away from those old licenses.
Q: How can we track and ensure we don’t exceed our concurrent user limit?
A: To manage compliance, you should actively monitor EBS usage. Oracle EBS itself doesn’t pop up a warning when you go over your license count – it’s on you to prevent that. Use a combination of:
- Admin Reports or Scripts: Oracle provides administrative reports (and you can write SQL queries against EBS or database session tables) to count active user sessions. Run these regularly.
- Third-Party Tools: Consider ITAM or monitoring tools that specifically track license usage. Some tools allow you to configure your license count and will alert if the concurrent session count exceeds a threshold.
- Periodic Audits: Conduct an internal audit of your usage on a monthly or quarterly basis. Simulate an Oracle audit by capturing peak concurrent user counts over that period and document the results.
By doing this, you’ll catch any trend toward overuse and can take corrective action before it becomes a compliance issue.
Q: What happens if we occasionally exceed the concurrent user count without realizing it?
A: Technically, if at any point you had more users logged in than you were licensed for, you were out of compliance. Oracle could, in an audit, demand that you back-license those excess usages – typically by purchasing additional licenses (based on current metrics) and paying back support fees. In reality, a one-time or very brief overage might not be easy for Oracle to detect or prove unless its audit captures that exact data. Regardless, it’s risky to assume you’re under the radar. If you suspect there were overages (even unintentional), it’s wise to rectify proactively:
- You could quietly reduce accounts or impose stricter controls to prevent it from recurring.
- If the overage is due to permanent business growth, approach Oracle to discuss a proper licensing adjustment rather than waiting for an audit. It’s usually better to negotiate a reasonable true-up than to face an audit finding.
Remember, Oracle audits often review usage logs and compare named accounts to licenses. Alternatively, in the case of concurrency, they may run tools during the audit period to capture usage. It’s best to assume any sustained pattern of overage will be caught.
Q: What are our options if we need to support more users but can’t get more concurrent licenses?
A: Since Oracle won’t sell new concurrent licenses, you have a few options:
- Convert to Named User Licensing: This is the most direct path. Determine the number of actual users who need access and purchase the corresponding Application User licenses for the relevant modules. Oracle might provide a credit for the value of your existing concurrent licenses during this conversion. Ensure all modules are covered, as named licenses are specific to each module.
- Enterprise License Agreement: If the user count is very large, consider an enterprise metric (like an Unlimited License Agreement for EBS or licensing by employee count). This can cover all users enterprise-wide for a fixed price, removing the concern of counting individual users or concurrency. It often makes sense when you have thousands of users or a plan to expand significantly.
- Partial Migration (Hybrid Model): In some cases, companies retain their existing concurrent licenses for a portion of users and purchase additional named user licenses for new users. For example, you might keep 50 users on the concurrent model and add 50 named user licenses for growth. This can be complex to manage (two different metrics simultaneously), but it’s a way to incrementally transition. If you do this, clarify with Oracle how compliance will be measured (you wouldn’t want them to double-count the same users).
- Optimize Usage: Before buying anything, ensure that all existing accounts are necessary. If you can free up some concurrent capacity by removing dormant users or better scheduling, that might delay the need for more licenses.
Ultimately, engaging with Oracle to meet your forecasted needs is important. They may propose a specific migration plan. As an enterprise customer, you should carefully evaluate the proposal or consult a licensing expert to ensure it’s cost-effective. Oracle’s first offer might not be the best one – everything is negotiable in an enterprise agreement.
