SAP Data Warehouse Cloud & SAP Analytics Cloud Licensing Guide 2026

SAP Data Warehouse Cloud: Origins, Evolution, and What It Is Today

SAP Data Warehouse Cloud (DWC) was launched as a cloud-native data warehousing product in 2019, positioned as SAP's answer to the growing cloud data warehouse market dominated at the time by Snowflake, Google BigQuery, and Amazon Redshift. Built on SAP HANA Cloud infrastructure and delivered through SAP BTP, DWC was designed to provide enterprises with a managed, cloud-native data integration and warehousing environment that offered native integration with SAP's transactional systems (S/4HANA, C/4HANA, Ariba, SuccessFactors) while also supporting non-SAP data sources.

The product has gone through two significant evolutions since its initial launch. The first was a substantial functional expansion in 2021 and 2022, adding data integration capabilities (pipeline management, data replication), a semantic layer (Business Layer for data modelling), a data marketplace for sharing and discovering data products, and expanded connectivity for third-party sources including Salesforce, Google Analytics, and AWS. The second evolution was the renaming and repositioning of DWC as SAP Datasphere in early 2023, which added a more formal data fabric architecture, expanded data governance capabilities, and positioned the product explicitly as the data management foundation for SAP's broader analytics portfolio.

For licensing purposes, it is essential to understand that SAP Data Warehouse Cloud and SAP Datasphere are the same commercial product at different points in its product lifecycle — DWC contracts are now effectively Datasphere contracts, and SAP has migrated the commercial entitlements of DWC customers to the Datasphere nomenclature without necessarily requiring a formal contract amendment. Organisations running DWC contracts should confirm with SAP what Datasphere capabilities they are entitled to under their existing agreements before committing to any additional Datasphere commercial terms at renewal.

The most important commercial characteristic of DWC/Datasphere from a buyer's perspective is its Compute Unit (CU) consumption model. Unlike per-user licensed products, DWC/Datasphere is metered on the computational resources consumed by data management workloads — data ingestion, transformation, replication, and query processing. This consumption model creates a fundamentally different commercial risk profile than per-user products: the cost scales with data volume and workload complexity rather than with headcount, which means it can grow rapidly and unpredictably as analytics adoption increases and data volumes expand.

DWC/Datasphere Capacity Units: The Complete Commercial Picture

Understanding how CUs are defined, measured, and metered is essential for any organisation managing DWC or Datasphere costs. SAP defines a Compute Unit as a standardised measure of computational resource consumption on the BTP HANA Cloud infrastructure. CUs encompass three dimensions of resource consumption: memory (the HANA in-memory capacity allocated to your Datasphere tenant), compute (the CPU resources consumed by processing workloads), and storage (the disk storage used for persistent data and technical metadata). SAP's CU billing engine aggregates these three dimensions into a single hourly CU consumption figure, which is then summed over the billing period to produce the monthly CU consumption total.

The minimum DWC/Datasphere commitment since 2024 is 1,532 CUs per month. Before 2024, the minimum was 4,300 CUs per month — a level that, as noted, priced out many potential buyers. The reduction to 1,532 CUs was a deliberate commercial decision by SAP to make Datasphere accessible to a broader range of buyers, particularly mid-market organisations and large enterprises that wanted to start with a targeted analytics use case rather than committing to an enterprise-scale deployment from the outset.

At the minimum commitment level of 1,532 CUs per month, an organisation is essentially provisioning a small but functional Datasphere environment: sufficient for a single data domain (for example, financial reporting from S/4HANA), a limited number of concurrent users through SAC, and a modest volume of data replication and transformation workloads. For most enterprise-scale implementations — integrating multiple SAP and non-SAP source systems, supporting dozens of concurrent analytics users, and managing significant data volumes — the minimum commitment is insufficient, and the actual production workload will typically require 5,000 to 15,000 CUs per month or more.

CU Pricing: What You Should Expect to Pay

SAP does not publish a universal CU list price, because pricing varies by region, by the specific compute tier (standard, production, premium), and by committed volume. Based on benchmarking from our client engagements, the following approximate CU price ranges provide a useful reference for 2025 to 2026:

• Standard Compute (development and testing workloads): Approximately $0.04 to $0.06 per CU-hour at list price. For an organisation consuming 3,000 standard CUs per month (approximately 4,320 CU-hours), the monthly cost at list is approximately $175 to $260, or $2,100 to $3,100 per year — significantly less than the production tier and often used for development and UAT environments.
• Production Compute (primary production workloads): The most common tier for enterprise deployments. List pricing runs approximately $0.06 to $0.10 per CU-hour. For a production environment consuming 8,000 CUs per month (approximately 11,520 CU-hours), the monthly cost at list ranges from $690 to $1,150, or $8,300 to $13,800 per year. Enterprise volume discounts of 25 to 40 percent are achievable in competitive situations.
• Premium Compute (memory-intensive or real-time workloads): The highest-performance tier, used for in-memory real-time analytics and large-scale HANA scenarios. List pricing exceeds $0.10 per CU-hour. Organisations running extensive real-time SAP reporting workloads through Datasphere may find a significant portion of their CU consumption falling in this tier.

The critical commercial insight is that most organisations underestimate which compute tier their workloads will fall into. Pre-sales modelling by SAP and implementation partners consistently defaults to standard compute assumptions for workload sizing. In production, many workloads — particularly those involving large data volumes, complex transformations, or real-time HANA access — run at higher compute tiers than the model assumed, resulting in higher-than-expected CU consumption from the first month of production operation.

SAP Analytics Cloud: Licensing Deep Dive

SAP Analytics Cloud is the designated BI, planning, and augmented analytics consumption layer for the SAP analytics portfolio. It works with Datasphere/DWC as the data management foundation, with SAP HANA Cloud directly (for live connection scenarios), with SAP BW/4HANA and legacy SAP BW (via BW Bridge), and with third-party data sources via file uploads, APIs, and OData connections. Understanding how SAC is licensed — and the specific traps in each user tier — is essential for any organisation managing SAC spend.

SAC User Tiers: What Each Covers

SAC is licensed on a named-user model with several tiers, each covering a distinct set of capabilities. The tiers as of 2026 are:

Business Intelligence (BI) Standard: This is the consumer tier — read-only access to published stories, dashboards, and data analysis views created by others. BI Standard users can interact with published content (apply filters, drill down, explore data within the published view) but cannot create or edit analytics content. List pricing is approximately $36 per user per month at enterprise volumes. This is the correct tier for the large population of business users who consume management reports, operational dashboards, and KPI monitors but do not need to build analytics content themselves.

Business Intelligence Professional: The creator tier — full access to build, edit, and publish SAC stories, dashboards, data explorations, and augmented analytics content. BI Professional users also have access to SAC's predictive analytics capabilities (smart predict, automated forecasting). List pricing runs approximately $55 to $75 per user per month. The most common licensing error we observe in SAC deployments is classifying users as BI Professional when their actual usage is BI Standard — a misclassification that can add thousands of euros of unnecessary annual cost per user.

Planning Standard: Provides access to planning models as a contributor — entering and modifying budget and forecast data, running allocation rules, and participating in collaborative planning workflows. Planning Standard users do not have access to model administration or advanced planning configuration. List pricing approximately $90 to $110 per user per month.

Planning Professional: Full planning capabilities including model creation and administration, advanced planning features, driver-based planning, allocation and distribution rules management, and the full set of planning APIs. Planning Professional users are typically the finance and planning team members who design, configure, and maintain the planning environment. List pricing approximately $110 to $130 per user per month. The misclassification risk here is the opposite of BI — organisations frequently classify users as Planning Standard when their actual activities require Planning Professional capabilities, leading to unexpected functionality limitations that require a tier upgrade at additional cost.

SAC and the SAP BW Legacy: Critical Transition Issues

A significant proportion of SAC deployments are transitioning from legacy SAP Business Warehouse (SAP BW) environments, either running on-premise or in the private cloud. SAP BW has been the de facto SAP reporting and analytics backbone for large enterprises for more than two decades, and the migration to SAC represents one of the largest analytics platform transitions in enterprise technology history. The commercial implications of this migration are substantial and frequently underestimated.

The primary commercial challenge of the BW-to-SAC migration is that SAP BW typically served as both the data management layer and the analytics consumption layer. In the SAC world, these two functions are separated: Datasphere (or BW/4HANA as a bridging product) serves as the data management layer, and SAC serves as the consumption layer. This architectural separation means that organisations migrating from BW to SAC must effectively licence two products — Datasphere and SAC — to replace what was previously a single SAP BW licence.

SAP offers the BW Bridge as a transition mechanism: a component of Datasphere that allows legacy BW objects (InfoProviders, queries, transformations) to run natively within the Datasphere environment, providing continuity of reporting while the migration to native Datasphere semantic models is completed. BW Bridge is licensed as part of the Datasphere CU consumption rather than as a separate product, but it does consume CUs — and the consumption rate for complex legacy BW workloads running through BW Bridge can be significantly higher than the consumption rate for equivalent native Datasphere workloads, because the legacy objects are less optimised for cloud-native execution.

DWC + SAC Combined Licensing: Commercial Structures and Traps

The majority of enterprise analytics deployments involve both DWC/Datasphere (for data management) and SAC (for BI and planning). SAP increasingly sells these two products together — either as a joint commercial proposal with separate line items, or bundled within a BTPEA credit pool. The commercial structure of how you purchase these two products together has significant implications for pricing, flexibility, and total cost of ownership.

Separate Product Contracts vs. BTPEA Bundling

When DWC/Datasphere and SAC are purchased on separate product contracts — each with its own line-item pricing, commercial terms, and renewal dates — the buyer has maximum visibility and flexibility. You can benchmark each product independently, negotiate each on its own commercial merits, and restructure either contract at renewal without necessarily touching the other. The downside is that two separate contracts mean two separate renewal negotiations and potentially two separate SAP account team relationships to manage.

When DWC/Datasphere and SAC are bundled within a BTPEA, the apparent advantage is simplicity: a single credit pool covers both products, a single account team manages the relationship, and SAP's commercial position is presented as "everything included" within the credit envelope. The commercial risk — as described in our CIO playbook — is that the unified credit pool obscures the individual pricing of each component, making it impossible to benchmark independently or to restructure the split between Datasphere CUs and SAC user licences without SAP's agreement (and typically without additional commercial concessions).

Our recommendation for most organisations is to insist on schedule-by-product pricing within any BTPEA that includes both DWC/Datasphere and SAC. This provides the administrative simplicity of a single commercial agreement while preserving the transparency needed for independent benchmarking and future renegotiation. SAP will initially resist this transparency, but it is achievable for organisations making material multi-year commitments.

Common Traps in Combined DWC + SAC Agreements

The following traps occur specifically in combined DWC/Datasphere + SAC commercial structures, and are distinct from the single-product issues described elsewhere in this guide.

Mismatched Contract Terms: When DWC/Datasphere and SAC are purchased at different points in time, their contract terms frequently do not align — DWC might be on a 3-year term expiring in December while SAC is on a 2-year term expiring in June. This misalignment creates a situation where every renewal involves only part of the analytics estate, reducing the buyer's leverage and making it impossible to negotiate the combined platform as a single commercial entity. Negotiate aligned contract terms for all analytics products at the first opportunity — even if it requires an interim adjustment to one contract's term length.

SAC User Count Growing Faster Than Modelled: SAC user adoption in production consistently exceeds the initial deployment projection. When the combined DWC + SAC agreement does not include provisions for incremental SAC user additions at the initially agreed discount rate, additional users are priced at list rate rather than the contracted rate — a common and expensive outcome. Negotiate a pre-agreed incremental pricing schedule for SAC user additions throughout the contract term.

Datasphere Overage Charged at List: If your Datasphere CU consumption exceeds the contracted monthly commitment, the standard SAP contract terms apply an overage charge at SAP's current list price rather than at the discounted rate that applies to your committed CUs. For organisations experiencing rapid analytics growth, this list-price overage can significantly inflate the total cost of the analytics platform. Negotiate a cap on overage pricing — specifically, that overage CUs consumed above the committed monthly allocation are billed at no more than the contracted per-CU rate.

Renewal Price Reset: When a combined DWC + SAC contract comes up for renewal, SAP's commercial team will typically propose to reset the commercial terms to current list prices as the starting point for the renewal negotiation. The discounts achieved in the original deal are presented as "expired." This is a negotiating tactic — you have legitimate grounds to argue that the renewal represents a continuation of a committed customer relationship, not a new deal, and that the discounts should carry forward as the baseline rather than as concessions. Engage independent advisory support for the renewal rather than accepting SAP's opening position.

Migration from DWC to Datasphere: Commercial Considerations

For organisations running existing DWC contracts, SAP's commercial team will at some point initiate a conversation about the transition to Datasphere. Understanding the commercial mechanics of this transition is important because SAP's presentation of the migration often conflates what is a product renaming with what is a commercial renegotiation.

In principle, existing DWC customers should be able to access Datasphere functionality under their existing contract terms: the product name has changed, but the commercial entitlements that were purchased should carry forward. In practice, SAP's approach to the DWC-to-Datasphere transition has been variable. Some customers have been migrated to Datasphere with minimal commercial disruption — the CU commitment, pricing, and term carry forward unchanged. Others have been presented with a "migration offer" that restructures the CU commitment, resets the pricing, or introduces new commercial terms that were not in the original DWC agreement.

Before accepting any "migration offer" from SAP, review your original DWC contract carefully. Confirm exactly what CU capacity you are entitled to, at what pricing, and for what term. If the migration offer reduces your entitled capacity, increases your pricing, or introduces commercial terms that are less favourable than the original DWC contract, treat this as a renegotiation — not as a migration — and negotiate accordingly.

SAC and Datasphere Audit Exposure: What SAP Looks For

SAP's audit function — the Global License Audit and Compliance (GLAC) team — includes analytics products within broader SAP licence audits, particularly where the audit scope includes a significant SAP BTP footprint. The primary audit vectors for DWC/Datasphere and SAC are the following.

SAC User Count Overuse

SAP audits SAC by extracting the complete named user list from the SAC tenant and comparing it against the contracted user count by tier. The most common SAC audit finding is user count overuse — specifically, users accessing SAC capabilities above their contracted tier. Examples include: BI Standard users who have been given edit access to stories (BI Professional capability); users who have been added to the tenant for testing or training purposes and were never removed after the test phase ended; and former employees whose SAC accounts were not deactivated when they left the organisation.

A well-structured user lifecycle management process is the most effective defence against SAC user audit findings. This means: quarterly review of the active user list against the contracted user count and tier; automated deactivation of accounts for users who have not logged in for 60 days; and a clear process for deactivating accounts when users leave the organisation or change roles. Most SAC audit findings we have seen arise from the absence of this basic lifecycle hygiene, not from deliberate over-deployment.

Datasphere CU Consumption Assessment

Unlike traditional licence audits that focus on a specific point-in-time licence position, Datasphere CU consumption is inherently continuous — every hour that workloads are running is a billable hour. SAP's audit of Datasphere typically involves requesting a detailed CU consumption report from the BTP cockpit (the SAP administrative console for BTP services), comparing the reported consumption against the contracted monthly CU commitment, and assessing whether any month during the contract term has recorded consumption above the committed level.

The specific audit risk with Datasphere is that many organisations do not actively monitor their CU consumption month-to-month. They sign the contract, deploy the platform, and then review costs only at invoice time — by which point an overage situation may have developed over several months. Implement a monthly CU consumption monitoring process, with an alert threshold set at 80 percent of your contracted monthly commitment, so that you have time to investigate and address any unexpectedly high consumption before an overage accumulates.

BTP Credit Consumption for Third-Party Integration

When Datasphere is used in conjunction with SAP Integration Suite (formerly CPI) to integrate non-SAP source systems, the Integration Suite workloads consume BTP credits separately from Datasphere CUs. A common audit trap is discovering that the BTP credits consumed by integration workloads were not modelled in the original commercial proposal — SAP's pre-sales team focused on the Datasphere CU commitment but did not properly account for the Integration Suite credit consumption required to populate Datasphere with non-SAP data. Ensure that any BTP commercial proposal for a combined Datasphere + Integration Suite deployment includes a detailed model of Integration Suite credit consumption, not just Datasphere CU consumption.

The Negotiation Playbook for Combined DWC + SAC Deals

The following strategic framework has been validated across our client engagements with combined DWC/Datasphere + SAC commercial decisions.

Establish Your True Capacity Requirement Before Negotiating

As with any consumption-based product, the foundation of a good DWC/Datasphere negotiation is an accurate model of your actual capacity requirement. Build this model based on: the specific data domains you are managing in Datasphere and their expected data volumes; the scheduled and on-demand workloads that will run against those data domains; the number of concurrent SAC users and their typical query behaviour; and a growth projection for years 2 and 3 of the contract based on your analytics roadmap. The capacity model should be built by a technical team with input from the business users and data engineering team — not solely by the implementation partner, whose interests may not be fully aligned with yours.

Separate the SAC Negotiation from the Datasphere Negotiation

SAP's commercial team will typically present DWC/Datasphere and SAC as a combined package with a blended commercial proposal. Before accepting this framing, assess whether you can negotiate each product more effectively on its own terms. SAC is a product where Microsoft Power BI is a credible and increasingly capable competitive alternative — using this competitive tension specifically in the SAC negotiation can drive significant pricing improvement without necessarily affecting the Datasphere commercial discussion, where the competitive alternatives are different (Snowflake, Microsoft Fabric). A combined commercial discussion that conflates two different competitive dynamics often produces worse outcomes than two separate discussions handled with product-specific competitive positioning.

Negotiate Expansion Rights at Pre-Agreed Rates

For both DWC/Datasphere CUs and SAC user licences, negotiate the right to purchase additional capacity or users during the contract term at a pre-agreed rate — specifically, at the discounted rate that applies to your committed volume rather than at list price. SAP is typically willing to agree to pre-priced expansion rights if the scope of potential expansion is reasonably bounded (for example, up to 50 percent of the initial commitment). These pre-agreed expansion rights protect you from list-price exposure on the growth that your analytics platform is likely to experience in years 2 and 3 of a 3-year commitment.

Secure Credit Roll-Over for BTPEA Deals

If you are purchasing DWC/Datasphere and SAC within a BTPEA, negotiate credit roll-over — the ability to carry unused credits from one annual period to the next within the BTPEA term. SAP's standard BTPEA terms do not include automatic roll-over: credits unused in year 1 expire at the start of year 2. For organisations that are building and deploying analytics capabilities progressively — with lower consumption in year 1 and higher consumption in year 3 — credit roll-over can save tens or hundreds of thousands of euros in stranded capacity costs.

Negotiate Renewal Price Continuity

In the renewal negotiation, push back on any attempt by SAP to reset the commercial baseline to list price. The starting position for a renewal of a DWC/Datasphere + SAC contract should be the pricing achieved in the original deal, not the current list price. If your usage has grown significantly, SAP has a legitimate interest in commercial growth — but this should be achieved through volume-based pricing adjustments on incremental capacity, not through a wholesale reset of the pricing structure that applies to the committed base.

Comparing SAP Analytics to Competing Platforms

For organisations that are not fully committed to SAP's data management architecture, the competitive landscape for analytics platforms in 2026 offers several credible alternatives. Understanding these alternatives — their strengths, their weaknesses relative to SAP's stack, and their pricing — is essential for building the competitive tension that drives SAP's commercial team to offer its best pricing.

Microsoft Fabric + Power BI: Microsoft's integrated data platform and analytics offering is the most commercially credible alternative to the DWC/Datasphere + SAC stack for organisations that are significant Microsoft customers. Microsoft Fabric provides data lake, data warehouse, and data engineering capabilities competitive with Datasphere, while Power BI provides BI and dashboarding capabilities at a substantially lower per-user cost than SAC. The key limitation is Microsoft's relative weakness in native SAP data integration: while Microsoft has improved its SAP connectors significantly, they do not match the depth of SAP's own native integration for complex S/4HANA and SAP BW scenarios.

Snowflake + Tableau or Looker: Snowflake as a data warehousing platform plus Tableau (Salesforce) or Looker (Google) as the analytics consumption layer is a well-established enterprise analytics architecture that competes directly with DWC/Datasphere + SAC. Snowflake's pricing model — based on compute credits and storage separately metered — is more transparent and competitive than Datasphere's at many volume levels, and Tableau's visualisation capabilities are generally rated more highly than SAC's by BI practitioners. The SAP integration challenge applies here as well: Snowflake has SAP connectors but they require custom implementation and ongoing maintenance.

Databricks + Power BI or Tableau: For organisations with significant machine learning and advanced analytics requirements alongside traditional BI, the Databricks Lakehouse Platform provides a compelling unified data and AI environment. Databricks' open source Spark and Delta Lake foundations appeal to data engineering teams and create lower vendor dependency than either Datasphere or Snowflake. The commercial model (DBUs — Databricks Units) is conceptually similar to Datasphere CUs, and similarly requires careful capacity planning.

How Redress Compliance Helps with DWC and SAC Licensing

Redress Compliance has supported organisations across Europe and globally in managing SAP Data Warehouse Cloud, Datasphere, and SAP Analytics Cloud commercial decisions across more than 80 engagements. Our advisory engagements consistently generate commercial outcomes that are materially better than what clients achieve when negotiating with SAP independently — typically 25 to 40 percent improvement relative to SAP's opening commercial position for Datasphere CU pricing, and 20 to 35 percent improvement for SAC user pricing.

Our DWC/Datasphere and SAC advisory services cover the following areas. Independent capacity modelling — we build the workload model that tells you how many CUs you need based on your actual data and workload profile, not SAP's generic benchmarks. Commercial benchmarking — we compare your current or proposed SAP analytics pricing against our database of comparable transactions from the past 12 to 24 months. Negotiation strategy — we develop and execute the commercial strategy, including competitive positioning, fiscal timing, and deal structure. Contract review — we review the specific terms of any proposed DWC/Datasphere or SAC contract before signature, identifying provisions that create unacceptable commercial risk. Audit support — we advise on audit response strategy and provide expert assessment of SAP's audit methodology and findings.

If you are managing a DWC renewal, an SAC expansion, a DWC-to-Datasphere migration, or a new combined analytics platform purchase in 2026, the most commercially impactful step you can take is to engage independent advisory support before beginning your commercial discussion with SAP. The investment in independent advice pays back consistently, measurably, and quickly in the form of better pricing, better contract terms, and lower commercial risk over the life of your analytics platform commitment.