SAP HANA Database Licensing: How SAP Charges and How to Pay Less

HANA Licensing Models: The Four Variants

SAP sells HANA in four distinct editions, each engineered to create a licensing trap that forces companies into higher-cost tiers. The sales pitch is straightforward: start small, scale painlessly. The reality is that most organisations land on expensive editions once they commit to the platform.

The four-edition matrix exists for a reason. SAP knows that procurement teams will compare edition pricing at the outset, but once your application architecture, integration pipelines, and team knowledge are built around HANA, switching costs are catastrophic. By the time you realise your "Platform Edition" cannot support the analytic workloads you actually need, switching to Enterprise Edition means not just a licence upgrade—it means re-testing, potential application refactoring, and negotiating a new master agreement. SAP wins either way: you pay the Enterprise Edition price, or you accept Platform Edition limitations and pay SAP consulting rates to work around them.

The strategic trap: SAP understands that technical architects choose Platform Edition or Express Edition, but C-level executives see the migration timeline and sign off on Enterprise Edition to "avoid upgrade costs later." Enterprise Edition fees are 50–60% higher, but amortised over 5–10 years, the cost-of-delay argument wins every time. By the time finance realises the mistake, HANA is embedded in your ERP roadmap and switching is prohibitively expensive.

How HANA Capacity Licensing Works

Unlike traditional SQL Server or Oracle licensing (which measure by processor cores or named users), SAP HANA licensing is based on RAM capacity allocated to the database. The licence meter is not what you use—it's what you allocate. If your server has 2TB of RAM and HANA is configured to use 1TB, you licence 1TB. If you configure it to use 1.5TB six months later, you need to buy 0.5TB more licence.

This design is extremely profitable for SAP. Database administrators naturally over-allocate to ensure performance headroom. A 500GB workload running on a 1TB allocation (which is common for production stability) means you're licensing for twice what you actually use. Over a 5-year contract, that over-allocation costs hundreds of thousands of pounds in unnecessary licensing fees.

HANA Licence Metrics: Full Use vs. Limited Use vs. Runtime

Within capacity licensing, SAP offers three distinct licence types. Each one is designed to trap a different segment of customers:

• Full Use Licence: The default. HANA can be used by any application, for any purpose. If you buy 1TB of Full Use, every application in your landscape can use HANA. Cost: the baseline.
• Limited Use Licence: HANA is restricted to a specific business process or application (e.g., "Finance only" or "S/4HANA only"). Cheaper (30–40% discount), but you cannot expand the use case without repurchasing. Most organisations eventually exceed the scope and either buy unlimited or negotiate an upgrade.
• Runtime Licence: HANA processes read-only data or application-driven transactions without modification. Requires third-party or customised applications that enforce the "read-only" constraint. Discount: 50–60%, but rarely suitable for ERP environments where data modification is inherent.

HANA Capacity Pricing Table

Below is the estimated licensing cost model based on allocated RAM capacity, including annual Enterprise Support at 22% of licence value:

These figures assume Full Use Enterprise Edition licensing. Limited Use licences reduce costs by 30–40%. Over a five-year contract term, the annual support escalation (typically 3–5% per year) compounds the total cost by an additional 10–15%.

The S/4HANA Bundling Trap

SAP doesn't sell S/4HANA without HANA. The S/4HANA Enterprise Management suite—the modern ERP platform replacing legacy SAP ECC—is architecturally bound to HANA database. SAP's messaging is consistent: "S/4HANA requires HANA. HANA requires S/4HANA. They are co-dependent."

This is technically inaccurate, but commercially perfect from SAP's perspective. S/4HANA can theoretically run on other databases (it is ABAP, after all), but SAP has engineered the application stack, licensing agreements, and support policies to make any alternative extremely difficult and expensive.

For enterprises running legacy SAP ECC today, the migration pitch is simple: "Your ECC environment is aging. Support is becoming constrained. Migrate to S/4HANA and you upgrade to modern technology, improved performance, and cloud optionality." What procurement teams often miss is the financial impact: you don't just licence HANA once. You licence HANA as the production database, then again for your UAT environment (another £360K–£700K), and often again for development or pre-production. If your current ECC landscape is running on Oracle or SQL Server with modest database licensing, switching to S/4HANA multiplies your database licensing spend by 3–5x across all environments.

The bundling works because SAP controls three variables: the application (S/4HANA), the database (HANA), and the support model (Enterprise Support). You cannot negotiate individual components without threatening your entire support contract. Teams that attempt to run S/4HANA on alternative databases find themselves without SAP support—a risk most organisations cannot accept.

Third-party support breaks this dependency. By adopting a TPS provider for HANA database support, organisations can cost-optimise the database layer without sacrificing S/4HANA implementation timelines or SAP application support. You keep S/4HANA on HANA (as required), but reduce database support costs by 50–60%.

Hidden HANA Cost Escalators

Licence cost is the headline. But SAP's true revenue model depends on cost escalators that accumulate silently across the contract term. A five-year HANA contract rarely costs what the initial quote promised.

The cumulative effect: a £360K initial licence often becomes a £600K–£800K five-year cost after escalations and add-ons are factored in. Procurement teams that negotiate only the headline licence fee miss the actual cost vector.

HANA vs. Alternative Databases: The TCO Reality

The financial argument for HANA often hinges on performance and feature claims. When measured purely on functionality, HANA is genuinely advanced. When measured on total cost of ownership, it is a poor choice for most organisations.

The comparison reveals a critical insight: HANA itself is expensive, but S/4HANA + HANA is catastrophically expensive. For organisations already running SAP ECC on traditional databases, the total cost of ownership of a HANA environment (including HANA database + S/4HANA application licensing) is 5–8x the cost of staying on ECC with third-party database support.

PostgreSQL or open-source alternatives appear dramatically cheaper on paper, but migration to a non-SAP database for an ERP system is extremely high risk. You lose SAP support, require bespoke database integration, and must accept extended testing cycles. For most enterprises, this risk is unacceptable.

The practical option: Stay on SAP ECC with SAP database, but switch database support to a third-party provider. You retain full SAP support for the application layer, avoid S/4HANA migration costs, and reduce your database support spend by 50–60%. This is the lowest-risk, highest-ROI path for most organisations.

SAP Audit Risk with HANA

HANA's memory-based licensing creates a unique audit exposure. The licence is measured by allocated RAM, not consumed RAM. In virtualised environments (VMware, Hyper-V), dynamic resource allocation, live migration, and memory overcommitment can make the actual allocated memory difficult to measure and verify.

SAP's audit process involves deploying a software scanner across your infrastructure, measuring the peak amount of RAM ever allocated to HANA processes, and comparing it against licensed capacity. In virtualised environments with dynamic memory allocation, peak allocation often far exceeds intended allocation—particularly during peak load periods, automated backups, or failover scenarios.

The audit risk is substantial. SAP audit reports frequently identify "unlicensed capacity" measured in hundreds of gigabytes, triggering multi-million-pound true-up costs. The most common cause: organisations virtualise HANA with 2TB of host RAM available and 1TB of dynamic allocation configured, but during a peak period, HANA draws 1.4TB due to a large batch load, a memory spike, or an analytic query. The audit identifies 1.4TB as the "actual" allocation, and you're suddenly 400GB unlicensed.

A third-party support provider reduces audit risk in two ways: (1) they actively manage HANA capacity planning and resource allocation to prevent unintended overallocation, and (2) they maintain documentation and configuration controls that evidence your actual licensed capacity, providing a defensible audit position. With stable, well-documented configuration, SAP audits become routine rather than expensive.

The Third-Party Support Option for HANA

A third-party support provider (TPS) covers SAP HANA database support independently of SAP's Enterprise Support programme. TPS covers:

• Security patches and critical updates
• Performance tuning and optimisation
• Backup and recovery operations
• High-availability and disaster recovery configuration
• Database upgrade and migration assistance
• Proactive monitoring and alerting
• Incident response and resolution (with 4–6 hour SLAs)

What TPS does not include: changes to SAP application code, S/4HANA functional support, or SAP module licensing. TPS is explicitly database-layer support. If your HANA environment is running S/4HANA or other SAP applications, you maintain SAP support for those applications separately.

The cost model is decisive. TPS providers typically charge 8–12% of the HANA licence Net List Value (NLV) annually. SAP's standard Enterprise Support is 22% of NLV. The difference—10–14 percentage points—translates to 50–60% cost savings.

On a 512GB HANA licence (£360K NLV), the annual support costs are:

• SAP Enterprise Support: £79,200/year (22%)
• Third-Party Support: £28,800–£43,200/year (8–12%)
• Annual Saving: £35,000–£50,000 (44–55% reduction)

Over a five-year contract, TPS reduces your HANA support spend by £175,000–£250,000. This is not a small saving—it often justifies the entire HANA migration cost for organisations on the fence about the investment.

The risk consideration: third-party support providers must be SAP-certified (or have equivalent credentials) to ensure technical competency. Reputable TPS vendors maintain SAP certification, employ former SAP database architects, and carry professional indemnity insurance. Vetting the TPS provider is critical, but the cost savings are substantial and legally defensible.

Negotiating HANA Licence Costs with SAP

SAP's standard licensing terms are published, but virtually never final. Enterprise sales teams have negotiating authority on multimillion-pound deals. Understanding your leverage points is essential.

Five Negotiating Strategies

1. Reference Competing Database Options

SAP's positioning assumes HANA is the only acceptable option. If you introduce competing databases (Oracle, PostgreSQL, Microsoft SQL Server) into the negotiation, the conversation shifts. "We're evaluating HANA against Oracle 23c and PostgreSQL 15 for our ERP environment. The total cost of HANA ownership needs to be competitive with these alternatives."

This is not a threat—it's a fact. SAP knows that migrating to a non-SAP database is extremely risky, but the possibility is sufficient leverage to open discount discussions. Aim for 15–25% discount on headline licence costs.

2. Use S/4HANA Deferral as Leverage

If SAP is positioning S/4HANA + HANA as a bundled migration, your explicit statement that "we are deferring S/4HANA by 3–5 years" changes the value proposition. SAP loses the application licensing, and database licensing becomes the only revenue. Significant discounts (20–35%) are possible if you commit to S/4HANA eventually but stay on ECC + HANA database now.

3. Multi-Year Pre-Pay Discount Negotiation

Proposing multi-year pre-payment (paying for years 2–3 upfront) provides SAP with cash flow certainty, and they will discount the future years by 10–15% to capture the value. Over a three-year contract, this typically amounts to £30K–£60K in savings.

4. HANA Capacity Right-Sizing

Many organisations are over-licensed. If your current ECC environment runs comfortably on 256GB of allocated RAM, but SAP's sales engineer recommends 512GB for "headroom," push back. Detailed capacity modelling (often free from consultants) can evidence that 256GB is sufficient, reducing licence costs by 50%.

Negotiate a clause allowing "capacity upgrade" at pro-rata cost if projections prove insufficient. This reduces the initial licence cost and transfers some risk to the organisation (a trade-off worth making).

5. Consolidation Credit for Legacy Licences

If you're consolidating multiple legacy SAP systems onto a single HANA platform, the aggregate legacy licences have residual value. SAP may offer "consolidation credit" that offsets a portion of the new HANA licence cost. This is typically 5–15% of the new licence value, but it's only offered if you ask.

Negotiation tactic: Engage an independent procurement firm or licensing consultant to prepare a detailed comparison of HANA vs. alternatives, capacity models, and TCO scenarios. Present this to SAP as your evaluation framework. SAP will typically respond with improved terms to prevent loss of the deal.