The biggest S/4HANA cost driver isn’t hardware or implementation – it’s the licensing model. Whether you opt for a traditional on-premise license or SAP’s cloud subscription (e.g., RISE with SAP), this choice determines not just your spending but also your control, audit exposure, and dependency on SAP. SAP positions its S/4HANA Cloud subscriptions as a simpler, all-in-one solution.
But that convenience often comes at the expense of flexibility and pricing leverage.
It’s critical to scrutinize the “cloud-first” narrative and understand the trade-offs before deciding on your S/4HANA deployment model. For an overview, read our SAP S/4HANA Licensing Guide: Models, Costs, and Migration Insights.
Overview: SAP Cloud vs On-Premise Licensing Models
On-Premises S/4HANA (Perpetual License): You purchase a perpetual license with a one-time upfront fee and own the software indefinitely. After that, you pay annual support (typically 22% of the license price) for updates and support.
This is a CapEx-heavy model – a large upfront investment followed by yearly maintenance fees. The key benefit is ownership: even if you stop paying maintenance, you retain the right to use the software. You also have complete control over where and how to run S/4HANA (on your servers or a cloud of your choice) and when to apply upgrades.
S/4HANA Cloud (Subscription via RISE or Public Cloud): You rent the software via a recurring subscription (typically a 3- to 5-year contract). The OpEx subscription fee covers the S/4HANA software, underlying infrastructure (hosting), database, regular upgrades, and support in one bundle.
You do not own the software – your rights last only as long as the subscription term. SAP manages the environment (especially in the RISE with SAP private cloud or the multi-tenant public cloud edition), so infrastructure and upgrades are handled for you.
This lowers the customer’s IT workload and upfront costs, but it locks you into SAP’s platform and timeline. If the subscription ends, your access to the system will be terminated.
Comparison Snapshot:
Below is a quick comparison of key differences between on-premise perpetual licensing and S/4HANA Cloud subscription (RISE):
| Category | On-Premises Perpetual | S/4HANA Cloud (RISE Subscription) |
|---|---|---|
| Ownership | Customer owns software licenses indefinitely. | SAP retains ownership; you only have usage rights for the term. |
| Cost Type | Capital expense (one-time license purchase) + ongoing maintenance (≈22% annually). | Operating expense (recurring subscription fee covering software, infrastructure, and support). |
| Flexibility | High – fully customizable environment, custom code and add-ons allowed. | Limited – standardized environment with restricted customizations (especially in public cloud SaaS). |
| Support | Optional, separate annual support contract (can use SAP or third-party). | Included in subscription (SAP provides support and manages updates). |
| Exit Cost | Low – you keep the software license even if you stop maintenance. | High – if subscription lapses, you lose access to the software entirely. |
Licensing Metrics and Measurement Differences
On-Premises Metrics: Traditional on-prem S/4HANA licensing uses Named User licenses and sometimes additional package/engine metrics. You must license each human user as a specific category (Professional, Functional/Limited, Employee Self-Service, etc.), and possibly license certain modules by usage (e.g., transactions, revenue, or orders for engines).
The upside is that you have the flexibility to reallocate licenses internally.
For example, if an employee leaves, you can assign their user license to a new hire. You can also adjust user license types (e.g., swap some Professional users for Limited users) as long as you have the appropriate licenses, allowing you to optimize license usage over time.
Cloud Metrics (FUE Model):
S/4HANA Cloud introduces the Full Usage Equivalent (FUE) metric. Instead of purchasing individual user types, you subscribe to a total number of FUEs that represent your total entitled usage. A role type with a weighting factor defines each user.
For example, an advanced “Professional” user might count as 1.0 FUE, while a casual self-service employee user might count as 0.2 FUE. If you subscribe to 1,000 FUEs, you could allocate, say, 800 professional users (800×1.0) and 1,000 employee self-service users (1,000×0.2 = 200 FUE) within that total of 1,000 FUE = 1000.
The FUE model provides some flexibility to mix user types as long as you stay within your total, but it lacks on-the-fly adjustability.
The ratios and allocations of user types are fixed in your contract. If your needs change (e.g., you suddenly need more heavy users and fewer light users), you may have to renegotiate the contract or purchase additional FUEs – you can’t simply reassign usage as freely as with perpetual named users.
Measurement and True-Up: In on-prem licensing, compliance is checked via periodic audits or system measurements (like SAP’s USMM/LAW reports). You have the chance to true-up licenses if you’ve outgrown your entitlement, often with some negotiation on timing and cost. In the cloud model, SAP is monitoring usage continuously.
There’s no traditional “true-up” audit process – any usage above your contracted FUE or other metrics will be noted and charged per the contract (either immediately or at renewal). Essentially, compliance is enforced in real-time.
One important consideration is that when your subscription term is up for renewal, it resets your baseline: you’ll be negotiating from whatever usage level you’ve reached, and any initial discounts could be reset. This means if your user count or data volume grew during the term, the renewal could significantly increase costs unless you planned for it.
Cost Structure and Pricing Mechanics
On-Premises Cost Structure: With perpetual licensing, you pay a large upfront license fee, then 22% per year for support. This upfront CapEx can be significant, but after a certain point, the model can become more cost-effective.
For example, over 5 years, the total cost of an on-prem license will be roughly ~2× the license fee (license + five years of maintenance). After the initial investment is amortized, ongoing costs are predictable, and you have an asset (the license) to show for it.
You also control infrastructure and can optimize those costs separately. Crucially, you decide if and when to upgrade – you’re not forced into costly upgrades on a vendor’s schedule, potentially stretching the value of your investment.
Cloud Subscription Cost Structure:
Subscription is a pure OpEx model – you pay a recurring fee each year or quarter. Contracts are typically 3 to 5 years. The subscription fee usually scales with some metric of usage or business size (number of FUEs, employees, or revenue bands).
Upfront discounting might make the first term attractive, but beware the renewal: often SAP’s initial quote for renewal includes 5–10% annual uplifts if not negotiated down. Over a similar 5-year span, you could end up paying an amount equivalent to or greater than the on-prem model, with no asset owned at the end.
In essence, the cloud model is financially attractive in year one (little upfront cost) but can become more expensive over a long horizon, especially if your usage grows. Your total cost will hinge less on the entry price and more on how well you control renewals and growth.
“In subscription models, total cost depends less on entry price and more on renewal discipline.” In other words, negotiating a great Year-1 price is only part of the battle – you must also negotiate price protections for the future. It’s wise to benchmark the subscription cost against an equivalent on-prem scenario (license + support + hosting) to see the break-even point over time.
Checklist: When evaluating and negotiating S/4HANA Cloud pricing, consider these actions:
- Request a detailed FUE breakdown: Understand exactly how SAP calculated your required FUEs or user counts. Know the assumed mix of user types and usage that underpin the quote – this transparency helps avoid overbuying capacity.
- Negotiate a renewal cap: Push for a clause capping subscription price increases (e.g. max 3% per year or tied to inflation) to prevent steep cost jumps at renewal. Also seek the right to reduce volume at renewal if your usage declines.
- Benchmark against on-prem: Model the 5- to 7-year total cost of the subscription deal versus purchasing licenses and running them yourself (including infrastructure and 22% support). This TCO comparison gives you leverage – if the subscription is much higher, ask SAP to justify the premium or adjust the price.
Deployment method has licensing implciations, Greenfield vs Brownfield Licensing Implications: How Implementation Approach Impacts S/4HANA Costs.
Flexibility and Customization Trade-Offs
One of the biggest non-financial differences is flexibility. An on-premises S/4HANA system is your environment to control. You can heavily customize the software (modify or extend SAP code, install add-ons, build Z-programs) to fit unique business processes.
You choose when to apply patches or upgrades, and you can freely integrate with third-party systems, even directly at the database level if needed. You also have the freedom to host the system wherever it makes sense – on your own data center, colocation, or on a cloud IaaS of your choice – and even switch hosting providers if needed.
This means on-prem gives maximum flexibility to align the system with your company’s specific needs and timeline.
By contrast, S/4HANA Cloud (especially the public cloud edition) operates on SAP’s standardized model. In the public SaaS, you receive quarterly releases and cannot delay them, as SAP updates your system on its schedule.
Custom code is very restricted; you’re expected to use only SAP’s provided extension mechanisms (which might not allow deep modifications). Even in the private cloud edition (RISE), where you have your own instance, SAP still controls the maintenance window and upgrade schedule (typically annual or biannual upgrades) that you must follow.
Certain customizations are allowed in private cloud, but you’re discouraged from heavy modifications since SAP must keep the environment supportable. Integrations are done through SAP-approved interfaces and APIs, not by direct database access.
Essentially, the cloud model forces you to adapt to SAP’s best practices and roadmap.
“Cloud aligns to SAP’s roadmap, not necessarily yours.” If your business requires significant custom developments or a unique upgrade cadence, the lack of flexibility in the cloud could be a serious limitation. Companies with heavily customized legacy SAP systems often find the public cloud edition too rigid for their needs. The trade-off for cloud’s simplicity is that you relinquish control over timing (upgrades), underlying infrastructure, and sometimes functional scope in exchange for a standardized, SAP-managed environment.
Support and Maintenance Considerations
With an on-prem license, support is optional (though recommended). Typically, customers purchase SAP’s support to get patches, updates, and helpdesk service – that’s the 22% annual maintenance fee.
However, you have options: if SAP’s support becomes too costly or you’re running a stable system, you can choose to switch to a third-party support provider or even go without support (not advisable for production, but it’s your choice).
Third-party providers (like Rimini Street, for example) may offer lower fees or more tailored support for older SAP versions, though you won’t get new SAP updates while on third-party support.
On-prem also allows negotiating maintenance terms with SAP – e.g., some customers negotiate caps on maintenance fee increases or get loyalty discounts, especially if they’ve been long-time customers or as part of contract negotiations.
In the cloud subscription, support is bundled and non-negotiable – it’s part of the service you’re paying for. You cannot unbundle support or use an alternate support provider, since SAP is running the system. The service comes with SAP’s standard SLAs (Service Level Agreements) for availability and issue resolution.
While SAP’s cloud support generally covers regular maintenance and problem resolution, enterprise customers might find that the responsiveness or flexibility isn’t always ideal. Critically, you have less leverage if support is lacking; you can’t threaten to take your support business elsewhere when you’re in SAP’s hosted environment.
Negotiation Tip: When entering a cloud contract (especially RISE with SAP), push for clear and measurable support SLAs. Ensure the contract defines key support metrics (like initial response time and resolution time for incidents) and consider adding penalty or credit clauses if service levels aren’t met.
SAP’s default cloud contracts can be vague on support quality, so make support expectations explicit in writing.
“If you’re forced into RISE, push SAP for transparent SLA metrics — especially incident resolution time.” Having these terms defined holds SAP accountable for keeping your system running smoothly, much like an internal IT team would be.
Exit Strategy and Contract Lock-In
A crucial consideration is what happens if you want to exit or change your licensing model down the road. With on-premise licenses, your exit risk is low: you own the software rights perpetually. If you decide to stop paying SAP’s maintenance, you don’t lose the ability to use S/4HANA – you simply won’t get new updates or official support.
You could continue running your system as-is for years if it meets your needs, or negotiate re-entry to SAP support later. You hold the cards in terms of timeline; there is no hard “end date” after which you must stop using the software.
Additionally, since the system is under your control, your data is on your databases and servers – you can access and extract your business data whenever needed, without needing SAP’s help or permission.
In a cloud subscription, contract end = cut-off. If you don’t renew, your access to the system is revoked when the term expires. SAP typically deprovisions the environment shortly after contract termination.
This creates significant lock-in pressure: as you approach the end of a 3- or 5-year term, you must either negotiate another term (often at new pricing) or risk business disruption.
Migrating away from S/4HANA Cloud (whether to on-premise or another vendor) is a major project that can’t be done overnight.
SAP knows this, which is why customers who are “all-in” on RISE have less leverage at renewal time. It’s essential to negotiate exit provisions upfront, when SAP is courting your business, rather than at the end when you have no alternatives ready.
Checklist: To avoid being handcuffed by a cloud contract, include these safeguards in your S/4HANA Cloud agreement:
- Advance renewal notice: A 90–120 day notice is required before the contract term ends, with no auto-renewal without explicit approval. This ensures you have time to evaluate options and prevents the contract from rolling over quietly on unfavorable terms.
- Data export assistance: Insist on a clause that gives you the right to export all your data in a usable format when the contract ends. SAP should provide support in extracting database and transaction data (and not charge an exorbitant fee for it). This prevents data hostage scenarios and smooths any transition.
- Post-termination grace period: Negotiate a short read-only access period (e.g. 60-90 days) after contract expiration. This allows your team to retrieve any last data and ensures continuity while you switch systems if there’s a gap. Even a brief grace period can be a lifesaver to avoid a hard cut-off.
These exit clauses protect you from the worst-case scenario of being entirely at SAP’s mercy at term end. In some cases, customers also negotiate a conversion option – the ability to convert the subscription into a perpetual license if they leave the cloud.
While not always granted, it’s worth discussing so that years of subscription fees aren’t sunk costs if you decide to bring the system back in-house.
Read more about the differences in licensing, S/4HANA vs ECC Licensing Differences: What Changes When You Migrate.
Audit and Compliance Exposure
Under the on-prem model, license compliance is largely your responsibility, but you have some breathing room in how it’s enforced. SAP typically conducts license audits (by requesting a USMM/LAW report or sending auditors) on a periodic cycle.
If you’re found out of compliance (e.g., more users than licensed or unlicensed use of a software engine), you’ll get an audit report, and a negotiation usually ensues.
There may be back maintenance or a license purchase required, but customers often negotiate terms or buy additional products as part of the settlement. Importantly, you can internally govern usage. For instance, you can proactively clean up inactive users, reduce usage before an official audit, and interpret license rules internally until an audit happens.
Audits are a headache, but they are also a negotiation event where you might have some flexibility (e.g., timing true-ups with new purchases or using old licenses to offset new metrics).
In the cloud model, the concept of an audit changes. Since SAP operates the environment, they have full visibility into your usage at all times. If your contract says you have 3,000 FUE and you start using the equivalent of 3,500 FUE, SAP will immediately know.
There’s little ambiguity or grace – the system and contract enforce the terms of use. Non-compliance in the cloud typically results in an automatic charge or requirement to upgrade your subscription.
For example, if you exceed a certain number of users or transactions allowed, the contract may stipulate that SAP can bill you for the overage or bump you into a higher subscription tier. Instead of an audit letter after the fact, you get a bill or a notification in real time.
This means no surprise audits (you won’t get an unexpected compliance bill in year 4 because everything is measured continuously), but it also means no wiggle room. You cannot quietly correct a compliance issue before SAP notices – they’ve already noticed.
In a way, it shifts the risk: on-prem, you might never be audited if you manage well, whereas in the cloud, you’re constantly “audited” by the system. Also, some license types like Indirect/Digital Access are handled differently: many RISE deals bundle digital access documents, simplifying that aspect of compliance.
However, any usage beyond what’s in the contract (be it users, storage, performance metrics, etc.) will immediately translate to a cost.
In summary, with cloud subscriptions, you trade the occasional audit drama for a constant, automated compliance meter.
As one expert put it, “Under Cloud, non-compliance costs appear instantly as invoice uplifts, not audit letters.” The best practice here is to thoroughly understand your cloud usage allowances and implement internal controls to monitor consumption, ensuring you’re never caught off guard by an overage charge.
Example Scenarios
To illustrate the commercial impact of these models, consider two real-world styled scenarios:
Scenario 1 – On-Premises License (Global Manufacturer): This company invested €12 million upfront in S/4HANA perpetual licenses for its worldwide operations. It pays about €2.6 million per year in SAP support (22% of license value) for updates and fixes. Over five years, their total spend (about €12M + €13M maintenance) will roughly equal the license cost twice over, but they own the licenses outright.
They’ve managed costs by negotiating maintenance terms, such as capping any support fee increases, and even moved their legacy ECC system to a third-party support provider to save on overall maintenance.
The on-prem model gives them full control to schedule upgrades on their timeline and customize the system as needed. If budget pressures rise, they might even suspend SAP maintenance while continuing to run the software internally.
Scenario 2 – Cloud Subscription (Global Retailer): This company migrated to RISE with SAP for S/4HANA, contracting for 3,000 FUEs (which covers their mix of heavy and light users). Their annual subscription cost is €5.5 million under a 5-year agreement (total commitment €27.5M). That fee includes all software, the SAP HANA database, cloud infrastructure on a hyperscaler, and SAP’s managed services. It allowed a fast rollout across international divisions with SAP handling the technical setup.
However, they had to accept SAP’s quarterly upgrade schedule and limit modifications to stay within the standard. Over the 5-year term, the retailer’s total cost is known, but as renewal approaches, they face an increase if they cannot reduce usage or negotiate a cap.
They also recognize that if they ever wanted to exit, they’d have to plan far in advance to avoid business disruption. The convenience of the subscription came with strict lock-in to SAP’s ecosystem and roadmap.
Outcome: In these scenarios, the on-premises model required a larger upfront expenditure but is likely to yield savings in the long run (especially beyond the initial several years) and offers greater flexibility.
The cloud subscription eliminated the upfront cost and simplified deployment, but over five years, the spend was comparable (or higher), and the company is fully dependent on SAP. The manufacturer with on-prem now has a long-term asset and options for support.
In contrast, the retailer must continually renew or replace their cloud agreement to keep the business running. It highlights the classic trade-off: on-premises can be more cost-effective and empowering over time, while cloud offers short-term ease at the cost of long-term agility.
5 Actions to Optimize Your S/4HANA Licensing Model
- Model total costs over 5–7 years, not just year one: Do a full TCO projection for each model. A subscription might look cheaper in year 1, but map out the costs over at least 5-7 years (including likely renewal increases) versus the one-time license + maintenance path. This long view prevents costly surprises.
- Negotiate renewal caps and exit rights upfront: Before signing any contract, secure limits on future price hikes (e.g., a cap on renewal increases) and clear exit provisions (advance notice, data extraction support, and transition assistance). Your leverage to get these terms is highest before you’re locked in.
- Document your customization needs and choose the model accordingly by taking an inventory of how much flexibility you need. If your business requires heavy customization or control, avoid the highly restrictive public cloud edition – a private cloud or on-premise might serve better. Match the model to your business requirements, not just SAP’s sales pitch.
- Compare current ECC costs to S/4HANA subscription offers: If you’re coming from SAP ECC, calculate what you currently spend on maintenance, infrastructure, and support. Then compare it to the proposed S/4HANA Cloud subscription fee. This baseline helps you evaluate if the cloud deal truly delivers value or if it’s just shifting costs around (or even increasing them).
- Secure data retention and “reversion” clauses in writing: In any cloud agreement, make sure you have a data retention plan – specify that you can get all your data back. Additionally, see if you can negotiate a license reversion clause (the option to convert to on-prem licenses if the cloud deal ends or fails). Having the ability to fall back to a perpetual license or at least retain your data and configurations protects you against worst-case scenarios.
By taking these actions, you can approach S/4HANA licensing strategically.
The goal is to maintain flexibility and cost control, whether you choose a subscription, perpetual, or hybrid model, and to avoid being trapped in a model that no longer suits your business in the future.
Read about our SAP Advisory Services
