{{item.videoDuration}}
{{item.title}}
{{item.text}}
{{item.videoDuration}}
{{item.text}}
Key takeaways:
- RISE with SAP standardizes the platform layer, but it doesn't remove your operational responsibility — it relocates and helps reshape it.
- SAP's own roles and responsibilities documentation draws an explicit line between what SAP manages and what's “excluded” — and excluded tasks include business-critical work like authorization management and in-depth application support.
- Budget overruns on SAP S/4HANA and RISE with SAP programs are common, and most of the overage traces to this exact gap, not to the platform subscription itself.
RISE with SAP is marketed, reasonably, as a simplification. One subscription. One SLA. SAP manages the infrastructure, the hyperscaler relationship, the operating system, and a defined catalog of standardized cloud services. For organizations tired of running their own data centers and patch schedules, that's a genuine improvement.
But “simplified platform” and “reduced responsibility” are not the same idea. That distinction often becomes clear in the first year after go-live.
RISE with SAP creates a shared operating model
It's tempting to think of RISE with SAP as a two-party arrangement: It's easy to assume SAP owns the technical operations while the customer simply uses the system. SAP owns the platform — data centers, hyperscaler management, OS and database administration at the infrastructure layer. You own the business — strategy, process ownership, master data governance, and decisions about what gets built. And in between sits a third lane that SAP's own roles and responsibilities (R&R) documentation calls out explicitly: anything outside SAP's packaged services is an excluded task, and excluded tasks belong to the customer — directly, or through a partner.
That third lane is broader than many organizations expect going in. Authorization management, in-depth application support, interface monitoring and data-backup validation aren't edge cases — they're the day-to-day work of keeping a modern SAP landscape healthy.
Cloud doesn't remove the requirement for skills
A common assumption with any “as-a-service” move is that the skills requirement shrinks along with the infrastructure footprint. It doesn't. You still need BASIS, ABAP, HANA DBA, functional, and security expertise — arguably more of it, because the release cadence for RISE with SAP environments (feature pack stacks, support pack stacks, version upgrades) is faster and more continuous than the annual or biennial cycles many organizations built their legacy support models around. Each release demands regression testing and adoption work just to keep the environment stable, before anyone gets to the business value the release was supposed to unlock. Our piece on smarter release management for enterprise platforms covers this exact challenge in more depth.
Why post-go-live costs are often underestimated
This helps explain why cost overruns on SAP S/4HANA and RISE with SAP programs are so common. In PwC's experience, a large share of SAP S/4HANA customers exceed their original budget, with the bulk of that overage sitting in unplanned application-layer work rather than the platform subscription itself. The infrastructure cost is fixed and known upfront. The operational cost of the excluded-tasks lane is the part organizations chronically underestimate, because it doesn't show up until the first major incident, the first feature pack stack, or the first audit finding on access controls.
RISE with SAP changes who manages the data center. It doesn't change who owns the operating model that keeps the application, security, integration and release responsibilities running.
What a well-designed post-go-live model looks like
None of this is an argument against RISE with SAP — the platform consolidation is real and valuable. It's an argument for treating the operational lane as seriously as the platform decision. In practice, that means:
- A single accountable owner for the excluded-tasks scope — not a patchwork of SAP, an integrator, and an internal team each pointing at the boundary line when something breaks.
- A scope built directly against SAP's R&R document, so there's no ambiguity about what's covered and what isn't.
- Release governance as a standing capability, not a project sprint — because in a RISE with SAP environment, the next release is always close.
- Skilled hands that don't disappear once the migration project team rolls off. The specialists who understood the landscape during cutover are often needed also for interface monitoring and access reviews six months later.
This is the territory PwC's Application Evolution Managed Services is built around, and it's the same underlying argument behind why SAP managed services should evolve beyond traditional AMS: an operating model should be judged by whether it maintains platform stability while enabling continuous improvement — not just by whether tickets get closed. RISE with SAP changes who manages the data center. Customers still need a clear operating model for the application, security, integration, and release responsibilities that remain outside SAP's packaged services.
Our cloud ambassador managed service aims to provide additional resource coverage, fixed fee, to augment the RISE with SAP subscription, provide dual governance, and assume the client-side responsibilities. For more on how PwC structures accountability across the SAP landscape — and how our cloud ambassador service can help you with RISE with SAP governance, staffing and coordination — see our SAP alliance page.
Learn how PwC closes the SAP gap
Stay accountable. Stay staffed. Stay in control.
{{filterContent.facetedTitle}}
{{contentList.loadingText}}
{{contentList.loadingText}}
Follow us
