Introduction: Why Deployment Model Is the Most Consequential Commercial Decision in S/4HANA

The choice of how to deploy SAP S/4HANA—cloud or on-premise, public or private, standardised or customised—is not a technical decision. It is almost entirely a commercial decision, and it will determine whether your total cost of ownership (TCO) over seven years looks like €2 million or €5 million.

Yet in most organisations, the deployment model is chosen for you. SAP's commercial advisory specialists guide prospects towards models that serve SAP's revenue targets, not your operational or financial reality. Account teams emphasise cloud adoption rates and standardisation benefits. They downplay on-premise licensing economics. They avoid mentioning programmes that might cost them a renewal. And they almost never surface the full scope of FUE (Full User Equivalent) conversion costs until contracts are nearly closed.

This playbook exists to reverse that imbalance. We examine all four viable deployment paths for S/4HANA: GROW with SAP (public cloud), RISE with SAP / SAP Cloud ERP Private Edition (managed cloud), on-premise perpetual licensing, and private cloud self-managed. We lay out their economics, constraints, and hidden costs. We expose the information asymmetry that SAP maintains. And we show you how to evaluate deployment models independently of vendor guidance.

The core insight is simple: deployment model choice is a lever that CIOs must own, because SAP will choose it for you if you let them—and you will pay for that convenience.

The Four Deployment Models: A Commercial Comparison Framework

SAP positions S/4HANA deployment options as a spectrum of flexibility and control. In reality, they are a commercial matrix where contract terms, licensing metrics, customisation scope, and mandatory change cycles lock you into profoundly different cost and capability profiles.

All four models can deliver functional S/4HANA. But their unit economics, upgrade cadence, and commercial sustainability are radically different. Choosing between them without a commercial framework is like choosing a vehicle based only on colour.

Dimension GROW (Public) RISE/Private Edition On-Premise Private Cloud (Self)
Implementation Time 8–12 weeks 6–12 months 9–18 months 8–14 months
Minimum FUE 30 35–40 None 30–50
User Cost (Annual) $180–300/user $150–280/user $300–600 (7-yr amortised) $200–350/user
Customisation Limited (Lite) Comprehensive Unlimited Comprehensive
Upgrade Cadence Quarterly (Mandatory) Controlled (Selective) Self-determined Self-determined
Support to Year N/A (Cloud) N/A (Cloud) 2040 (EHP 6–8) Version-specific

GROW with SAP: Fast, Standardised, and Cheaper—With Real Constraints

GROW with SAP is public cloud only. It is positioned as the fastest, simplest, and most cost-effective path to S/4HANA. In many respects, that positioning is accurate—but only for organisations willing to accept deep standardisation and accept quarterly upgrades as a fact of life rather than a choice.

Implementation and Time to Value

GROW implementations typically run 8–12 weeks for standard configurations. This is a genuine competitive advantage. Organisations that have deployed GROW report going live with a meaningful subset of enterprise finance functionality in a timeframe that would require only a quarter or two of project governance at an on-premise shop. The standardised data model, pre-configured processes, and SAP's deployment playbooks compress project risk and schedule.

This speed matters, particularly for smaller enterprises or those with limited ERP governance maturity. If your S/4HANA requirement is genuinely limited to "run the core GL and AR/AP on a cloud platform without massive customisation," GROW often makes that possible inside a single fiscal year.

Standardisation and Customisation Constraints

This speed is purchased with inflexibility. GROW operates in "Lite" customisation mode. This means you can configure standard SAP processes, but custom code, extensions, and process deviations outside SAP's codified scope are either prohibited or require special commercial arrangements.

For many organisations, this constraint is manageable. Finance processes in particular are standardisation-friendly: GL mapping, multi-entity consolidation, intercompany settlement, and statutory reporting have converged across industries. If your AR/AP workflows, inventory valuation, or GL hierarchies deviate significantly from SAP's standard, GROW forces a choice: re-engineer your process to fit the software, or accept limitations in functionality and reporting.

For organisations with deep process specialisation—pharmaceuticals requiring GMP-aligned lot tracking, aerospace requiring supplier scorecard integration, food manufacturers requiring allergen and origin controls—GROW is not a realistic option. You will find yourself building exception workflows outside the core system, defeating the purpose of deployment speed.

Quarterly Mandatory Upgrades

GROW operates on a quarterly upgrade cycle. These are not optional patch releases. They are mandatory migrations of your entire productive environment. SAP publishes the upgrade schedule; you do not negotiate timing around board meetings, year-end closes, or project deadlines.

The stated commitment is "zero downtime" and backward compatibility. In practice, every quarterly upgrade cycle introduces testing requirements, potential configuration drift, and the possibility of SAP-introduced behavioural changes that affect your processes. Forward-looking organisations budget for post-upgrade regression testing and variance investigation. Organisations that do not often find themselves discovering in October that September's mandatory upgrade introduced subtle GL posting sequence changes or report output formatting drift.

This forced upgrade cadence is the price you pay for SAP's scalability and security posture across the global GROW customer base. It also ensures that every GROW customer, regardless of industry or size, is running a release version that is never more than 90 days old. This homogeneity is valuable to SAP operationally; it is a trade-off for you.

Pricing and Minimum Commitments

GROW pricing is per-user, typically in the range of €160–270/user/month (roughly $180–300), depending on user type and geography. SAP requires a minimum commitment of 30 FUE. For a small organisation (50–60 total headcount), this translates to a floor of roughly €58,000–100,000 annually for the cloud platform alone.

This is genuinely cheaper than on-premise perpetual licensing for small deployments. For a 40-person service organisation that needs GL, AR/AP, and basic reporting, GROW often represents the lowest TCO path. The density of users per operational headcount is high, the process deviation is low, and the speed of deployment justifies the subscription model.

For larger organisations (500+ users), the per-user cost structure becomes less favourable when compared to on-premise volume pricing and negotiated perpetual licensing discounts.

RISE with SAP / SAP Cloud ERP Private Edition: What Is Changing in 2025

RISE with SAP was introduced as SAP's flagship managed cloud offering, positioning itself as a middle ground: cloud infrastructure and operations provided by SAP, but with greater customisation flexibility and controlled (rather than mandatory) upgrade cadence compared to GROW.

As of Q1 2025, RISE with SAP is being formally retired and rebranded. The successor is SAP Cloud ERP Private Edition, with significant implications for existing customers and new procurement decisions.

RISE History and 2024 Positioning

RISE with SAP launched in 2021 with typical contract terms of 5 years. It was marketed as an all-in-one cloud bundle: infrastructure, platform-as-a-service, implementation services, and ongoing managed operations. Minimum FUE commitments typically start at 35–40 users.

RISE pricing was structured to include not just the software licence (similar to GROW at €135–250/user/month) but also infrastructure, SAP's managed operations, and transition services. This bundling was attractive in theory: a single contract, a single vendor responsible for uptime, a single bill for the entire cloud stack.

In practice, RISE contracts introduced complexity. The bundled model obscured the actual cost of infrastructure (typically 20–30% of total bundled cost), the cost of operational support, and the incremental cost of customisation and extension development beyond the standard offering.

The 2025 Transition: RISE Discontinued, Cloud ERP Private Edition Launched

SAP announced in late 2024 that RISE with SAP branding would be discontinued from mid-2025. Two successor offerings exist:

This transition matters because it signals a strategic shift in SAP's commercial positioning. The retirement of RISE branding suggests that SAP is consolidating managed cloud offerings and reducing the number of distinct commercial SKUs in the market. For CIOs currently evaluating a RISE contract negotiation, it creates bargaining room: SAP wants to migrate customers to the new brand and is often willing to offer transition incentives.

Cloud ERP Private Edition: Specifications and Implications

SAP Cloud ERP Private Edition offers the following characteristics:

For organisations that found GROW too rigid and on-premise too operationally burdensome, Cloud ERP Private Edition offers a compromise. You get the operational simplicity of managed cloud (no infrastructure procurement, no data centre operations, patching handled by SAP) without forced upgrade cycles or standardisation constraints.

The cost of this compromise is that you must commit to multi-year contracts and you bear the full complexity of customisation governance and extension development. SAP operates the platform; you operate your processes.

On-Premise S/4HANA: The Path SAP Would Rather You Didn't Take

If GROW is SAP's velocity play and RISE/Cloud ERP Private Edition is SAP's flexibility play, on-premise S/4HANA is the path SAP economically discourages but still allows.

On-premise perpetual licensing exists because large enterprises with existing data centre operations, deep ERP governance, and specialised processes require it. It is not discontinued. But it is no longer SAP's commercial priority, and this is evident in how it is discussed, priced, and supported.

Perpetual Licensing Economics

On-premise S/4HANA perpetual licensing is priced per user (FUE-based) with no minimum user count and no mandatory subscription renewal. A perpetual licence grants you the right to operate that software version indefinitely, subject to maintenance and support agreements.

Published perpetual licensing rates are typically €3,600–7,200 per FUE (roughly $4,000–8,000). However, these are list prices, not market rates. Large enterprises with leverage regularly negotiate perpetual discounts of 40–60%, resulting in effective per-user costs of €1,440–4,320 ($1,600–4,800) per FUE.

Over a 7-year operating cycle, this translates to perpetual costs of roughly €200–620 per user per year (amortised), compared to €135–300 per user per month for cloud services. For a 200-user deployment, the comparison looks like this:

The perpetual path is cheaper. Not marginally cheaper—materially cheaper. A German logistics company was explicitly advised by their SAP account team that on-premise S/4HANA was "not the recommended path." When they commissioned independent evaluation, they discovered that on-premise perpetual licensing at negotiated rates produced a 7-year TCO approximately 28% lower than the RISE equivalent, with greater flexibility at renewal.

Perpetual Support and Maintenance Timeline

On-premise S/4HANA (Enhancement Pack 6–8) has mainstream maintenance support through December 31, 2027. This is not a forced upgrade deadline; it is the point at which SAP stops issuing security patches and critical fixes for free. Extended maintenance is available from 2028–2030 at an additional cost of approximately 2% uplift on annual licence value, covering roughly 24% of the licence cost.

This means that organisations deploying on-premise S/4HANA in 2026 have a legitimate operational runway to 2035 or beyond: 2 years of mainstream support (through 2027), 2 years of extended maintenance (2028–2030), and then the option to either upgrade to the next major version, migrate to a cloud offering, or continue operating with non-vendor support arrangements (available from third-party vendors at costs up to 50% below SAP maintenance).

This flexibility is a profound commercial advantage for large, stable enterprises. A multinational organisation with deep process customisation, mature change control, and the capacity to manage their own technology refresh can operate on-premise perpetually, deferring upgrade decisions until the business case for technology investment is clear.

Customisation and Control

On-premise licensing grants you complete control over customisation scope, upgrade timing, and platform extensions. You can extend ABAP code, integrate custom modules, and maintain process workflows that deviate indefinitely from standard SAP best practices. This is freedom and liability in equal measure.

Organisations with high customisation become operationally dependent on deep ERP expertise and carry the burden of managing technical debt. But they also maintain the ability to support unique competitive advantages through technology that cloud standardisation would eliminate.

FUE Conversion: The Hidden Cost That Hits Every Cloud Migration

The single largest financial shock in cloud migrations is FUE conversion. We address it separately because it affects all cloud models (GROW, RISE, Cloud ERP Private Edition, private cloud) and because SAP rarely surfaces it prominently in early commercial discussions.

What Is FUE and Why It Differs From Legacy Licensing

FUE is a metric that measures usage rights to S/4HANA and cloud applications. It categorises users into three bands:

Legacy SAP ECC licensing used named user licensing: you named a user, you licensed one seat per person. If a person accessed the system, they were a licensed user. Simple and administratively straightforward.

FUE is a capability-based metric. A user who only submits expenses (Employee level) counts as 0.25 FUE even though they are one person. A person who manages GL posting, GL reconciliation, and consolidation (Professional level) is 1.0 FUE. The metric allows SAP to price based on functional entitlement rather than headcount.

The Conversion Cost

In most organisations, FUE conversion results in a 30%+ increase in licensed user count compared to legacy naming conventions. Here is why:

For a 300-person organisation with 150 legacy named users, FUE conversion commonly results in 200–210 licensed users, an increase of 33–40% in licensed headcount and a commensurate increase in annual cloud fees.

Avoiding FUE Conversion Surprise

FUE conversion should be a line item in any cloud commercial evaluation. Before signing any agreement, demand that SAP or your implementation partner conduct a detailed FUE mapping of your current user population. Require them to provide the count of Professional, Limited Professional, and Employee users they anticipate licensing. And then stress-test that count by category:

This is not a technical exercise; it is a commercial one. The difference between 150 FUE and 200 FUE is €54,000–120,000 in annual cloud fees. That difference should be visible and negotiable before contract signature, not discovered at implementation kickoff.

The SAP ERP Private Edition Transition Option: The Option SAP Won't Volunteer

In Q1 2025, SAP launched a formal programme offering selected large enterprises a transitional option: extended ECC maintenance to 2033, rather than the standard 2027 retirement date.

This programme exists. It is called the SAP ERP Private Edition Transition Option. It is available only to select large enterprises (typically €9+ million annual SAP spend). But it is almost never volunteered by SAP account teams because it generates lower revenue than a RISE conversion.

Who Qualifies and How It Works

The programme allows large ECC customers to extend standard maintenance support from the baseline 2027 date to December 31, 2033, provided they commit to a specific roadmap. The roadmap typically includes targeted modernisation (moving finance to S/4HANA or a cloud application, while keeping other modules on extended ECC) or preparation for cloud migration on a defined timeline.

Pricing for extended maintenance is not published publicly. Typically, it involves a modest annual fee (often 5–10% of licence value) for each year of extension beyond 2027.

For a large enterprise with €13.5 million in annual ECC maintenance fees, extending to 2033 would cost roughly €6.75–13.5 million across six years (2027–2033), assuming flat maintenance costs. By comparison, a RISE conversion for the same user population might cost €36–54 million over a 5-year term.

The Transition Option is valuable precisely because SAP does not discuss it. If you are a large ECC customer being pressured by your SAP account team to accelerate S/4HANA migration or accept RISE contracts, asking directly whether you qualify for the Transition Option changes the negotiating dynamic. You are no longer choosing between cloud now (RISE) or cloud eventually (extended ECC followed by migration). You are choosing between a controlled, cost-managed extension programme and a vendor-accelerated migration.

Commercial Leverage

The existence of the Transition Option is important information. It is not information SAP volunteers. Large enterprises that ask for it directly often find their account teams initially deny it exists, then acknowledge it exists but claim it requires escalation, then eventually extend it with commercial concessions. This sequence happens because the programme is real but is managed as a special case rather than a standard offering.

If you are currently managing an ECC retirement decision and your organisation qualifies as "large" (typically >€4.5 million annual SAP spend, >1,800 named users), requesting information about the Transition Option in writing to your account team creates a paper trail. Even if they decline, you now have documented your request and their response, which becomes valuable context if you later engage independent advisors or legal support in commercial negotiations.

Private Cloud vs Public Cloud Licensing Mechanics

The distinction between public cloud (GROW, Cloud ERP Private Edition on AWS/Azure/GCP) and private cloud (Cloud ERP Private Edition on SAP-managed infrastructure or your own infrastructure) is more than architectural. It affects licensing, upgrade cadence, customisation scope, and pricing structure in material ways.

Public Cloud Characteristics

Public cloud deployment means your instance runs on shared multi-tenant infrastructure operated by AWS, Azure, or GCP, with SAP responsible for the application layer and cloud provider responsible for infrastructure. Characteristics include:

Public cloud scaling is linear with user count. Add 10 users, add 10 FUE, increase cost by €19,200–32,400/year. Public cloud is economically efficient for small and mid-sized deployments (50–200 users) because infrastructure cost per user is low and shared across a large customer base.

Private Cloud Characteristics

Private cloud deployment means your instance runs on dedicated infrastructure—either SAP's private cloud (hosted by SAP, but isolated to your organisation) or your own infrastructure (deployed, managed, and operated by you with SAP providing the software and technical support).

Private cloud characteristics include:

Economics: Private Cloud Costs More, But You Control More

The private cloud premium (30–50% higher TCO than public cloud) is often not fully understood before implementation. Organisations choose private cloud thinking they are optimising for customisation, but they do not always realise the infrastructure cost premium until they are deep in procurement.

The economics make sense if you have high customisation, complex integrations, or regulatory requirements (data residency, isolation) that require private deployment. For organisations with standard processes and modest customisation, private cloud adds cost without proportional benefit.

The Commercial Framework: How to Evaluate Deployment Models Independently

Evaluating deployment models should follow a disciplined commercial framework rather than vendor guidance. This framework should address economics, operational burden, flexibility, and risk.

Step 1: Define Your Total Cost of Ownership Time Horizon

All cost comparisons should use a consistent time horizon. We recommend 7 years, aligning with typical cloud contract terms (3–5 years) plus extension or renewal. For on-premise, 7 years aligns with perpetual licence cost amortisation and extends through the 2027–2030 extended maintenance window.

Step 2: Conduct a Detailed FUE Mapping

For any cloud evaluation, map your current ECC user population into FUE categories. Do not accept vendor estimates. Build a bottom-up list of every person who will access the system, categorise them (Professional / Limited Professional / Employee), and sum to FUE. Add 15–20% to account for business expansion over 7 years. This is your cloud user licensing baseline.

Step 3: Build Scenario Costs

For each deployment model you are evaluating, build a full 7-year cost scenario including:

Build scenarios for each model with realistic assumptions for your organisation. This should produce 7-year TCO estimates for each path.

Step 4: Sensitivity Analysis on FUE and User Growth

Cloud costs scale linearly with FUE. Run sensitivity analysis: if your FUE estimate is off by 15% (common in early estimates), what does that cost? If user growth runs 5%/year instead of 3%, how does that affect 7-year costs? Identify which cost drivers are most sensitive to your assumptions.

Step 5: Evaluate Non-Cost Factors

Cost is not the only factor. Also evaluate:

Negotiation Timing and the SAP Fiscal Year

SAP's fiscal year ends September 30. Q4 (July–September) is when SAP pushes for contract signature to close the fiscal year. This is leverage for you.

Large deals started in Q1 or Q2 but not closed by end of Q3 face pressure to close in Q4 (often with commercial concessions) or be rescheduled to the next fiscal year. This creates windows of negotiating leverage:

If you are in active negotiation with SAP for a large contract, understanding their fiscal calendar creates negotiation timing. Asking for extended evaluation period in Q1–Q3 is defensible; asking for it in August is less defensible (from SAP's perspective) because of fiscal year pressure.

Conclusion: Deployment Model as a Strategic Lever

The choice of how to deploy S/4HANA—cloud or on-premise, public or private, GROW or RISE or perpetual—is not a technical decision. It is a commercial decision that determines whether your 7-year TCO is €2.25 million or €4.95 million, whether you maintain control over upgrade timing, and whether you can sustain competitive advantage through process specialisation.

SAP has powerful incentives to guide that choice towards managed cloud offerings, which generate recurring revenue and limit your exit options. Those incentives are not aligned with your cost management or operational flexibility.

The antidote is disciplined commercial analysis independent of vendor guidance. Build a detailed FUE map. Run scenario costs across all four deployment models. Evaluate non-cost factors honestly. Understand the leverage points in SAP's calendar. And recognise that the information SAP will not volunteer—the Transition Option, the 50%+ perpetual licensing discounts, the FUE conversion shock—is often the most valuable information in the negotiation.

CIOs who choose their deployment model independently, armed with financial analysis and commercial framework, pay SAP's costs rather than SAP's preferred margin. Those who allow SAP to choose for them pay the difference.