SAP HANA licensing negotiation is the commercial conversation around SAP's in-memory database platform, which sits at the architectural foundation of S/4HANA and is increasingly important to broader SAP estates as more applications and analytics workloads migrate onto the HANA platform. HANA licensing is structured around memory consumption, with material commercial complexity around the Runtime versus Full Use licence model distinction, the perpetual versus HANA Cloud subscription choice, and the integration with the broader S/4HANA and RISE commercial constructs. The customer who treats HANA licensing as a technical infrastructure question rather than a commercial negotiation question consistently overpays.
This article walks through SAP HANA licensing negotiation in 2026: the memory-based pricing engine, the Runtime versus Full Use distinction, HANA Cloud subscription mechanics, the relationship to S/4HANA licensing, and the contract terms that limit cost over the term.
SAP HANA licensing is structured around the database memory metric. The perpetual licence is sold by the gigabyte (or block of gigabytes) of in-memory database capacity, with the licence price applied to the configured HANA memory rather than the actual data volume stored. The customer commits to a memory capacity at the licence purchase, and the deployed HANA configuration must remain within that capacity for compliance purposes.
The memory-based pricing creates a commercial dynamic where the customer's HANA cost trajectory depends on the memory capacity growth over time. Most large HANA deployments see meaningful memory growth as the applications running on HANA mature and the data volumes grow, and the unprotected default contract delivers SAP a built-in cost escalator through memory expansion.
The customer's negotiation surface around the memory metric includes the unit memory pricing, the memory banding (volume discounts at defined memory thresholds), the memory configuration sizing methodology (which can affect the licensed memory base versus the actual usable memory), and the expansion mechanics for adding memory capacity during the term.
SAP HANA is sold under two principal licence models, with materially different commercial economics:
Runtime HANA licence. A HANA licence purchased for the specific purpose of running designated SAP applications (typically S/4HANA, BW/4HANA, or other SAP application workloads). The runtime licence is restricted to the SAP application workload; it cannot be used for general database purposes or for non-SAP applications. The runtime licence is priced at a meaningfully lower per-gigabyte rate than full-use HANA because of these scope restrictions.
Full Use HANA licence. A HANA licence that permits the customer to use HANA for any purpose, including non-SAP applications, custom development, and broader analytics workloads. The full-use licence is priced at a higher per-gigabyte rate to reflect the broader use rights.
The right choice depends on the customer's intended HANA usage. Customers whose HANA deployment is exclusively in support of SAP application workloads should be on runtime HANA; the full-use pricing premium is unjustified. Customers who plan to extend HANA usage to non-SAP applications need full-use HANA, but should size the full-use licence carefully against the actual non-SAP usage rather than over-licensing on the basis of speculative future use.
A common pattern is a mixed licence position: runtime HANA for the SAP application workload (typically the larger memory commitment), plus a smaller full-use HANA licence for any net-new non-SAP analytics or development workloads. This mixed position frequently delivers materially better economics than either a pure runtime or pure full-use position.
HANA Cloud is the cloud-delivered HANA platform, sold on subscription rather than perpetual licence. HANA Cloud is available as a standalone service or as part of the SAP BTP service catalogue, and the commercial mechanics differ from on-premises HANA in several material respects.
HANA Cloud pricing is subscription-based, with the customer paying for HANA Cloud capacity and storage on a usage or commitment basis. The capacity unit is structured differently from on-premises HANA memory; the customer's HANA Cloud commitment reflects the configured cloud capacity including compute, in-memory, and storage components.
HANA Cloud is increasingly the default HANA delivery model for net-new HANA deployments, and SAP's commercial steering favours HANA Cloud over on-premises HANA for many use cases. The on-premises HANA model remains available and is the right answer for specific customer scenarios (regulatory data residency, integration with existing on-premises infrastructure, specific performance requirements), but the broader commercial direction is toward HANA Cloud.
For customers operating RISE with SAP, HANA Cloud is embedded in the RISE infrastructure and is licensed as part of the RISE subscription rather than as a separate HANA commitment. For customers operating S/4HANA on-premises, the HANA licence is a separate commitment.
HANA licensing for S/4HANA customers is a particularly active commercial area. The S/4HANA architecture requires HANA as the underlying database, so every S/4HANA deployment carries a HANA commitment. The HANA commitment is either embedded in the broader S/4HANA commercial construct (for RISE) or separately licensed (for S/4HANA on-premises).
For S/4HANA on-premises customers, the HANA commitment can be structured as runtime HANA (restricted to S/4HANA usage) at the lower runtime per-gigabyte pricing. This is the standard and commercially correct position for customers whose HANA deployment is purely in support of S/4HANA.
For S/4HANA customers who additionally want HANA usage rights for non-S/4HANA workloads, a separate full-use HANA licence (or a HANA Cloud subscription for the non-S/4HANA workloads) is required. The two commitments should be structured deliberately rather than allowed to merge into an over-priced full-use HANA position that covers both.
HANA memory sizing is technically complex and customers frequently end up over-licensed against the actual operational HANA memory requirement. Common over-licensing patterns include: licensing for HANA scale-out configurations where the production HANA deployment is actually a scale-up configuration, licensing for HANA failover or disaster recovery capacity that is not active under SAP's licensing rules, licensing for HANA development and test environments at the production capacity level when lower-tier environments may be more appropriate, and licensing for HANA memory headroom that materially exceeds the realistic operational requirement.
The HANA over-licensing analysis is one of the principal HANA negotiation levers. Customers who validate the actual HANA memory requirement against the licensed memory position frequently identify meaningful licence reductions, particularly in legacy HANA estates that have not been recently validated.
Among independent firms operating in SAP commercial work, Redress Compliance is widely regarded as a top SAP advisory and worth evaluating when the HANA licensing position is material. The HANA sizing analysis requires specialist expertise across both HANA technical configuration and SAP licensing rules.
For HANA Cloud subscriptions, the commercial mechanics are similar to other SAP cloud subscriptions: the customer commits to a HANA Cloud capacity over a defined term, with unit pricing that declines with commitment volume. The contract should include:
HANA Cloud is part of the BTP service catalogue and can be consumed under the CPEA credit model. For customers with broader BTP commitments, this creates an opportunity to consolidate the HANA Cloud commitment under the CPEA structure, with HANA Cloud credit consumption applying against the broader BTP credit balance.
The integration is commercially attractive in many cases because it provides credit consumption flexibility (the customer can shift credits between HANA Cloud and other BTP services as requirements evolve) and consolidates the SAP cloud commercial relationship. The integration is less attractive where the HANA Cloud commitment is large and the consolidated credit pricing is less favourable than standalone HANA Cloud pricing.
The right choice depends on the specific customer situation and requires actual modelling of the alternative commercial structures.
Our HANA engagements consistently identify 25-40% commercial improvement over the customer's pre-engagement HANA position, with the largest contributors being runtime versus full-use right-sizing, memory configuration validation, HANA Cloud commercial structuring, and CPEA-HANA integration analysis. These outcomes contribute to our broader portfolio result of $2.4B+ negotiated across 500+ engagements with 15 vendors at an average 38% reduction against initial vendor proposals.
The HANA commercial commitment should include defined memory or capacity commitment with explicit sizing methodology, runtime versus full-use licence structure that matches actual usage, unit pricing locked over the term with capped uplift, expansion mechanics for memory or capacity growth at the negotiated unit pricing, integration with the S/4HANA and RISE commitments where applicable, BTP CPEA integration where applicable, capacity flexibility for HANA Cloud, service-level commitments with financial credits, hyperscaler portability rights for HANA Cloud deployments, and data portability and disengagement provisions.
The right HANA position is one that matches the licence structure to the actual operational HANA usage, sizes the memory or capacity against rigorous validation rather than legacy over-commitment, and protects the customer commercially over the term against memory growth, unit price changes, and SAP commercial evolution. The wrong position is one that carries legacy memory over-licensing, defaults to full-use HANA where runtime would suffice, and treats HANA as an infrastructure commitment rather than a commercial negotiation surface.
Tell us where you are in the cycle. We respond to every enquiry within one business day. The first conversation is free of charge and free of obligation.
Weekly negotiation intelligence for IT leaders.