SAP HANA licensing surprises are among the most common cost overruns we encounter in S/4HANA migration engagements. Organisations budget for application licences and underestimate — or entirely miss — the HANA database cost component. For a 1TB production HANA deployment, enterprise-grade licensing costs £60,000–£130,000 per year. For large deployments exceeding 4TB, annual HANA licence costs alone can exceed £400,000. Understanding how HANA is licensed is therefore not an optional deep-dive — it is a prerequisite for any credible SAP commercial strategy.
How SAP HANA Licensing Works
HANA licensing is fundamentally memory-based. Unlike traditional database licensing (which is typically CPU- or core-based), SAP HANA is licensed according to the amount of RAM allocated to the HANA instance. This has significant implications: as data volumes grow and your HANA system requires more memory, your licence cost grows in parallel — unless you have negotiated fixed-memory terms or capacity caps upfront.
The licensing unit is "HANA memory" measured in 64GB blocks for most enterprise editions. SAP's standard pricing for HANA Enterprise Edition (the edition required for most production S/4HANA deployments) runs approximately £4,500–£8,000 per 64GB of licensed memory per year on a subscription basis, or £15,000–£25,000 per 64GB as a perpetual licence with 22% annual maintenance.
The Critical Distinction: Runtime vs. Full Use
SAP differentiates between HANA Runtime Licences and HANA Full Use Licences. Runtime licences are bundled with specific SAP application licences (S/4HANA, BW/4HANA, and others) and permit the use of HANA exclusively as the database for those specific applications. Full Use licences permit HANA to be used as a general-purpose in-memory database platform — including custom applications, third-party data, and analytics workloads not directly associated with an SAP application.
Many organisations unknowingly deploy workloads that convert their Runtime licences into Full Use requirements. Custom BW reports drawing on non-SAP data, operational reporting against HANA tables for non-SAP processes, and third-party integration layers that write to HANA schemas are among the most common triggers. The commercial consequence is a licence uplift from Runtime to Full Use pricing — a difference of 40–80% in annual cost on an equivalent memory allocation.
Key Risk: SAP's definition of what constitutes a Full Use trigger is intentionally broad. If your HANA system stores any data not associated with a licensed SAP application, or if third-party tools directly access HANA tables, SAP will typically assert Full Use requirements. Audit your actual HANA workloads before entering any SAP renewal or migration negotiation. Leading advisory firms including Redress Compliance and Atonement Licensing conduct HANA workload assessments as a standard pre-negotiation step.
HANA Edition Comparison
SAP markets several HANA editions. The distinctions matter commercially because they determine both what you can legally do with HANA and what you will pay.
| Edition | Primary Use Case | Key Capabilities | Relative Cost |
|---|---|---|---|
| HANA Express | Development / testing | Up to 32GB; no production use | Free / low cost |
| HANA Runtime | SAP app database | Bundled with S/4HANA, BW/4HANA | Included in app licence |
| HANA Advanced | Extended analytics | SAP apps + limited custom | 1.3–1.5× Enterprise |
| HANA Enterprise | Full platform use | All workloads; multi-tenant; full custom | Baseline Full Use pricing |
| HANA Cloud | Cloud-native SaaS | Consumption-based; elastic scaling | Variable / consumption |
For most large enterprises running S/4HANA on-premise or in a hyperscaler infrastructure-as-a-service (IaaS) environment, HANA Enterprise Edition with Runtime licensing (included with S/4HANA) is the baseline. The question is whether any workloads trigger Full Use requirements — and what the resulting licence gap looks like commercially.
HANA Cloud Licensing
SAP HANA Cloud is the cloud-native database-as-a-service offering within the SAP Business Technology Platform. It uses a consumption-based licensing model, purchased through BTP Credits. Capacity is measured in compute units (vCPUs and memory) rather than licensed memory allocation blocks, and scales elastically.
For organisations running RISE with SAP (SAP's cloud-delivered S/4HANA subscription), the HANA database is embedded in the RISE subscription — the HANA licence is not separately visible or negotiable in the same way. This is one of RISE's structuring features: SAP bundles infrastructure, application, HANA, and maintenance into a single subscription price, making it harder to benchmark individual cost components. See our SAP RISE negotiation guide for how to evaluate and negotiate RISE economics effectively.
For organisations exploring HANA Cloud as a standalone data platform capability (extended analytics, IoT data, third-party data integration), the economics depend heavily on workload sizing and BTP credit consumption patterns. The headline consumption rates are competitive with hyperscaler database services at small scale but can become expensive at enterprise data volumes without careful credit consumption planning. See our SAP BTP Licensing guide for the credit consumption framework.
Memory Sizing: Where Organisations Get It Wrong
HANA memory sizing is more complex than it appears, and undersizing at the point of contract signature creates both performance risk and licensing risk. SAP's sizing guidance for S/4HANA production systems is published through their Quick Sizer tool, but the output requires expert interpretation. Three common sizing mistakes that have commercial consequences:
1. Sizing for Current Data Volumes Only
A HANA licence covers a specific memory allocation. As the database grows — through transactional data accumulation, new modules, or BW expansion — you need additional licensed memory. Organisations that licence exactly what they need at go-live regularly find themselves purchasing additional HANA memory 18–36 months post-implementation, typically outside the leverage window of the original deal. Negotiating a growth provision or step-up entitlement into the original agreement is significantly more cost-effective than purchasing incremental memory at standard list price later.
2. Conflating DR and Production Requirements
SAP requires HANA licences for disaster recovery (DR) systems, though at a discounted rate. The standard DR discount is 50% of production licence cost for a warm standby system. Organisations sometimes assume their DR HANA is covered by production licences — it is not. For a production system with 2TB of licensed HANA memory, the DR system requires an additional 2TB of HANA memory at 50% cost: a meaningful line item that should appear in your total cost of ownership model from day one.
3. Dev/Test Landscape Licensing
SAP typically licences development and test HANA systems at 25–30% of production licence cost per tier. For a standard three-landscape SAP environment (production, quality/test, development), the total HANA licence stack is approximately 1.55× the production licence cost (production at 100%, QA at 30%, dev at 25%). This multiplier is frequently omitted from preliminary business case modelling, leading to budget variances discovered late in the procurement process.
Negotiation Principle: The most effective HANA licence negotiation strategy is to establish a committed multi-year total landscape size (production + DR + dev/test) and negotiate a bundled rate for the entire allocation. SAP offers significant discounts — typically 25–40% below list — for organisations committing to a defined landscape over three to five years. This approach also protects against incremental pricing on memory growth within the committed allocation.
HANA and the S/4HANA Migration Deal
For ECC customers migrating to S/4HANA, the HANA cost calculation is closely intertwined with the broader migration economics. The key variables are:
- Existing database: Customers currently running ECC on Oracle or SQL Server need to account for the Oracle/SQL Server licence cost savings when they decommission those databases — but only if the underlying Oracle licences are not committed in a ULA or multi-year agreement.
- HANA Runtime bundling: S/4HANA Professional User and other application licences include HANA Runtime for the S/4HANA database workload. This Runtime coverage should be carefully scoped to ensure maximum utilisation before purchasing additional Full Use licences.
- Conversion credit mechanics: SAP's standard ECC-to-S/4HANA conversion credits apply to application licences, not HANA database licences. HANA must be separately purchased or included in the RISE subscription.
- Total licence cost comparison: A proper ECC-to-S/4HANA TCO model must include current ECC + Oracle/SQL Server costs versus S/4HANA application + HANA + BTP costs. Many SAP-produced migration business cases omit the HANA incremental cost.
Our S/4HANA negotiation guide covers the full migration cost analysis framework, including the HANA cost integration. For organisations evaluating RISE as their migration vehicle, our RISE negotiation guide explains how HANA costs are embedded in the RISE subscription structure and what to benchmark.
Negotiation Strategies for SAP HANA
HANA is a genuine cost lever in SAP negotiations — one that is often underutilised because organisations focus primarily on application user licence negotiations. Four specific HANA negotiation levers that enterprise buyers can deploy:
1. Landscape Bundling
Negotiate the total landscape (production + DR + dev/test + any additional environments) as a single bundle at deal signature. SAP's commercial teams have meaningful discount authority on multi-environment HANA commitments. Bundle the HANA negotiation with the application licence discussion to maximise leverage — HANA should not be a separate afterthought negotiation.
2. Multi-Year Memory Commitment with Cap
Commit to a three-year HANA memory size in return for volume pricing, with a cap on annual memory expansion cost built into the agreement. This protects you against standard list-price incremental charges while giving SAP the revenue predictability they value. Well-structured cap provisions typically limit expansion pricing to 60–70% of new business list price.
3. Runtime Maximisation
Before purchasing any Full Use licences, audit every HANA workload to determine whether it genuinely requires Full Use or whether it can be restructured to operate within Runtime coverage. In our experience, approximately 35–40% of organisations acquiring Full Use HANA licences are doing so unnecessarily — their workloads could be configured to operate within bundled Runtime coverage with modest architectural adjustments.
4. Hyperscaler Infrastructure Negotiation
If deploying HANA on AWS, Azure, or Google Cloud infrastructure (rather than on-premise or via RISE), negotiate the hyperscaler contract separately and independently from the SAP licence. SAP and hyperscalers have commercial partnership agreements that can create linkage in deal structures — but buyers who negotiate these elements independently typically achieve better outcomes than those who accept SAP's "cloud migration package" pricing.
For organisations seeking independent advisory on SAP HANA licensing and negotiation, our software licensing advisory practice and SAP vendor practice provide comprehensive commercial support from former SAP executives who understand both the technical and commercial dimensions of HANA agreements.
Key Takeaways
SAP HANA licensing is memory-based, edition-tiered, and easy to underestimate. The most important principles for enterprise buyers are: understand the Runtime vs Full Use boundary before any negotiation; size the total landscape (production, DR, dev/test) from day one; negotiate HANA as part of the broader SAP deal rather than as a separate afterthought; and model HANA costs explicitly in any S/4HANA migration business case. The difference between an informed HANA negotiation and an uninformed one is routinely £200,000–£800,000 over a three-year agreement for large enterprise deployments.
For a downloadable framework covering SAP negotiation benchmarks and HANA cost modelling, see our SAP Negotiation Playbook.