S/4HANA
ERP Strategy
RISE with SAP
A useful way to evaluate RISE is to stop thinking of it as "hosting" and start thinking of it as a managed service boundary plus a commercial packaging model.
In the common hyperscaler model, SAP is responsible for running and managing the cloud services required for the RISE landscape inside an account "managed by SAP," while customers can still run extensions in their own separate account. This matters because it changes the locus of control (and therefore the value proposition): you are paying for operational accountability and standardization, not just infrastructure.¹
One reason RISE business cases go sideways is that "bundled" is interpreted as "everything is covered." It is not. SAP's own Roles & Responsibilities (R&R) documentation for SAP S/4HANA Cloud, private edition makes clear that services fall into categories (standard, optional, packaged, additional) and that some tasks/services can be subject to additional fees and must be explicitly contracted.
The practical takeaway: In 2025, a credible RISE evaluation starts by translating your expectations into a line-item scope matrix against SAP's R&R and your contract supplements—before you compare TCO.
If your current reality is frequent "who owns the incident?" escalations between your SI, hosting provider, and internal Basis/security teams, RISE can reduce coordination cost because SAP runs the managed layer and is accountable within that boundary. This is not a soft benefit. In SAP operations, coordination failure is a real cost driver (downtime, delayed fixes, prolonged root-cause cycles).
RISE frequently accelerates decisions that organizations otherwise postpone: upgrade paths, lifecycle discipline, and operating model modernization. SAP's private cloud service specifications and documentation ecosystem make it easier to standardize roles, responsibilities, and service expectations at the platform layer.
The Signavio Starter Pack is conceptually valuable because it supports process understanding and redesign, two prerequisites for sustainable ERP value. However, the impact depends on whether the organization actually uses it as a continuous discipline rather than a one-time assessment.
If your key constraint is internal SAP operations capacity (Basis, security, patching, monitoring), pushing parts of that burden into a managed boundary can free internal capacity for higher-leverage transformation work—process standardization, data governance, and adoption.
RISE can simplify the platform responsibility boundary, but it does not eliminate the expensive work that dominates most ERP programs: scoping, fit-to-standard, data remediation, integration design, testing, and change adoption. If your biggest cost driver is discovery churn and late decision-making, the hosting model will not fix that by itself. Moreover, relying solely on a managed service to address deep-seated organizational or process inefficiencies is a common pitfall that can lead to unmet expectations regarding return on investment.²
In the AWS model, SAP manages the AWS services required to run the RISE landscape inside an AWS account "managed by SAP," while customers can use separate accounts for extensions. That structure can be a benefit (clear boundary) or a drawback (reduced autonomy), depending on your target cloud operating model.
SAP's R&R documentation explicitly frames that some tasks/services are not covered by standard services and may require additional fees and explicit contracting. This is the single most common source of budget surprises in RISE discussions: an assumption that a capability is "part of managed service," followed by a later realization that it is optional/packaged/additional.
Even when the annual run-rate looks reasonable, contract structure, renewal mechanics, and the operational realities of exiting a managed boundary should be evaluated explicitly.
Instead of asking "Is RISE cheaper?", ask: What risks and internal costs am I buying down, and what autonomy am I trading away?
To build a robust business case, begin by quantifying these key cost categories:
Next, on the benefits side, quantify these areas:
RISE is often worth it when:
RISE is often not worth it when:
In my opinion, RISE with SAP is worth it in 2025 when operational accountability, standardization, and reduced coordination costs are your primary constraints—and when you are willing to trade some autonomy for predictability within a managed boundary. It is less compelling when you already operate SAP efficiently and your biggest ROI lever is not hosting, but transformation execution: scoping quality, fit-to-standard discipline, data readiness, and adoption.
The best evaluations avoid ideology ("cloud good" vs "cloud bad") and instead produce a single-page decision artifact: a quantified TCO model plus a responsibility matrix that makes trade-offs explicit.
