BusinessObjects BI Licensing Explained: Named Users, Concurrent Sessions & CPU Metrics

Why BusinessObjects Licensing Still Matters

Even in today’s cloud-first world, many enterprises continue to run SAP BusinessObjects (BOBJ) alongside newer analytics tools.

These hybrid BI landscapes (think BusinessObjects plus SAP Analytics Cloud or even non-SAP BI tools) mean BusinessObjects BI license models remain highly relevant.

Mismanaging your BO licenses can lead to costly shelfware (licenses paid for but never used) and unexpected compliance risks during audits. On the flip side, having clarity on BusinessObjects licensing gives you negotiation leverage and helps cap costs.

In short, understanding SAP BO license types isn’t just an IT concern – it’s a strategic procurement priority for controlling spend and avoiding waste.

For an overview, read SAP Analytics & BI Licensing Guide.

BusinessObjects License Models at a Glance

SAP BusinessObjects offers three primary licensing models, each with distinct advantages and drawbacks. The right choice depends on how your users access the system and the scale of your deployment.

Let’s break down the models:

• Named-User Licenses – These are tied to specific individuals. Each user is assigned a license that grants them access at any time. This model offers predictability since you pay per named person, making usage easy to track. However, it can become expensive if over-allocated – for example, if you purchase more named licenses than the number of active users (resulting in shelfware). Best fit: small to mid-sized teams with stable, consistent usage by each user.
• Concurrent Session Licenses – These licenses enable a pool of users to share access, with a limit of active sessions at any given time. In practice, you might have hundreds of users in the system, but if only (say) 50 are ever logged in at the same time, a 50-session concurrent license could cover it. This model offers flexibility and is cost-effective for organizations with numerous infrequent or occasional users. The risk is hitting the session cap: if your peak usage exceeds the licensed concurrent sessions, additional users trying to log in will be blocked (or you’ll need to buy more licenses). There’s also potential session contention – one heavy user could consume multiple sessions or keep sessions open, tying up licenses. Best fit: larger organizations with a broad user base who use BI sporadically rather than all at once.
• CPU-Based Licenses – This model is priced by server processing capacity (typically by the number of server CPU cores on which BusinessObjects is installed). It allows an unlimited number of users and sessions – usage is unrestricted, as long as you don’t exceed the licensed CPU resources. CPU-based licensing was often used for large-scale deployments where counting individual users was impractical. Its strength is scalability: as your usage grows, you don’t need additional user licenses, theoretically. However, cost can skyrocket if servers are oversized or not optimized; you’re paying for raw hardware capacity whether or not it’s fully utilized. In virtualized or cloud environments, every vCPU counts as a core; therefore, over-provisioning cloud instances can inadvertently trigger the need for additional CPU licenses. Best fit: very high-volume enterprise BI environments or external-facing scenarios where user counts are unlimited – but beware, this model needs careful sizing to avoid overpaying. (Note: CPU licensing is a legacy approach and not offered in newer contracts, but many firms still have it in place.)

Below is a comparison of these BusinessObjects licensing models and their cost profiles:

Deployment Considerations — On-Premise vs. Private Cloud

Licensing implications can vary depending on whether your BusinessObjects deployment is on-premises or in a cloud environment (including SAP’s Private Cloud Edition for BO). Here’s what to consider:

• On-Premise BusinessObjects: Traditionally, on-premises BusinessObjects use a perpetual licensing model. You purchase licenses (whether named, concurrent, or CPU) upfront and then pay annual maintenance (support fees, typically ~20% of license price each year). The benefit is that you own the licenses indefinitely. However, you must manage the infrastructure and ensure compliance independently. If you scale up (i.e., add more users or CPU cores), you will need to procure additional licenses accordingly. One challenge in on-premises setups is license inertia – companies often purchase more licenses than needed, “just in case,” resulting in shelfware that remains unused while maintenance fees continue to accrue.
• BusinessObjects in a Private Cloud (Hosted): SAP now offers BusinessObjects Private Cloud Edition (PCE) and similar hosted solutions. These are typically subscription-based. Instead of perpetual licenses, you pay an annual subscription fee, which often bundles the software license, infrastructure hosting, and support in one. The metrics for PCE subscriptions can be a mix – SAP might size your subscription by the number of named users or concurrent users, as well as by the hardware capacity allocated. (For example, PCE may offer “t-shirt sized” packages like Small, Medium, Large, based on a combination of user counts or concurrency limits and system resources.) In a cloud subscription, you gain flexibility to scale, and SAP handles the infrastructure. Still, you may end up effectively re-licensing your environment: your existing on-premises licenses typically cannot be applied directly to SAP’s cloud service. This transition needs careful negotiation to avoid paying twice.
• Hybrid Deployment (On-Prem + Cloud): Many enterprises are in transition – keeping some BusinessObjects on-premises while starting to use cloud analytics or moving some BO workloads to a hosted cloud. A big risk here is dual entitlements or overlap. For instance, if you move a portion of users to a cloud subscription while retaining all your on-premises licenses, you may be paying for more capacity than you actually need during the migration period. It’s essential to align contracts to avoid double coverage. Also, moving BO to a new environment (like AWS/Azure) under a CPU license model requires checking your contract: ensure virtual cores are counted properly and consider rightsizing servers to avoid non-compliance (adding CPUs without licensing them) or unnecessary cost.

In summary, on-premise licensing gives you control and perpetual rights but can lead to locked-in costs (maintenance on unused licenses).

At the same time, private cloud offerings convert BO into a service – potentially easier to manage, but requiring new contracts and vigilant oversight to avoid overlap and ensure you get credit for what you already paid for.

Read SAP Analytics Cloud Licensing: Subscription Models, User Types & Cost Control.

Where BusinessObjects Costs Escalate

It’s easy for BusinessObjects licensing costs to balloon if not actively managed. Here are common areas where costs can escalate and value leaks away:

• Shelfware: Perhaps the biggest source of waste. Shelfware refers to licenses that have been purchased but sit idle (like boxes on a shelf). In a BO context, this could involve hundreds of named-user licenses assigned to individuals who never log in, or extra concurrent session capacity that remains unused. Companies may overbuy licenses during initial purchases or renewals (often due to overestimation or sales pressure), and then continue paying annual maintenance fees on those unused licenses. This is essentially throwing money away year after year. Regular usage audits can help identify shelfware, allowing you to trim it.
• Overallocation & Wrong Model Selection: How You Allocate License Types Matters. One common mistake is assigning a named license to every user by default, even if many of those users rarely use the system. If 1,000 users have named licenses but only 100 are active at any time, that’s a classic overallocation – a concurrent session model would likely cover that usage with far fewer licenses. Conversely, some companies stick strictly to concurrent licenses, even for power users who are always on the system; those frequent users might have been better off with named licenses (especially if concurrent slots fill up). Choosing the wrong model (or sticking to an outdated one) can mean you’re overpaying for your needs. For example, paying for a large CPU-based license on a powerful server when only a handful of users are active is overkill; a smaller server or a user-based approach could be more cost-effective. It’s vital to align the license model to your actual usage pattern.
• License Stacking and Mixing Models: SAP generally does not allow mixing certain license metrics on the same environment (for instance, you wouldn’t combine CPU-based licensing with concurrent sessions on one deployment – compliance monitoring would be complex). However, companies sometimes end up with a form of “license stacking” when they expand or upgrade: for example, purchasing new named-user licenses for a component that’s already covered under a CPU license umbrella, or maintaining a CPU license while also adding concurrent licenses for new users. If done incorrectly, this can lead to paying twice for the same capability. The key is to evaluate your entire license landscape holistically. You may decide to consolidate into one model rather than juggling multiple. Whenever you add a new license type, consider whether it overlaps with existing entitlements.
• Audit Risk (and Unexpected Fees): If your usage quietly exceeds what you’re entitled to – for example, more named users exist in the system than you have licenses for, or your peak concurrent sessions occasionally go beyond your purchased number, or you’ve increased server CPUs without updating your license count – you are out of compliance. SAP (or any software vendor) can discover this in an audit. The result can be hefty “true-up” bills or penalties to back-pay for overuse, often at list prices. Aside from the direct financial impact, an audit scramble consumes a significant amount of internal time and can derail budgets. Preventative monitoring is crucial: track how many users actually use BO, how many sessions run concurrently at peak, and what your hardware setup is, so you can proactively adjust licenses before SAP knocks on the door.

Understanding these pitfalls is the first step. Next, let’s look at how to negotiate with SAP and optimize your contract to keep costs under control.

Negotiation & Cost Control Tactics

Negotiating SAP BusinessObjects licensing (especially during contract renewals or expansions) is where procurement leaders can significantly reduce cost overhead.

Here are several tactics and strategies to consider:

• License Model Flexibility: From the outset, try to negotiate the flexibility to switch license models or re-balance the mix as your needs evolve. For example, if you initially purchased a block of named-user licenses but find that a concurrent model would better suit new user groups, request that SAP allow a conversion of some licenses to concurrent session licenses (CSLs). Similarly, secure the option to swap licenses (sometimes called license swapping rights) – this means if you end up with an excess of one type, you can convert them to another type or even other SAP products of equivalent value. SAP won’t volunteer this, but customers have had success requesting it, especially if it’s framed as a way to remain a long-term SAP customer as needs change.
• Cap or Reduce Maintenance Fees: If you’re on legacy perpetual licenses, maintenance fees are the annual tax you pay to SAP for support and updates. These typically run ~20-22% of the license’s upfront cost each year. Over many years, you may end up paying more in maintenance than the original license cost. There’s room to negotiate here. Push for a cap on the maintenance percentage or, at the very least, a freeze on increases. In some cases, if you can’t reduce the percentage, consider negotiating credits or reduced maintenance on software licenses (or better, terminate maintenance on licenses you don’t use). Another angle: if SAP is pushing you to transition to a cloud model, use that as an opportunity to negotiate maintenance concessions on the remaining on-premises licenses during the overlap period.
• Clarify CPU Definitions and Rightsizing: If you have any CPU-based licenses, nail down the exact definition of a “CPU” in your contract. Does it refer to physical cores, virtual cores (vCPUs), processor sockets, etc.? This becomes crucial if you virtualize or move to cloud infrastructure. Ideally, negotiate terms that favor you – for instance, if your contract was written in an era of physical servers, clarify how it applies to virtual environments (e.g., maybe agree that a certain number of vCPUs count as one licensed CPU to avoid doubling costs). Additionally, when planning infrastructure changes, coordinate with licensing to negotiate a temporary allowance or a specific core count freeze. Example: If you know you’ll need to scale up hardware for a short-term project, negotiate in advance that you won’t be charged for extra CPUs if they’re removed later, or get a grace period to acquire additional licenses. SAP can be amenable to such terms if asked, rather than dealing with it post-audit.
• Eliminate or Reallocate Shelfware: Use renewal time to purge your shelfware. Audit your usage beforehand (there are tools and SAP’s own License Measurement tools that can help quantify actual usage). Go into negotiations with data: “We have 500 licenses but only 300 active users – we want to drop 200 licenses from maintenance.” SAP sales reps may resist outright termination because it cuts their revenue; a strategy here is to trade those unused licenses for something you do need. Perhaps you can consolidate and receive credit – e.g., drop 200 named users and in exchange, add 50 concurrent licenses or apply the value towards a new SAP product, such as Analytics Cloud. The goal is not to pay maintenance on anything you aren’t using. Make it clear you’re prepared to right-size, and get quotes for a reduced license count. Often SAP will come around with an offer to convert shelfware into other licenses or offer a discount to keep them with reduced scope, rather than lose the maintenance revenue entirely.
• Negotiate Pricing Caps and Renewal Terms: If you’re signing a multi-year agreement or subscription, try to lock in pricing terms. For instance, negotiate a cap on annual price increases for subscriptions or a cap on the cost of additional licenses in the future (this prevents surprises if you need to expand later). Ensure any unit price for additional named users or concurrent sessions is fixed or has minimal escalation for the term of the contract. Additionally, clarify renewal options: do you have the right to reduce quantities at renewal without penalty? It’s better to have that written in, so you’re not forced into paying for the same number of licenses if your usage drops.

By employing these tactics, companies can often trim significant fat from their BusinessObjects licensing costs – sometimes achieving double-digit percentage reductions – all while maintaining the flexibility to scale as needed.

Example Scenario — Cutting BO Licensing Costs by 30%

To illustrate how these strategies come together, consider this simulated scenario based on a composite of real cases:

Starting point: A large enterprise had 5,000 named-user licenses for SAP BusinessObjects, purchased years ago when “everyone” was given access. Over time, usage patterns changed, and an internal audit revealed only about 2,000 individuals actively used BusinessObjects in a typical month. The other 3,000 licenses were essentially unused or used very occasionally. The company was also paying a hefty annual maintenance fee for all 5,000 licenses.

Action taken: At renewal, the IT and procurement team negotiated a license model shift. They decided to retain named-user licenses for the 2,000 heavy or steady users, but to handle the rest more efficiently. They secured an agreement to convert 2,500 of the unused named licenses into a pool of concurrent session licenses. Based on usage analysis, they determined that a pool of around 300 concurrent sessions could comfortably support the periodic access needs of those intermittent users (instead of 2,500 separate named licenses!). The remaining 500 truly excess licenses were terminated outright, removing them from the contract (and halting their maintenance costs). Additionally, the company had been considering a hardware upgrade for performance; since they were under a CPU-based license for one particular backend system, they negotiated a clause to freeze the CPU license metric at the current core count – meaning adding a few extra cores for performance would not immediately trigger a need to buy more licenses.

Outcome: These changes resulted in a roughly 30% reduction in annual BusinessObjects spending. The mix-and-match approach – a smaller set of named users combined with a moderate concurrent license pool – aligns more closely with the actual usage profile, eliminating the need to pay for thousands of idle accounts. Maintenance fees dropped accordingly with the lower license count.

Moreover, by clarifying the CPU terms, they avoided an unexpected cost increase when scaling infrastructure. This scenario illustrates the potential savings that can be achieved by actively managing and negotiating BO licenses, rather than passively renewing the status quo.

IT & Procurement Checklist — Managing BusinessObjects Licensing

Use the following checklist to keep your BusinessObjects licensing under control and aligned with your organization’s needs:

• ☐ Identify your current BO license mix: Document how many licenses of each type you have (named user, concurrent session, CPU-based) and which contracts or bundles they belong to. Understanding your entitlements is step one.
• ☐ Audit actual usage vs. entitlements: Measure how many users actually log in and how often, what your peak concurrent usage is, and how many CPU cores you’re running for BO. Compare this with what you’re licensed for. This usage gap analysis clearly reveals underutilization (or overutilization).
• ☐ Remove or reallocate shelfware: For any licenses not being used, plan to eliminate them or convert them to a more suitable type. This might involve reclaiming named-user licenses from former employees, consolidating roles so that fewer people truly need access, or swapping unused licenses for other products or models that will be utilized.
• ☐ Negotiate renewal terms in advance: Don’t wait for the renewal quote to take action. Months before renewal, hold open discussions with SAP or your reseller about potential adjustments, such as reducing quantities, converting models, or securing better maintenance rates. Ensure any agreement is in writing to avoid surprises. If you’re moving to a cloud or hybrid model, negotiate transitional arrangements (like credits for unused on-prem licenses toward cloud subscriptions).
• ☐ Plan for hybrid/cloud transition impacts: If your roadmap includes migrating some BusinessObjects workload to SAP’s cloud (or another platform), factor that in. Coordinate so that you’re not caught paying for dual running environments longer than necessary. For example, if adopting SAP’s BusinessObjects Private Cloud Edition, time the ramp-down of on-prem licenses to coincide. Also, verify how your current licenses can or cannot be applied in new environments – and get any needed contract amendments to cover new deployment scenarios.

By following this checklist periodically (at least annually and before any contract talks), you’ll maintain control over your BusinessObjects licensing and avoid common cost traps.

FAQ — BusinessObjects BI Licensing

Q: What’s the difference between named-user and concurrent-session licensing?
A: A named-user license is assigned to one specific person (the named individual) and allows them unlimited access to BusinessObjects anytime. A concurrent-session license, on the other hand, is not tied to a single user; instead, it allows a specified number of active sessions to occur simultaneously. For example, 20 concurrent-session licenses mean up to 20 users can be logged in simultaneously. The key difference is flexibility: named-user licenses are one license per person (whether or not they’re actively using the system at a given moment), while concurrent licenses are a shared pool that many users can access as long as the total number of live sessions does not exceed the limit. Named licenses are straightforward but can be wasteful if many users are light users; concurrent licenses are efficient for large user bases but must be managed to avoid hitting the concurrent cap.

Q: When does CPU-based licensing make sense?
A: CPU-based licensing makes sense primarily in scenarios where you have a very large or unpredictable number of users and need essentially unlimited access. Under a CPU license, you pay based on the server’s processing power (for example, per CPU core), and in return, any number of users can use the system. This model was more common in the past for enterprise-wide deployments or when BusinessObjects was used in a public-facing way. It can simplify licensing (no need to count users or sessions) and handle massive scale. However, today it’s considered a legacy approach because it can become extremely expensive if your hardware is powerful but usage is moderate. With modern, scalable infrastructure, many companies find user-based models to be more cost-effective. In short, CPU licensing may make sense if user counting is impractical and usage is truly enterprise-wide – but you must ensure your hardware sizing is efficient; otherwise, you will pay for a lot of unused capacity.

Q: Can we mix BO license models in one contract or environment?
A: Mixing license models within one BusinessObjects deployment is generally not allowed or not practical. SAP typically requires you to select a primary licensing metric for a given environment to ensure compliance clarity. For instance, you wouldn’t simultaneously apply both concurrent session licenses and CPU licenses on the same server environment – it would be unclear which takes precedence, and SAP’s audit tools can’t easily reconcile a mix of metrics. That said, you can have different models for different environments or components. For example, a company might have an older CPU-based license for their production system, and a named-user license model for a separate test or development environment. Alternatively, you may have users licensed by name and a pool licensed by concurrent sessions, if they are segregated by system or contract. It’s essential to work this out with SAP: if you are transitioning models, negotiate how the new model will replace the old one. Mixing in the wrong way can lead to paying more than necessary (license stacking) or compliance issues. Aim to simplify your licensing model per environment for clarity and cost-effectiveness.

Q: How do hybrid deployments (on-prem + cloud) affect BO licensing?
A: Hybrid deployments can complicate licensing, so they need to be handled carefully. If you maintain your on-premise BusinessObjects system while also deploying BusinessObjects on a private cloud or using SAP Analytics Cloud, you might be dealing with separate license agreements simultaneously. On-prem licenses generally don’t “carry over” to SAP’s cloud services – for example, your perpetual named-user licenses for BO won’t simply apply to the cloud edition; the cloud edition will have its own subscription licenses. This can lead to overlapping costs if not managed: you could be paying maintenance for on-prem licenses at the same time as subscriptions for the cloud. To handle this, negotiate a migration plan. SAP sometimes offers incentive programs or credits for customers moving to the cloud (like allowing a portion of on-prem investment to offset cloud costs, or providing temporary dual-use rights during migration). Make sure to right-size each side: as you ramp up cloud usage, consider reducing on-premises licenses accordingly. Also, verify technical licensing requirements – e.g., if you host your own BO on AWS or Azure using your perpetual licenses, ensure your CPU/core counts are in line with the contract. In summary, a hybrid approach requires vigilance against duplicated licensing and contractual flexibility to adjust spending from one platform to another as your strategy evolves.

Q: What’s the fastest way to reduce BO licensing costs?
A: The quickest win to reduce BusinessObjects costs is to target shelfware and oversized licenses. Start by identifying any immediately unused licenses – for example, users who haven’t logged in for months or excess concurrent capacity. Removing those from your maintenance renewal (or reallocating them to needed areas) stops the bleeding of paying for nothing. Another fast-impact move is checking your license model fit: if you spot a mismatch (such as hundreds of named users who barely use the system), you can negotiate a conversion to concurrent sessions for those users, which often reduces the number of licenses needed. Additionally, review your support fees – sometimes simply asking for a discount or aligning your contract end dates with corporate procurement cycles can yield quick savings. In emergencies, companies have even opted to temporarily remove maintenance on non-critical licenses to save budget (with the plan to reinstate later if needed). Longer term, consider if a cloud subscription (with a lower footprint) could replace some on-prem costs. However, as an immediate step, nothing beats a thorough internal audit of usage to identify where you’re spending ineffectively. That data drives swift conversations with SAP to reduce license counts or switch models, resulting in tangible cost reduction on the next invoice.

Read about our SAP Advisory Services.

Do you want to know more about our SAP Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit