SAP Data & Analytics Licensing Strategic Playbook for CIO
Introduction
Modernizing SAP data and analytics platforms is a priority for CIOs looking to drive insights while managing costs.
SAP offers a portfolio of analytics solutions – from the high-performance HANA database to data warehousing with BW/4HANA and cloud analytics with SAP Analytics Cloud (SAC). Each comes with a distinct licensing model that can significantly impact total cost of ownership (TCO).
This playbook provides a strategic overview of these products’ licensing, highlights common pitfalls, and offers guidance for migration from legacy tools.
CIOs can use this playbook to make informed, cost-effective decisions on SAP analytics licensing and plan smooth transitions from older Business Intelligence (BI) platforms to modern solutions.
SAP’s Data & Analytics Products and Licensing Models
SAP HANA (In-Memory Database Platform)
Role in Analytics: SAP HANA is an in-memory, columnar RDBMS that underpins SAP’s analytics and ERP solutions. It powers real-time reporting and analytics for SAP applications, such as S/4HANA and SAP BW/4HANA, and can also serve as a standalone database for custom or third-party applications.
Licensing Models: HANA’s licensing is divided into two main categories: Runtime and Full Use.
- HANA Runtime License: This cost-effective option is restricted to use only in support of SAP applications. If HANA is deployed solely as the embedded database for SAP software (e.g., running SAP BW/4HANA or S/4HANA), a runtime license is required. The pricing for a runtime HANA license is typically calculated as a percentage of the SAP application’s value, rather than based on hardware size. For example, SAP uses a metric called HSAV (HANA Software Application Value) – essentially the total net price of SAP applications running on HANA – and charges a percentage (commonly around 15%) of that value for HANA runtime rights. This means the database cost scales with the investment in SAP software. The runtime license is lower-cost, but limits how HANA can be used. Customers may not directly access HANA outside of the SAP application’s user interface and APIs. Building custom applications on HANA or connecting third-party reporting tools directly to the HANA database requires a different license. In short, the runtime edition is strictly for SAP workloads. It comes with several usage restrictions (for instance, extracting data directly from HANA tables or using certain admin tools can violate the license if done outside the SAP app context). CIOs who favor this model should ensure that HANA serves only SAP’s packaged applications, with no standalone development.
- HANA Full-Use License: This model grants unrestricted access to the database. A full-use (sometimes called “Enterprise Edition”) HANA license allows running any application on HANA – including custom-built solutions or third-party software – and permits direct data access and integration outside of SAP’s application layer. With this flexibility comes a different cost model: full-use HANA licensing is typically capacity-based, most often tied to the amount of memory (RAM) allocated to HANA. SAP usually sells full-use HANA in blocks of memory (for instance, per 64 GB increments), or measures usage in gigabytes. The cost is significant – HANA full-use licenses are known to be relatively expensive and often come with limited discounts. This price premium reflects the expanded rights to exploit HANA’s capabilities for any purpose. From a budgeting perspective, full-use licensing means HANA costs scale with the size of the database. This can be a double-edged sword: it provides flexibility to consolidate workloads on HANA, but if the system’s memory footprint grows, licensing costs grow accordingly. SAP typically monitors HANA memory utilization over a 12-month period for licensing compliance. Peak or average usage beyond the purchased amounts may trigger true-up costs. Full-use HANA licenses come in editions (e.g., Standard, Enterprise), bundling different feature sets, but all are fundamentally usage-unrestricted. CIOs should choose a full-use license only if they need HANA’s platform capabilities beyond SAP applications, such as developing custom data marts on HANA or using HANA as a multi-application database. Otherwise, the runtime option is far more economical.
Key Considerations for HANA Licensing:
Selecting between runtime and full use is a critical decision. The runtime license is ideal when HANA’s role is limited to powering SAP ERP, BW, or other SAP-delivered systems – in these cases, it dramatically lowers database costs. However, the moment an organization anticipates any non-SAP data or external applications on HANA, a full-use license is required to stay compliant. CIOs must weigh the long-term data strategy: is HANA intended to be an enterprise-wide data hub, or just an SAP-specific engine?
It’s advisable to start with runtime licenses wherever possible, to minimize costs, and upgrade to full use only when needed. Additionally, careful sizing of HANA is crucial under either model. For runtime HANA, sizing affects the performance of SAP applications, but not the cost directly, since cost is a percentage of the app value.
For full-use HANA, sizing directly affects cost, so over-provisioning memory can lead to overpaying. Regularly monitor HANA memory consumption and growth trends. Implement data tiering, archiving of cold data, and housekeeping to keep the in-memory footprint lean. This helps avoid unexpected spikes that could force a larger license.
In summary, align the HANA license type with your usage scope, and continually optimize HANA data volume to control expenses.
SAP BW/4HANA (Data Warehouse)
Role in Analytics: SAP BW/4HANA is SAP’s next-generation enterprise data warehouse, designed to run exclusively on the HANA database. It is the successor to the traditional SAP Business Warehouse (BW) software.
BW/4HANA organizes data from SAP and non-SAP sources, enabling complex analytics, historical reporting, and data modeling. It often works in tandem with front-end tools like SAC or BusinessObjects for reporting and visualization.
Licensing Model: With BW/4HANA, SAP introduced a new licensing approach compared to older BW versions. Notably, BW/4HANA requires SAP HANA as its underlying database, which is reflected in its name. Licensing BW/4HANA, therefore, involves two aspects: the BW/4HANA application license and the HANA database license. In many cases, BW/4HANA is sold with a bundled HANA runtime license, or customers can use an existing HANA license.
Key points include:
- Package/Capacity Licensing: Unlike legacy BW, which was often included with SAP ERP licenses, BW/4HANA is a separately licensed product. SAP typically licenses BW/4HANA based on the size of the data warehouse, measured by the memory footprint or data volume (often aligned to HANA memory). Many BW/4HANA deals use a capacity metric such as 64 GB blocks of HANA memory. In practice, this means an organization might purchase BW/4HANA in tiers (for example, up to 1 TB of HANA memory, etc. – larger sizes yielding better unit pricing). Under this model, the cost covers the BW/4HANA software and a HANA runtime license to support it. An alternative licensing approach sometimes used is named user licensing, where each BW/4HANA end-user needs a BW/4HANA user license (often a Professional Named User). SAP appears to offer customers a choice: license by users or by data volume. Many enterprises choose the volume-based model to allow broad usage of the data warehouse without per-user costs, effectively allowing unlimited users to access BW/4HANA as long as the data size stays within the licensed band. The key for CIOs is to evaluate which model better fits their usage. If only a small, controlled set of users will use BW, user-based licensing could be cheaper. However, if BW is a core enterprise data hub with many consumers, capacity-based licensing avoids the complexity of tracking individual users. Note that if licensing by capacity, it generally assumes a HANA runtime license for BW is included or separately obtained – you would not additionally pay a full-use HANA license unless you plan to extend HANA usage beyond BW/4HANA itself.
- Bundled HANA Runtime: In most scenarios, running BW/4HANA means using HANA in runtime mode dedicated to Business Warehouse (BW). The BW/4HANA license and the HANA runtime license are often bundled or at least closely related. If BW/4HANA is the only application on that HANA instance, a runtime license (restricted to BW usage) will cover it. However, suppose you intend to use the same HANA instance for custom data marts or other apps alongside BW/4HANA. In that case, you must consider a full-use HANA license, similar to the decision described earlier for HANA. For pure BW scenarios, stick to the included runtime to save cost. The BW/4HANA license model “based on size” implicitly uses HANA memory as the measure, so it aligns with a HANA runtime license of equivalent size. Essentially, BW/4HANA’s pricing by 64GB blocks can be seen as a way of pricing the combined BW application and required HANA database capacity together. This is a shift from older BW on traditional databases, where licensing was user-based and the database was separately licensed (often to a third-party, such as Oracle or SQL Server).
- Removal of Legacy Restrictions: SAP has removed certain add-on license requirements in BW/4HANA that existed in classic BW. One notable example is the “Open Hub” licensing. In SAP BW 7.x, if customers wanted to export data out of BW to external systems (for example, to feed a non-SAP data lake or BI tool), SAP required an additional Open Hub license. This was essentially a charge for extracting data to non-SAP targets. BW/4HANA eliminates that constraint – there is no separate Open Hub license; users are free to consume BW/4HANA data from any SAP or third-party analytics tool without extra fees. This change encourages the use of modern BI tools, such as SAC, directly on BW/4HANA’s data. For CIOs, this is good news as it reduces the hidden costs of integrating BW data with other platforms – a point to leverage in planning your BI architecture.
Key Considerations for BW/4HANA Licensing: Organizations planning to transition to BW/4HANA must budget for a new license purchase or conversion, as it is not a free technical upgrade from SAP Business Warehouse (BW). SAP BW 7.5, the last NetWeaver-based BW, remains supported until the end of 2027, with extended maintenance available until 2030.
As a result, many customers are at a crossroads: either migrate to BW/4HANA or consider alternative data warehouse strategies before the deadline. If you choose BW/4HANA, negotiate a licensing model that best suits your usage pattern, such as user-based or volume-based.
Be aware that if you previously didn’t pay separately for BW (because it was bundled with SAP Business Suite), you will need to allocate a budget for BW/4HANA licenses – potentially a significant amount if your data volumes are large. On the positive side, migrating to BW/4HANA can offer a return on investment (ROI) in the form of simplified data models and improved performance, leveraging HANA. This may enable the retirement of some custom data management solutions or reduce the need for third-party database licenses.
Ensure that any BW/4HANA license deal includes the necessary HANA runtime rights to avoid any surprise costs. Also, maintain clarity on whether your BW/4HANA environment will be exclusively used for SAP data warehousing or if it will coexist with new cloud-based analytics, such as SAP Datasphere.
SAP’s roadmap for data warehousing is evolving. You’ll want flexibility if your strategy changes. In summary, license BW/4HANA in a way that matches your scale (data size vs. number of users) and keep it within the SAP ecosystem to take advantage of cheaper runtime DB licensing.
Plan the timing of migration to avoid incurring expensive extended maintenance on the old BW, and leverage SAP’s incentive programs (discussed later) to offset the costs.
SAP Analytics Cloud (SAC)
Role in Analytics: SAC is SAP’s flagship cloud analytics platform, providing business intelligence (dashboarding, reporting), planning (budgeting & forecasting), and predictive analytics in a software-as-a-service model.
It is a key component of SAP’s strategy to move analytics to the cloud, complementing and eventually succeeding on-premise tools like SAP BusinessObjects.
For CIOs, SAC represents a shift from license-and-maintenance to subscription-based usage.
Licensing Model:
SAC is available only as a cloud subscription, but SAP offers flexible subscription options. The two primary licensing approaches are user-based subscriptions and capacity-based subscriptions:
- User-Based Licensing: This is the most straightforward model – you pay a subscription fee per named SAC user, typically on a yearly or monthly basis. There are different user types or tiers in SAC, each aligned to a specific functionality. For instance, a common package is “SAC for Business Intelligence,” which covers standard analytics features, and a higher-tier package, “SAC for Planning” (often referred to as Planning Professional), which includes planning and what-if modeling capabilities. Planning users are priced higher than pure business intelligence (BI) users. All SAC users are named; each individual requires a license, as it’s not a concurrent user model by default. Contracts often come in blocks of users and have terms that range from 1 to 5 years. This model allows costs to scale with the number of people actively using the analytics tool. It provides cost predictability for a given user base, but one must manage license counts as staff or usage grows. SAP has in the past offered concurrent session licenses for SAC, allowing users to share a pool of licenses for up to a certain number of simultaneous logins. Still, these were largely phased out, and new SAC customers primarily choose named user subscriptions. In a user-based model, it’s essential to assign the appropriate license type to each user (e.g., only give the Planning license to those who require planning features, while others can use lower-cost BI licenses). This optimizes spending.
- Capacity-Based Licensing: For large-scale deployments or those with highly variable usage patterns, SAP also offers a capacity-based subscription for SAP Access Control (SAC). In this model, pricing is determined by the amount of resources consumed rather than a fixed user count. Capacity metrics could include things like data storage size, computing resources, or even the number of reports or “stories” run – SAP’s specific capacity metric for SAC is often tied to data volume and system size. Essentially, an enterprise can license a specific capacity bucket, such as enough capacity to support X GB of data or Y hours of analytics processing per month. Then, any number of users can be on the system as long as usage stays within that capacity. This model is suitable for organizations with a heavy workload in analytics. Still, the user base is broad (e.g., occasional users across the company) – it can sometimes yield cost savings by not requiring a license for every possible user. It also provides flexibility if the number of users is very fluid. However, capacity licensing requires careful monitoring of usage to avoid overages. SAP typically will work with customers on a custom contract for capacity-based SAC licensing (it’s not usually a public price list item), and it may be transacted via SAP’s Cloud Platform Enterprise Agreement (CPEA) where cloud credits are consumed based on SAC resource usage. CIOs considering this model should evaluate their anticipated data scale and concurrency. If you have thousands of users who only infrequently access dashboards, paying per user might be inefficient – a capacity model could be more cost-effective. On the other hand, if usage is high and sustained by many users, capacity pricing could exceed a named-user model. The break-even point should be analyzed (SAP and partners can help simulate costs under each model).
Regardless of the model, SAC operates on a term-based subscription contract. This means you pay annually or quarterly, and maintaining access requires renewal. SAC subscriptions typically include support and updates, as it’s a SaaS solution.
There is no perpetual license. From a planning perspective, switching from on-premises BI to SAC shifts costs from capital expenditure (CAPEX)- such as licenses and hardware – to operational expenditure (OPEX)- including recurring subscriptions.
It also introduces the need for active license management – for example, revoking unused user licenses promptly or rightsizing capacity commitments, because oversizing a cloud subscription results in wasted budget for that year.
Key Considerations for SAC Licensing:
When adopting SAC, CIOs should map out how different roles in the organization will use the tool. Power users who create dashboards or perform planning will need the higher-tier licenses.
In contrast, casual viewers might only need a BI license (or could potentially be served by sharing static reports, although SAC’s strength lies in interactive analytics for licensed users). Consider starting with a pilot or a small number of licenses and growing as adoption increases, to avoid buying a large number up front that aren’t immediately utilized.
SAC allows adding more users mid-term (usually at a prorated cost), but reducing users typically can only happen at renewal time. So, it’s better to slightly under-provision and then expand than over-provision and waste budget. For capacity-based licensing, ensure you have transparency into usage metrics.
SAP provides administrative dashboards for system usage; use them to check if you’re within your purchased capacity. Also, note that planning functionality in SAC may have capacity-related aspects, such as the number of planning models or data storage for planning scenarios.
Align the SAC subscription term with your broader cloud strategy. Many companies bundle SAC as part of RISE with SAP or other enterprise agreements, which can offer discounts or credits. Finally, SAC is part of the SAP Business Technology Platform (BTP) portfolio. If your company has BTP credits, you can leverage them to consume SAC as a service.
Always negotiate for flexibility – for instance, the ability to switch some users to capacity metric or vice versa if your usage pattern changes. SAP’s cloud licensing is evolving, so stay up-to-date on new offerings. For example, SAP occasionally introduces new bundles or promotions, such as including certain SAC features with S/4HANA Cloud or offering discounts for existing BusinessObjects customers.
Common Licensing Pitfalls to Avoid
Managing SAP analytics licensing can be a complex process. Several pitfalls routinely trap customers, leading to compliance issues or unplanned cost overruns.
CIOs should be cognizant of these issues when evaluating and managing licenses:
- Exceeding Licensed HANA Memory (Sizing Pitfalls): Under a full-use HANA license model, it’s easy to run into trouble if the system grows beyond the initially licensed memory. SAP’s audits will check the peak or average memory utilization of HANA. If your usage exceeds what you purchased, you may be liable for significant back payments or may be required to purchase additional blocks (often at a premium). The pitfall here is over-provisioning hardware “just in case” or allowing data bloat. For example, a team might store years of detailed data online in HANA, which can cause memory usage to exceed the licensed amount. The solution is to right-size and continuously govern the HANA environment: archive cold data to cheaper storage, delete unused data (such as logs and traces), and consider using HANA’s native data tiering (NSE or extension nodes) if available, to keep hot memory usage low. Another sizing issue arises with the runtime HANA license. While it doesn’t limit memory explicitly (since it’s based on application value), customers sometimes underestimate the memory needed for their SAP system, causing performance issues that tempt them to add data or apps beyond the runtime’s allowed scope. Avoid the temptation to repurpose “excess” HANA memory for unlicensed scenarios. Always acquire additional licensing before expanding usage. In summary, treat HANA sizing not just as a technical exercise but as a licensing exercise: forecast data growth and factor that into license planning to prevent costly true-ups.
- Using HANA for Non-SAP or Custom Applications (License Breach): A common (and dangerous) pitfall is using a HANA runtime license system for tasks beyond its intended scope. For instance, a company might have a HANA runtime license for BW/4HANA. Still, a developer can connect a third-party business intelligence (BI) tool, such as Power BI or Tableau, directly to HANA to run queries or export HANA data into a custom application. Such usage is not permitted under the runtime agreement. It constitutes what SAP terms’ indirect use’ or ‘misuse’ of the database license. SAP has been increasingly vigilant about this – audit programs have specifically targeted HANA runtime customers to ensure no unauthorized activity. The cost impact can be severe: SAP may demand an upgrade to a full-use license (retroactively covering the period of misuse), which can result in a hefty license purchase plus back fees for maintenance. This scenario typically arises not out of malice. Still, due to ignorance in larger organizations, one IT team might not realize the licensing constraints and connect external tools to HANA, even though it’s technically feasible. To avoid this, CIOs should educate their teams on HANA license restrictions and implement safeguards. If using runtime, enforce that all data access goes through the SAP application layer (e.g., use SAC or BO on top of BW’s OLAP interface, rather than directly hitting HANA calculation views without permission). If there is a genuine business need to use HANA as a general-purpose database, proactively discuss license options with SAP. Sometimes, an add-on license for limited use or a partial upgrade can be negotiated instead of a full upgrade to the enterprise edition, if caught early. The guiding principle: keep HANA usage in line with your license type. If it’s runtime, no custom apps or direct SQL access outside SAP’s delivered tools.
- Ignoring Indirect Access and Named User Licensing in Analytics: While our focus is on data/analytics products, remember that SAP’s licensing also involves named users for any access to SAP software. A pitfall is allowing analytics tools (such as SAC or third-party BI) to pull data from SAP systems and display it to users who may not have the proper SAP user licenses. In the context of BW/4HANA or SAP Analytics Cloud (SAC), if a SAC dashboard displays data sourced from SAP S/4HANA for a broad audience, do those viewers require SAP named user licenses? SAP’s Digital Access model covers some of these cases (counting document events rather than users). The main point for CIOs is to ensure that when legacy systems and new analytics intersect, you aren’t unintentionally violating user licensing. For BusinessObjects environments, SAP historically required that each user viewing reports had a corresponding SAP license if the data ultimately came from SAP systems (“named user” linkage). SAP has introduced a Digital Access adoption program to mitigate classic indirect access fees, but one must carefully review how analytics content is consumed. Pitfalls include: users extracting data from BW and then sharing it widely outside the SAP environment without proper licensing, or using third-party front-ends on top of SAP data without considering SAP’s indirect use policies. The mitigation is to audit and map out data flows, knowing who or what is accessing your SAP data warehouse or ERP data. If non-SAP systems are consuming data, consult SAP’s rules on indirect usage. You may need a licensing construct like SAP’s Digital Documents licensing or ensure that those users are covered under an enterprise license. This area can be legally complex, but ignoring it can result in significant compliance penalties. A best practice is to utilize SAP’s analytics front-ends (SAC, etc.,) which are already licensed for the users accessing them, thereby covering the SAP data access implicitly, rather than exposing data via unlicensed channels.
- Overlapping and Redundant Licensing During Transitions: As organizations transition from old analytics tools to new ones, a common pitfall is double-paying for similar functionality. For example, a company moving from BusinessObjects to SAC might hold licenses for both for a period. If not managed, this can blow the budget and erode the business case for the new system. It’s easy to underestimate the time a migration takes, which can lead to extended parallel run costs. Additionally, some may assume they can drop the old maintenance immediately after buying the new one. However, contractually, that may not be possible if the old system is still in use. CIOs should be wary of long transition phases where two sets of licenses run concurrently without a plan to sunset one. We discuss mitigation strategies in the next sections, including leveraging conversion programs. However, the key pitfall is the lack of a plan for decommissioning. Always tie the new deployment to a timeline for reducing the old licenses and communicate this internally so that stakeholders are aware that legacy systems will retire on schedule. Otherwise, you may find the organization comfortable with redundant systems (“just in case”) and end up maintaining both indefinitely at great cost.
By anticipating these pitfalls – HANA sizing overages, misuse of runtime licenses, indirect usage violations, and paying for redundant tools – CIOs can steer clear of compliance crises and budget overruns.
Diligent license compliance audits (both internal and not just SAP’s audits) and an open dialogue with SAP can turn many of these issues into non-issues. Essentially, know your license boundaries and actively manage usage against them.
Transition Strategies for Legacy BI to Modern SAP Analytics
Many enterprises have long-standing investments in legacy SAP Business Intelligence (BI) tools, such as the SAP BusinessObjects suite or older BW systems. Transitioning to SAP’s modern analytics offerings is not just a technical migration, but also a process of licensing and cost management.
Below, we provide strategic guidance for two common transition scenarios: from SAP BusinessObjects to SAP Analytics Cloud, and from SAP BW (NetWeaver BW) to either SAP BW/4HANA or SAP Cloud Analytics.
The goal is to achieve modernization with minimal disruption and cost surprise.
From SAP BusinessObjects (BOBJ) to SAP Analytics Cloud (SAC)
Current State:
The SAP BusinessObjects BI platform (BOBJ) has been a staple for on-premise reporting and analytics, featuring tools such as Web Intelligence, Crystal Reports, the Universe semantic layer, and Dashboards (Xcelsius). Many global CIOs find themselves managing large BOBJ deployments with thousands of reports and users.
However, SAP’s innovation focus has shifted to SAC for analytics, and cloud adoption trends are driving interest in moving away from on-premises business intelligence (BI) infrastructure. SAP BusinessObjects version 4.3 (the latest as of this writing) is committed to maintenance support until at least 2027, which effectively sets a horizon for planning a transition.
After that, customers will likely need to move to either SAC or SAP’s private cloud offering for BusinessObjects, as SAP is unlikely to produce a BOBJ 5.0 with long-term support. Thus, CIOs have a multi-year window to execute a migration to SAC or another modern business intelligence (BI) platform.
Challenges:
Migrating from BOBJ to SAC is not a simple ‘lift and shift’. There is no automated conversion tool that turns a WebI report into an SAC story or a Crystal report into a SAC analytic application. Content typically must be rebuilt or redesigned in SAC.
Additionally, SAC and BOBJ are different paradigms: SAC is purely web-based and geared towards interactive dashboards, whereas BusinessObjects also caters to formatted reporting and offline analysis. Some legacy use cases, such as heavy pixel-perfect reporting or complex batch printing, may not yet be fully met by SAC’s capabilities.
This functional gap often necessitates a period of co-existence, where BusinessObjects remains in use for certain needs. At the same time, SAC is introduced for new projects and gradually takes over suitable use cases.
Strategic Approach:
A successful transition involves a phased, hybrid strategy:
- Assess and Rationalize Content: Start by auditing your BusinessObjects environment. Identify which reports and universes are heavily used and truly needed. Many organizations find that a significant portion of their reports is redundant or rarely used. Retiring or consolidating these before migration will reduce effort and the need for SAC licenses. This process, often referred to as “right-sizing” the BI content, is crucial. Tools or services can help analyze usage logs to pinpoint candidates for retirement.
- Phase 1 – Hybrid Deployment (“Extend Analytics”): SAP recommends an “Extend” approach before a full “Migrate” approach. This means you introduce SAC alongside BusinessObjects and integrate them. SAC can connect live to BusinessObjects universes and WebI documents via a “Live Universe Connector.” In practice, this allows SAC to act as a new front end for some of your existing BusinessObjects data models, leveraging your BOBJ investment while using SAC for visualization. For example, you can take a well-built Universe from BOBJ (which encapsulates complex SQL logic) and connect SAC to it to create modern dashboards, without having to rebuild the data model from scratch. This hybrid approach provides immediate value – users see new SAC dashboards that pull from trusted data sources. During this phase, continue to use BusinessObjects for reports that SAC cannot yet replace, such as complex operational reports or statements. Encourage new analytics requirements to be built in SAC rather than WebI, to gradually shift the innovation to SAC.
- Phase 2 – Migrate Key Use Cases: Focus on fully migrating specific use cases to SAC. Good candidates are dashboards built in tools like Xcelsius (SAP Dashboards) or Analysis for Office that can be reimagined in SAC with its richer visualization and augmented analytics features. Notably, older tools like Xcelsius are Flash-based and went out of support in 2020, so many customers already needed an alternative – SAC is a natural fit. Rebuild those in SAC to deliver a better UX and eliminate legacy technology dependencies. Another area is self-service analysis, where users use WebI to do ad-hoc data exploration. SAC’s user-friendly interface can often provide a superior experience, with features like natural language queries and machine learning insights. Conduct pilots with power users to fine-tune SAC stories that can replace a set of WebI reports.
- Phase 3 – Gradual Retirement and Cutover: Over 1-3 years (depending on complexity), incrementally migrate the remaining critical reports to SAC or other solutions as needed. Some content might not be moved to SAC – for example, high-volume batch printing reports may be better replaced by a different tool or may remain in BusinessObjects if you choose to keep a small footprint. The end goal, however, is to significantly reduce or entirely decommission the BusinessObjects environment, thereby saving on its maintenance and infrastructure costs. Once SAC is handling the majority of analytics, you can choose to retire BusinessObjects. SAP offers a Private Cloud Edition (PCE) for BusinessObjects as a transitional option – essentially, SAP hosts your BOBJ system in their cloud under a subscription. This is worth considering if you cannot retire BOBJ entirely by 2027. Moving it to PCE shifts it to OPEX and may ease some administrative burden, but it still incurs an extra cost. Ideally, full decommissioning yields the greatest savings.
Licensing Considerations During Transition:
During the hybrid phase, you will have an overlap of SAC subscriptions and BOBJ licenses. To mitigate the cost impact, leverage SAP’s Cloud Extension Policy for analytics. SAP has a program that allows customers to convert a portion of their existing on-premise license investment into cloud subscriptions. In essence, you can trade unused BusinessObjects licenses, shelfware, and even maintenance fees to offset SAC subscription costs.
For example, suppose you have a surplus of BusinessObjects named user licenses. In that case, SAP may let you terminate some of those (reducing maintenance cost) in exchange for committing to an SAC subscription of equivalent value. This requires negotiation with SAP, but many CIOs have found success in reallocating their budget. Instead of paying maintenance for a legacy tool, they use that money to fund new Software Asset Control (SAC) licenses.
The Cloud Extension Policy helps prevent double payment during the transition period. It’s also wise to time the purchase of SAC to coincide with your BusinessObjects maintenance renewal cycle. If, for example, your BOBJ maintenance renews each January, consider initiating SAC in January so you can potentially non-renew a portion of BOBJ at that time.
Keep track of user counts: as users move to SAC, you may reduce named user counts in BusinessObjects, especially if you had analytics-specific user licenses. However, be cautious to maintain license compliance on BOBJ while it’s in use – do not drop those licenses too early.
Cost Optimization:
Migrating to SAC can yield cost benefits in the long run: lower infrastructure costs (no servers to maintain for BI), and potentially lower license costs if you successfully retire redundant tools. SAC might also come bundled with other SAP cloud deals.
To optimize costs, ensure that you train and drive adoption of SAC among business users – maximize the value of what you’re paying for. Conversely, turn off BusinessObjects modules that are not in use (for example, if you have add-ons like Explorer or Mobile that are no longer used, consider dropping their maintenance).
Archiving the BOBJ content that has been migrated and shutting down those servers can save not only money but also operational risk. Lastly, watch out for change management costs – factor in user training on SAC and the effort required for report redevelopment. These are one-time investments that yield returns if planned well.
In summary, the transition from BusinessObjects to SAC should be treated as a strategic program, not just a technical upgrade. It touches licensing, budgeting, user skills, and even data governance (as you remodel some analytics).
But with a phased approach and use of SAP’s licensing conversion offerings, CIOs can navigate this shift with controlled costs and end up with a more agile, cloud-based analytics platform.
From SAP BW (NetWeaver BW) to BW/4HANA or SAC
Current State:
Many SAP customers have an existing SAP BW data warehouse, often BW 7.x, running on traditional databases or even on HANA in “BW on HANA” mode. These BW systems might have been in place for decades, accumulating vast amounts of enterprise data and critical ETL processes. Now, SAP BW 7.5 (the latest “old” version of BW) is nearing the end of its mainstream maintenance in 2027.
CIOs must decide on a go-forward data warehouse strategy: upgrade to SAP BW/4HANA (the new on-premise DW) or potentially shift to a cloud data warehousing approach.
The question often arises: could SAC (with its in-memory engine and data wrangling features) serve as a simpler replacement for some BW uses? There is also SAP’s Datasphere (SAP Data Warehouse Cloud) as a cloud data warehouse, but since this playbook focuses on BW/4HANA and SAC, we will stick to those options.
Option 1 – Migrate/Upgrade to SAP BW/4HANA:
This path is the direct evolution of your data warehouse. BW/4HANA is built specifically for HANA and streamlines many of the modeling objects. Moving from BW 7.x to BW/4 is a significant project – it’s not an in-place upgrade.
There are generally three approaches that SAP outlines: new greenfield implementation, in-place technical conversion (available only from BW 7.5 on HANA, with many prerequisites), or a shell conversion (migrating structures and then data). Regardless of the approach, it requires effort in system migration, testing, and possibly rewriting certain custom code, as BW/4 has simplifications and does not support all older BW objects.
From a licensing perspective, moving to BW/4HANA will mean purchasing BW/4HANA licenses as discussed earlier. SAP does not automatically grant BW/4HANA usage rights to BW license holders – you must sign a new licensing agreement.
However, SAP may offer license conversion programs or incentives. One example is if you already licensed BW on HANA (i.e., you have a HANA runtime license for BW 7.x and perhaps some licensing metric for BW itself), SAP sales reps often can structure a conversion deal where the value of your existing licenses is credited toward BW/4HANA.
It’s important to engage SAP early to understand the commercial offering. Sometimes, BW/4HANA adoption can be bundled as part of a broader S/4HANA and digital transformation deal, which might yield better discounts.
Key reasons to choose this path include the following: you have heavy investments in BW (business logic in ABAP routines, BEx queries, Extractors from SAP ERP, etc.) that you want to preserve.
BW/4 will protect those investments (many can be adapted rather than rebuilt entirely) and provide a modernized platform with continued support to 2040. It’s especially sensible if your organization relies on complex, scheduled batch data pipelines and a large library of existing reports that read from BW’s InfoProviders.
BW/4HANA can also coexist with SAC – in fact, SAC can act as the primary front-end for it, replacing the old BEx or even Analysis for Office in many cases. You can modernize the back-end (from BW to BW/4) and the front-end (using SAC for new reporting) in parallel.
One caution: do not assume BW/4HANA is “just a technical upgrade” – treat it as a reimplementation project. There will be opportunities to redesign data models, eliminate outdated data that is no longer needed, and improve performance.
Take those opportunities. A straight port of everything might be faster, but it would bring a lot of baggage into the new system. By cleaning up during migration, you can potentially opt for a smaller HANA footprint, which reduces license costs.
For example, if you aggressively archive and drop unused infocubes, the BW/4HANA system might only need half the memory, which saves money. This ties into cost optimization: rationalize your BW before or during the move.
Option 2 – Move to SAC (and/or Other Cloud Solutions) Instead of Traditional BW:
Some organizations are considering whether they need an on-prem data warehouse at all going forward. SAC itself has in-memory data storage for imported data and can perform data transformations through data acquisition and modeling features.
Additionally, SAP now offers Datasphere (previously known as SAP Data Warehouse Cloud), which, when combined with SAC, provides cloud-based data warehousing capabilities. While SAC alone is not a full data warehouse (it’s more of an analytics tool that can hold data in memory for analysis), combining SAC with cloud data storage or virtualization can cover certain use cases that were historically handled in BW.
This approach essentially means retiring SAP BW and handling reporting through a mix of S/4HANA’s embedded analytics, SAC’s modeling, and other data platforms for non-SAP data. For instance, one strategy is to move historical data and external data feeds into a cloud data lake or SAP Data Sphere, and then use SAC to query those sources live or via imports.
Another strategy is to leverage S/4HANA (if you’ve migrated to S/4) for operational reporting via CDS views, and then use SAC on top of S/4 for real-time analytics, eliminating the need to stage data in BW.
The benefits of skipping BW/4HANA: avoiding the licensing and infrastructure cost of maintaining another big system. It can also simplify your landscape (one less application to upgrade and patch). License-wise, you would avoid purchasing BW/4HANA licenses and possibly reduce HANA license needs (if your BW was on a separate HANA, decommissioning it frees up that capacity).
However, be mindful that the data warehouse function doesn’t disappear – it shifts elsewhere. You might incur new costs, for example, if you adopt SAP Datasphere, which has its subscription fees (often based on storage and user counts).
Or suppose you plan to significantly expand S/4HANA’s data retention for analytics. In that case, you may need more S/4HANA memory (which indirectly increases S/4 licensing since S/4HANA is licensed partly by metrics like revenue or users that might not directly scale with data, but the technical demands might push you into higher infrastructure costs or even the need for S/4 Data Warehouse Foundation add-ons).
SAC can perform lightweight data modeling and joins, and now includes features such as data preparation and blending. Some customers with relatively simpler analytics (a few data sources, not huge volumes) might use SAC alone (with its in-memory engine for imported datasets) as a quasi data mart, thereby fully replacing BW.
This is realistic if your data volumes are low to moderate and primarily needed for dashboards and planning, rather than for complex historical trend analysis that requires massive data crunching. SAC’s performance and data handling have limits (for very large datasets, a BW or database is still needed).
Hybrid Approach:
It’s worth mentioning that the decision need not be binary. A hybrid strategy could be to split your workloads instead of migrating everything from BW to a single target. Perhaps core, structured, and repeatable reporting (especially on SAP financials and logistics data) goes to a lean BW/4HANA, ensuring strong governance and integration with SAP sources.
In contrast, more experimental or rapidly changing analytics, especially those involving non-SAP or big data, are performed in the cloud (Datasphere or other cloud data warehouses) with SAC as the unifying reporting layer across both.
This way, you can reduce the scope and cost of BW/4HANA compared to your old BW and leverage cloud scalability for new use cases. SAC can combine live data from BW with data from cloud sources in a single story, so a hybrid data warehouse (DW) environment can still feel seamless to end users.
Licensing Considerations and Cost:
If you move to BW/4HANA, plan to purchase both the license and the HANA runtime license. Be aware of the support timing – doing it before 2027 avoids extended maintenance fees on old BW. If you decide not to go to BW/4HANA, consider if you will still pay maintenance on BW 7.x until 2030 (which SAP allows at extra cost).
Running BW 7.x past 2027 means an additional maintenance uplift (likely an extra % on top of standard maintenance). This might be acceptable for a short while if you need a safe harbor while implementing alternatives, but it’s not a long-term solution. If you fully retire BW, you can terminate its maintenance, saving that annual cost entirely.
An important consideration is the data migration cost: moving from BW to another system (BW/4 or others) involves migrating a large amount of data. Factor in project costs and, if necessary, new licenses for integration tools used for extracting and loading data.
Also, consider the opportunity to clean house – many CIOs use the migration as a chance to remove old data, potentially reducing the target system size and license needs. For example, if you decide not to bring 10 years of log data to the new system because no one uses it, you might save a few terabytes of HANA memory, which is a substantial amount of money saved.
Finally, check if SAP offers any bundled incentives. Sometimes, if you commit to S/4HANA, BW/4HANA, and SAC together, SAP may offer more attractive pricing, as it secures your use of their platform from end to end. Work with your SAP account team to see if a holistic deal is possible. This could also involve trading in old licenses – for example, if you have a lot of unused BW named user licenses, you may be able to get credit towards BW/4HANA.
Recommendation:
Generally, if your company heavily relies on a data warehouse and has many SAP source systems, BW/4HANA is the safer strategic choice to ensure continuity and supportability. If your use of BW was minimal or primarily for basic reporting, you might leapfrog to cloud analytics entirely.
In either case, start planning well in advance of 2027, allocate budget for either the BW/4 project or alternative analytics projects, and leverage SAP’s migration tools and services (SAP provides utilities for BW to BW/4 conversions, and for BW to Datasphere via “BW Bridge” as well).
The transition from BW is not trivial, but done smartly, it’s an opportunity to modernize your data foundation and potentially optimize cost structure (for instance, possibly reducing total software footprint or moving to more flexible cloud subscriptions).
Cost Optimization Tactics for Analytics License Transitions
Upgrading your SAP analytics landscape is the perfect time to optimize costs. Beyond the product-specific guidance above, here are strategic tactics CIOs can use to manage and reduce licensing costs during these transitions:
- Leverage License Conversion and Swap Programs: Take advantage of SAP’s programs, like Cloud Extension Policy or license swap offerings. These allow you to convert existing on-prem license values into cloud subscriptions. For example, convert unused BusinessObjects licenses or maintenance into SAC subscriptions, or swap legacy BW licenses for BW/4HANA licenses at a discount. By doing so, you avoid paying full price for the new licenses and avoid shelving sunk costs. Always ask SAP if a conversion option exists – SAP has been amenable to this as it encourages cloud adoption.
- Negotiate Bundled Deals: When transitioning to multiple new products (such as S/4HANA, BW/4HANA, and SAC all at once as part of a digital transformation), consider negotiating a bundled license deal. SAP can be flexible on pricing if it sees a strategic long-term commitment. Bundles like RISE with SAP sometimes include elements like SAC or could be extended to cover BW/4HANA at attractive rates. Ensure the bundle meets your needs (don’t pay for things you won’t use); however, economies of scale can drive down the per-unit cost. Also, aligning all major purchases in one negotiation can give you more leverage to obtain volume discounts.
- Rightsize Environments Before Licensing: As emphasized, clean up data and users before you lock in license metrics. Archive data from HANA to shrink memory needs. Delete or consolidate unused Business Workload (BW) objects and data. In BusinessObjects, eliminate inactive users and reduce concurrent user licenses if possible. The smaller and more efficient your environment, the fewer GB or users you need to license on the new systems. This rightsizing can also save on hardware and cloud costs. It may require an upfront effort (data archiving project, user cleanup campaign), but it has direct license cost benefits.
- Stagger Migrations to Avoid Peak Overlap: If possible, do not schedule all transitions simultaneously, which can maximize overlapping licenses. For instance, migrating BW first in one year, and then tackling BOBJ to SAC the next year, might allow you to use freed-up budget from the first project to fund the second. If you try to do everything at once, you’ll be carrying old and new costs concurrently. A phased approach can smooth the spending curve. During unavoidable overlap periods, keep them as short as possible – set aggressive but realistic timelines for decommissioning legacy systems once the new one is live, to prevent double payments.
- Optimize SAC License Allocation: For SAP Analytics Cloud specifically, monitor usage and adjust license types. Not every user needs a full creator license – some may just be viewers of dashboards. If those can be shared via PDF or on a big screen without login, you might not need to license all of them. SAP’s licensing for SAC is role-based; ensure each user has the appropriate role and thus consumes the correct license (BI vs Planning). If you find that your SAC utilization is under capacity, you may consider consolidating to fewer licenses at renewal. Conversely, if one department isn’t using SAC, consider reallocating those licenses to another rather than buying new ones. Stay flexible: you might start with a named user model and later talk to SAP about switching to a capacity model if your user count balloons – or vice versa, if you started with capacity but realized a set number of power users make up 90% of usage, then named user could be cheaper. Renegotiate at renewal time based on actual usage patterns; SAP would rather adjust the model than lose you as a customer.
- Retire Duplicative Tools: A primary cost-saving comes from eliminating redundant software. If you adopt SAC, plan to fully retire at least one legacy BI tool (not just BusinessObjects); possibly other tools like Tableau or Qlik, depending on your landscape, if you are consolidating on SAC. Reducing the total number of BI platforms saves licensing and support costs and simplifies governance. Similarly, if you move to BW/4HANA, consider if you can retire some third-party ETL or database systems that BW’s new capabilities might replace. Every system retired is maintenance fees saved and staff time reallocated. The key is to resist keeping the old system “just in case.” Have a clear decommission plan and execute it.
- Continuous License Audit & Compliance Management: Make software asset management a continuous discipline. Use SAP’s tools (License Administration Workbench, etc.) and third-party tools to track usage of SAP licenses. Proactively identify if you are under-utilizing something (then perhaps reduce it) or nearing a usage cap (to negotiate expansion in advance rather than pay audit penalties). Also, monitor indirect usage – if new integrations are built (e.g., connecting a new CRM system to BW), flag them to the licensing teams to assess whether they are compliant or require additional licensing. It’s cheaper to address licensing needs upfront than to suffer an audit finding.
- Training and Change Management: While not a direct licensing tactic, investing in training helps ensure the new systems are used effectively. If users are well-trained on SAC or BW/4HANA, they will fully utilize the new features, and you get better value for your license spend. Poor adoption is a wasted investment. Also, educated users are less likely to unintentionally violate license rules (for example, a power user who knows the limitations of a runtime license won’t connect unauthorized tools to HANA). Allocate a budget for education to protect and maximize your software investment.
- Benchmark and Consider Third-Party Maintenance if Applicable: For some legacy systems that you must keep but don’t want to invest in (say you’re keeping an old BW for historical data but not actively developing it), you might consider third-party maintenance providers (like Rimini Street or others) after SAP’s support ends, to save on support costs. This is a niche strategy and comes with risks (losing SAP support), but in certain cases, it can save costs if the system is static. However, for most, the goal is to migrate off the legacy system rather than pay someone to maintain it longer.
Applying these tactics can significantly reduce the financial burden of transitioning to new SAP analytics platforms. A combination of smart negotiating, diligent housekeeping, and strategic timing will enable your organization to modernize its analytics toolkit within a reasonable budget, and often with improved ROI over time thanks to more efficient licensing and cloud scalability.
Actionable Recommendations for CIOs
In light of the above analysis, CIOs should take the following concrete steps to ensure cost-effective and future-proof decisions around SAP data and analytics licensing and migration:
- 1. Map Your Analytics Landscape and License Position: Inventory all SAP analytics systems (e.g., BW, HANA, BOBJ), their versions, and their current licensing status. Document any non-SAP integrations. Use this as a baseline to identify necessary license changes (e.g., runtime vs full HANA) and potential compliance risks.
- 2. Choose HANA License Type Strategically: If HANA is only used for SAP applications, stick to the cheaper runtime license and enforce policies to prevent non-SAP usage. Only invest in a full-use HANA license if your strategy requires HANA as a broader data platform. Regularly monitor HANA memory usage to ensure you stay within purchased capacity, and clean up data to avoid unneeded expansion.
- 3. Evaluate BW/4HANA Migration vs. Alternative Solutions: With SAP BW 7.x support nearing its end, decide whether to migrate to SAP BW/4HANA or switch to a cloud-based analytics stack. If BW/4HANA is needed, engage SAP early in a conversion deal and plan the project to be completed by 2027. If not, create a roadmap for replacing BW capabilities, such as data integration and historical reporting, with SAC and other data platforms. In either case, archive and prune data to minimize the footprint (and cost) of the new solution.
- 4. Plan BusinessObjects to SAC Transition in Phases: Develop a phased migration plan from SAP BusinessObjects to SAP Analytics Cloud. Begin by integrating SAC with your existing BI (in hybrid mode) to achieve quick wins and familiarize users. Gradually recreate high-value reports in SAC and encourage new projects to use SAC. Target a sunset date for BusinessObjects and communicate it. Leverage SAP’s Cloud Extension Policy to convert BusinessObjects maintenance budget into SAC subscription value, mitigating dual run costs.
- 5. Optimize SAC Licensing and Adoption: For SAP Analytics Cloud, select the right licensing model (user-based vs. capacity-based) based on your user count and usage patterns. Start with a manageable number of users and scale up. Continuously review license assignments – ensure expensive planning licenses are only held by those who need them. Drive user adoption through training so that the SAC investment delivers full value and justifies consolidating other BI tools into SAC, saving costs.
- 6. Use SAP’s Incentive Programs and Negotiate: Take advantage of SAP programs for digital transformation – whether it’s bundled discounts, free trial periods, or flexible licensing during migration. When negotiating new licenses (BW/4, SAC, etc.), bring your SAP account team a holistic plan. Consolidating purchases can yield better pricing. Don’t be afraid to seek custom terms (e.g., an extra development SAC tenant at no cost or a temporary dual-use license for BW and BW/4 during migration) – SAP often accommodates such requests to ensure your successful adoption.
- 7. Tighten Governance to Avoid Surprises: Establish governance for license compliance. Internally track and review how systems are used. Prevent unauthorized direct access to HANA, especially under runtime licenses, using technical controls. Ensure every third-party system interfacing with SAP data is licensed appropriately (consider SAP’s Digital Access document licensing if relevant). Proactively run SAP’s measurement tools and address any usage above entitlements before an official audit does.
- 8. Retire Legacy Systems to Harvest Savings: Once new platforms are in place, decommission legacy BI and BW systems on schedule. This allows you to eliminate their associated license maintenance, hardware, and support costs. Redirect those savings to fund innovation on SAC and HANA. Avoid keeping old systems’ just in case.” If necessary, export data to cheaper storage for compliance purposes, but shut down expensive software where possible.
- 9. Monitor SAP’s Roadmap and Adjust: SAP’s analytics and data warehousing roadmap is evolving (e.g., integration of SAC with Datasphere, new “one data suite” vision). Stay informed through SAP briefings or Gartner updates. If new licensing models or products emerge that could reduce your cost or improve capabilities (for instance, SAP might introduce more unified pricing for data & analytics cloud services), be ready to pivot. A flexible contract structure or shorter-term SAC agreements can give you room to adapt as the market changes.
- 10. Engage Stakeholders and Build the Business Case: Communicate with the CFO, finance, and business unit leaders about the licensing and migration strategy. Build a clear business case that quantifies the cost of the status quo (e.g., rising maintenance costs on BW/old hardware) versus the investment in new solutions, with anticipated benefits such as improved performance, agility, and eventual cost reductions. Gain support by highlighting not just IT savings but also the business value of modern analytics (better insights, real-time data, advanced planning). A well-understood strategy will ease approvals for the necessary license purchases and project funding, and set expectations that cost optimizations will be realized through the disciplined execution of this playbook.
By following these recommendations, CIOs can confidently steer their organizations through the complex licensing landscape of SAP’s analytics tools. The result will be an optimized license portfolio that supports modern data-driven decision-making without overspending, and a clear path away from legacy constraints toward a more agile, cloud-enabled analytics future.
