Introduction – Why HANA Changes the Licensing Equation
Migrating to SAP S/4HANA means adopting SAP’s own HANA in-memory database – you can’t run S/4HANA on Oracle or SQL Server.
In SAP ECC days, you could choose a third-party database, but with S/4HANA, HANA is mandatory. This shifts database licensing from an afterthought to a strategic budget factor.
How you license HANA can make or break your migration budget, because the cost and terms of that license will directly impact your total cost of ownership (TCO). Read our ultimate guide to SAP S/4HANA Licensing Migration Cost Traps: Don’t Let Licensing Surprise You.
In practical terms, moving to S/4HANA introduces a new cost structure for your ERP environment. You’re not just paying for S/4 software licenses – you must also budget for the HANA database license and its ongoing support fees.
Many organizations treat the database as a technical detail until the invoice arrives. To avoid surprises, it’s crucial to plan HANA licensing early in your migration project and bake it into your ROI calculations.
Think of it this way: S/4HANA forces you onto SAP’s road (the HANA database), and you need the right “vehicle” (license type) to drive on it. Choosing the wrong licensing model or sizing poorly can lead to oversized costs or compliance issues down the line.
On the flip side, smart licensing choices can save hundreds of thousands in fees.
Checklist: Before migrating, make sure to:
- Identify the HANA edition you need: Will you use Runtime (SAP-only use) or Full Use (broader use)?
- Validate your sizing assumptions: Determine if HANA cost will be based on memory or cores, and size realistically.
- Include HANA in your budget model: Add the HANA license cost (and support) into your migration TCO/ROI analysis from the start.
HANA Licensing Models: Runtime vs Full Use
When planning for HANA licensing, start by choosing between two models: SAP HANA Runtime or SAP HANA Full Use (Enterprise Edition).
This decision defines both your usage rights and cost structure:
- HANA Runtime License: This is a discounted license that only permits HANA to be used with SAP applications like S/4HANA (and maybe SAP BW/4HANA if included). It’s often priced at roughly 15% of the SAP software’s value. For example, if you’re licensing $500,000 of S/4HANA modules, the HANA runtime license might cost around $75,000. Annual support (typically 22%) is added on top. The runtime option is cheaper upfront – essentially a bundling deal for SAP’s own database – but comes with a big limitation: no third-party or custom applications can directly access that HANA database. It’s like a “locked” database only for SAP’s use. This is ideal if you only plan to use HANA for S/4HANA itself and nothing else. Many traditional SAP shops fall into this category, using HANA merely to make S/4HANA function.
- HANA Full Use License (Enterprise Edition): This license allows you to use HANA for any application or purpose, SAP or non-SAP. You can build custom apps on HANA, use third-party tools, or run other databases on the same HANA platform. The trade-off is cost. Full Use HANA is usually licensed by hardware capacity (either the memory size in gigabytes, or sometimes by processor cores), and it costs significantly more – often 2×–3× the price of a runtime license for an equivalent system. For instance, a HANA Full Use license for a given environment might cost in the high six figures, compared to a low six-figure sum for the runtime option. You’re paying a premium for flexibility. Full Use makes sense if you intend to use HANA as a multi-purpose data platform – say, powering S/4HANA plus a custom analytics application, or consolidating data from non-SAP systems.
Conversational Tip: Think of the Runtime license like leasing a car – it’s cheaper, but you’re only allowed to drive on SAP’s “road.” Full Use is owning the car outright – you can take it anywhere, but it costs more.
Example Clause: “Customer licenses HANA Runtime for SAP applications only, with the right to upgrade to a Full Use license at a prorated cost.” (This kind of clause lets you start with Runtime and convert to Full Use later by paying the price difference, protecting you if your needs grow.)
Checklist: When deciding between Runtime and Full Use:
- Assess your use cases: Will HANA exclusively serve SAP apps, or will you need it for custom or third-party applications?
- Choose Runtime for SAP-only workloads: If you don’t plan to use HANA beyond S/4HANA (no external integrations at the database level), the cheaper Runtime license is usually sufficient.
- Secure an upgrade path: If you opt for Runtime, negotiate terms to upgrade to Full Use later if needed (e.g., agreeing on how to credit your initial investment if you expand usage).
Read about S4 Hana licensing pitfalls, SAP S/4HANA Licensing Pitfalls During Migration: How to Avoid Paying Double for Your SAP Move.
Licensing Metrics – Memory vs Core-Based Models
Beyond license type, understand how SAP calculates HANA license cost.
There are two primary metrics in play, depending on your deployment model:
- Memory-Based Licensing (per GB of RAM): Traditionally, on-premise HANA licenses are sold according to the memory size of the database. You purchase HANA in predefined memory blocks (for example, in 64 GB increments). The more memory you license, the higher the cost. This model is straightforward: if your S/4HANA environment needs 256 GB of HANA memory, you license 256 GB (4 blocks of 64 GB, in this example). Higher memory = higher license fee, regardless of how much of that memory is actively used day-to-day. Most on-premises S/4HANA customers and some private cloud setups use this model. It’s critical to size accurately – oversizing memory means overspending. (For instance, a 1 TB HANA license might cost hundreds of thousands of euros; sizing 20% too high could mean a six-figure sum paid for capacity that sits idle.)
- Core-Based Licensing (per CPU/vCPU): In some cloud or subscription scenarios (such as RISE with SAP or certain hyperscaler offerings), HANA cost is tied to processing power rather than fixed memory. Here, you pay based on the number of HANA CPU cores or virtual cores allocated to your instance. This model can be easier to scale elastically – adding more CPU (and implicitly more memory) could simply increase your subscription fee. However, core-based pricing often comes bundled in broader packages, which might include a markup for the infrastructure and management. RISE with SAP, for example, includes HANA database usage in the overall subscription price for S/4HANA Cloud. You won’t get a separate HANA bill – it’s baked into your user licenses – but you should know that the sizing (in cores and memory) still matters, as it influences your cloud subscription cost.
Key point: Always verify which licensing metric applies to your S/4HANA deployment. If you’re self-hosting or doing a standard on-prem license, expect a memory-based model.
If you’re going with SAP’s cloud (RISE) or perhaps licensing via a cloud marketplace, ask if the pricing is core-based or included in a flat subscription.
The metric affects how you optimize resources: for memory-based systems, you minimize unused RAM; for core-based systems, you ensure CPU allocations align with actual workload needs.
Checklist: To manage metric-based costs effectively:
- Confirm your model: Is your HANA license priced by GB of memory or by CPU cores (or is it included in a SaaS subscription)?
- Align with sizing reports: Cross-check the licensing metric against your SAP Quick Sizer or infrastructure plan to ensure it matches the assumptions.
- Run “what-if” scenarios: Understand cost sensitivity – e.g., if memory usage grows 10%, how much more will licensing cost? This helps avoid nasty surprises if your data footprint or user count increases.
The importance of rightsizing S4Hana, Avoiding Shelfware in Migration: How to Right-Size S/4HANA Licenses and Retire the Old Ones Smartly.
The Oversizing Trap – When “Future Proofing” Becomes Costly
Vendors and implementation teams often advise “future proofing” your HANA environment by buying more capacity upfront. Be careful: oversizing is a common cost trap in S/4HANA projects. Yes, you want headroom for growth, but buying tomorrow’s capacity today means paying for shelfware (unused capacity) from day one.
Risks of Oversizing: If you license significantly more HANA memory than you actually use in the first few years, you’re paying for idle RAM.
This has a double cost: the initial license fee (which could be hundreds of thousands of dollars too high) and the annual maintenance on that inflated license base (SAP support is typically 22% of license cost yearly – applied to all that extra capacity you’re not utilizing). Unlike cloud infrastructure, you can’t easily scale a perpetual license down.
SAP does not readily allow you to “return” part of a license for credit. Once you own those HANA GBs, you’re stuck with them (and their support costs), even if your actual usage lags behind the prediction. In other words, oversizing is essentially pre-paying for future growth – great for SAP’s revenue, not so great for your budget.
Conversational Tip: SAP’s idea of “future-ready” often means paying for next year’s usage today.
So how do you avoid the oversizing trap without risking performance? Validate sizing assumptions independently. Use SAP’s sizing tools (like Quick Sizer), but also review your current database footprint and growth trends.
Consider engaging an expert to sanity-check the implementation partner’s sizing – they might pad the numbers “just to be safe.” It’s wiser to start with what you realistically need for the first 1-2 years and then have a plan to expand later if needed.
One strategy is to negotiate flexible expansion clauses in your SAP contract. For example, arrange the right to purchase additional HANA capacity later at the same discount or rate as the initial purchase. That way, you aren’t forced to overbuy now out of fear of higher costs later.
You might also cap annual growth charges to avoid budget shock if you do scale up.
Example Clause: “Customer may expand HANA licensed memory by up to 20% per year at the same per-GB price as the initial license.” This ensures you can scale gradually without a pricing penalty, instead of oversizing upfront.
Checklist: To prevent costly oversizing:
- Know the growth plan: Understand how much extra capacity (if any) was baked into the sizing. Challenge overly generous “future growth” buffers.
- Document sizing rationale: Ensure you have transparency on why X GB of HANA was recommended. If it includes 5-year growth, you might decide to buy for 2-3 years now and add later.
- Avoid paying for unused capacity: Wherever possible, buy what you need now (plus a small safety margin), and utilize contractual terms or options to add more when justified by actual growth.
Accounting for HANA in Your Migration Budget
Don’t let the HANA license be an unplanned surprise in your S/4HANA migration budget. Many CIOs focus on application licensing costs (for S/4HANA modules, users, engines, etc.) and infrastructure costs, but treat the database as “included” or forget that it has its own price tag.
Fact: If you’re moving to S/4HANA on-premise or in a private cloud, you will be buying a HANA database license (unless you opt for SAP’s all-inclusive RISE subscription). This cost must be accounted for in any ROI or business case for the migration.
A common misconception is that the HANA license is just a technical necessity, not a major budget item. In reality, the HANA license (plus its 22% annual support fee) can significantly impact your ongoing run costs. If you’re replacing an existing database (like Oracle or IBM DB2), you might save on those third-party licenses or maintenance – but those savings likely shift to SAP’s column now.
Be mindful if you previously paid for an Oracle or SQL Server license as part of your hardware bundle or through a different team; after migrating, that expense will transform into an SAP HANA license expense.
Also, consider the interplay with existing SAP maintenance. If you’re transitioning from ECC under maintenance to S/4HANA, check whether HANA license support is an incremental cost or if any credits apply. (Usually, HANA license support is additive – a new line item on top of S/4 support.) For cloud deployments under RISE with SAP, clarify that the HANA database usage is included in the subscription.
RISE typically bundles HANA runtime rights into the service, but double-check your contract to avoid double-paying or missing it in the fine print. If you use a hyperscaler (AWS, Azure, GCP) and bring your own HANA license, remember to budget for both the cloud infrastructure and the SAP license.
And watch out for any cloud provider markups: for example, if you rent HANA through a cloud marketplace, the cost might include a premium over a direct SAP license (for the convenience of hourly billing and underlying hardware).
Pro Tip: If HANA isn’t on your budget sheet, it’s probably hiding in SAP’s package price. In other words, SAP may have rolled the database cost into a bigger number – you still pay for it one way or another. Always surface the database costs explicitly.
Checklist: When budgeting for S/4HANA:
- Line-item the HANA license: Make the HANA database license (and support fees) a visible entry in your budget and TCO model – it’s too large to lump under “miscellaneous.”
- Account for support uplift: Plan for the annual support on the HANA license (usually 22% of whatever license fee you pay). This will recur every year and grow if your HANA footprint grows.
- Verify cloud inclusions: If using RISE or a cloud solution, confirm in writing whether the HANA license is included. If not, get quotes for it so you’re not underestimating your costs.
Negotiation Levers and Optimization Tactics
SAP knows you must have HANA for S/4HANA – it’s non-negotiable because you need to buy it. However, the price and terms are negotiable. You still have leverage to optimize your HANA licensing costs if you plan and negotiate strategically as part of your S/4 deal.
Here are some tactics to consider:
- Trade-In Credits for Legacy Databases: If you are coming from a non-HANA database (Oracle, IBM, Microsoft) and paying maintenance on those, see if SAP will provide a credit or discount on HANA licenses for moving off a competitor’s product. In some cases, SAP has offered programs or one-time incentives for switching to HANA (especially if you were licensing the third-party DB through SAP contracts). Even if not formally offered, you can raise the point: “We’ll be saving money by dropping Oracle – help us justify HANA by offsetting that cost.”
- Bundle HANA in the S/4HANA License Deal: Don’t negotiate your S/4 licenses and HANA licenses in silos. When you’re signing a new S/4HANA contract or conversion, include the HANA database in the package. SAP will be keen to close the full S/4 project deal, and you can often get a better overall discount by bundling. For example, negotiate the percentage for HANA runtime down from the standard 15%, or get extra HANA capacity thrown in if you’re paying for Full Use. Leverage the fact that HANA is critical to S/4 to make SAP sharpen its pencil on price.
- License Conversion and Reallocation: If you have sunk costs in existing database licenses (especially if acquired via SAP), ask about conversion options. SAP may allow you to convert unused SAP software value into HANA licensing. For instance, if you bought a Sybase or other SAP database product that you’ll retire, you might get a credit toward HANA. Additionally, if you previously paid for SAP Oracle runtime licenses as part of ECC, those might be tradable for HANA runtime licenses under certain programs. It never hurts to ask.
- Multi-Year Agreements and Price Locks: Predictability can be just as valuable as one-time discounts. Negotiate a multi-year price lock for HANA licensing and support. This could mean SAP agrees not to increase support fees beyond the standard rate, or they fix the price per GB for additional HANA purchases for, say, 3 years. Locking in your unit costs for future expansions (as mentioned earlier) is a great guard against the “price hike later” tactic. Also, try to lock maintenance at 22% of net price (or lower if you can negotiate it) for at least a few years without inflation surcharges.
Conversational Tip: SAP knows HANA is non-negotiable – but your pricing still is. Everything is negotiable if you come prepared.
Example Clause: “Customer receives a credit for decommissioned Oracle database licenses equal to 100% of their remaining Oracle support fees, applied toward the cost of HANA Runtime licenses.” (This kind of term ensures you don’t pay double maintenance during the transition and get value for previous investments.)
Checklist: When negotiating HANA as part of your S/4 migration:
- Document trade-ins/credits: If SAP offers any credit for legacy databases or license swaps, get it in writing and subtract it from the HANA cost in your contract.
- Cap and lock costs: Secure a cap on maintenance (no surprise increases) and lock in pricing for anticipated growth or additional HANA purchases over the next few years.
- Bundle for discounts: Aim to finalize HANA licensing at the same time as S/4 licensing – use the total deal value as leverage to improve the HANA terms (e.g., better discount percentage or extra capacity).
Governance – Monitoring HANA Cost Post-Migration
Signing the contract is just the start. After you go live on S/4HANA, you should treat HANA licensing as an ongoing governance priority. This will help you stay compliant and avoid needless expenses as your usage evolves.
First, set up regular monitoring of your HANA usage. If you have a Full Use license with a memory limit, track how much memory is actually in use versus what’s licensed. Suppose you see your utilization creeping up toward the licensed amount (e.g., consistently 85%+ of capacity). In that case, that’s a signal to plan for an expansion before you hit the limit (running over your licensed memory could be a compliance violation).
If you’re on a Runtime license, monitor that the HANA database isn’t being accessed in unauthorized ways. For example, ensure no one connects a third-party reporting tool directly to the HANA schemas, as that could cross the line into needing a Full Use license.
Conduct an annual internal audit or compliance check for your HANA usage. Verify that the appropriate license type covers all HANA instances in your landscape and you aren’t inadvertently using HANA for something outside your entitlement.
This is especially important if your organization adds new analytics tools, interfaces, or data loads – make sure they align with your license (Runtime license = only SAP app usage; anything else would require Full Use).
Also, review any expansion rights or clauses before you scale up your environment. If your user count grows or you implement additional modules that drive more data into HANA, check if that pushes you into needing more HANA capacity.
Refer to your contract: do you have a right to a certain amount of extra GBs at a fixed price? If not, engage SAP early to discuss expansion options – you’re better off negotiating additional capacity proactively rather than after an audit flags you for overuse.
It’s a good practice to maintain a simple HANA license dashboard internally. This could be a quarterly report that shows current HANA licensed capacity vs. used capacity, any external connections (to flag potential compliance issues), and the cost implications.
With this information, your team can forecast when you might need to budget for more HANA licenses and avoid last-minute scrambles.
Checklist: Post-migration HANA license governance:
- Monitor memory utilization (or CPU usage) regularly – e.g., monthly. Catch any growth trends early.
- Review compliance annually: Ensure your HANA usage (what it’s used for and how much is used) aligns with your license entitlements.
- Plan before expanding: Before adding hardware or additional HANA workloads, verify your license can cover it, or use any negotiated expansion clause. This avoids unplanned costs or compliance gaps.
Action Step: Build a HANA License Dashboard that tracks your licensed capacity, current usage, and cost. For example, if you see memory usage at 70% of licensed capacity and growing, you can budget and negotiate for an increase before it hits 100%. This proactive approach keeps you in control of costs and compliance.
5 Ways to Control Your HANA Database Costs
Finally, to wrap up, here are five practical ways you can control HANA database costs during and after your S/4HANA migration:
- Choose the cheapest suitable license: Opt for the Runtime license unless you have a clear need for HANA outside of SAP applications. Don’t pay for full-use freedom if you won’t use it.
- Right-size your HANA memory allocation: Only license the capacity you realistically need. Avoid buying “just in case” memory that will sit unused – you can always scale up later with the right terms in place.
- Negotiate upgrade and expansion terms upfront: Lock in the ability to upgrade from Runtime to Full Use, or to add more HANA capacity later, at predetermined rates. This protects you from SAP’s list prices as your business grows.
- Leverage legacy investments: If you’re retiring Oracle/DB2/SQL licenses, seek credits or discounts on HANA. Also, repurpose any SAP license value you can (like converting old DB licenses) to offset the HANA cost.
- Review usage quarterly: Make HANA license compliance and optimization a quarterly habit. Ensure you’re using what you paid for, stay within bounds, and identify opportunities to fine-tune (for example, archiving data to control HANA memory growth).
By understanding these HANA licensing considerations and tactics, you can migrate to S/4HANA with eyes wide open on database costs. With the right approach, you’ll meet SAP’s requirements without overspending, ensuring your HANA investment truly supports your business value from S/4HANA.
Read about our SAP Services.
