If your organization is running — or planning to run — SAP systems on RISE with SAP, you’ve probably noticed something: the narrative from SAP makes it sound like Basis teams can kick back and relax. “SAP handles the infrastructure, the patching, the operations…” But anyone who’s actually worked with RISE knows the reality is more nuanced.
Full disclosure: RISE with SAP is essentially HEC (HANA Enterprise Cloud) on hyperscaler infrastructure (Azure, AWS, GCP), wrapped in a new commercial and operating model. The core ECS (Enterprise Cloud Services) engine hasn’t fundamentally changed — but your responsibilities have.
Table of Contents
1. SAP Still Manages the Infrastructure — But Your Basis Team Stays Busy
Let’s clear up the biggest misconception first. Yes, under RISE, SAP takes responsibility for OS patching, database management, backup and recovery, and system-level monitoring. But that doesn’t mean your Basis team has nothing to do.
As the RISE Roles and Responsibilities document makes clear, customers retain responsibility for:
- Transport management and RFC management
- User role administration and authorization
- System monitoring, memory management, sizing, and capacity planning
- Pre- and post-refresh activities
- Testing and validation of all patches (even SAP-applied ones)
- All non-critical security patching (CVSS below 8)
In fact, many experienced Basis teams report spending significant time coordinating with — and sometimes guiding — the junior RISE Basis engineers assigned to their account by the MSPs SAP contracts with. Your internal expertise doesn’t become obsolete. It becomes more strategic.
As I covered in my earlier post about RISE with SAP and the Evolution of the SAP BASIS Consultant, this shift from “doing” to “orchestrating” is the single biggest change for Basis teams moving to RISE.
2. The OSS Notes Library Is Your Survival Guide
One of the most valuable resources for managing SAP systems on RISE with SAP is the comprehensive collection of OSS notes maintained by SAP’s ECS team. These aren’t optional reading — they’re the operational manual for your RISE environment.
Here are the ones you absolutely need to bookmark:
| OSS Note | What It Covers | Priority |
|---|---|---|
| 3344326 | FAQ: Private Cloud Landscape (ECS Landscape) | ⭐ Critical |
| 3351928 | FAQ: ECS ABAP System User Management | ⭐ Critical |
| 3250501 | Mandatory Security Parameters for ABAP Systems in ECS | ⭐ Critical |
| 3480723 | Security Parameters for HANA Databases in ECS | ⭐ Critical |
| 3572444 | Standard Backup Policy for RISE Production Systems | 🔥 High |
| 2597323 | Transport Directory Between RISE and On-Premise TMS | 🔥 High |
| 3441135 | System Copy Service Request Handling for ECS | 🔥 High |
| 3286240 | Client Administrative Actions Restrictions | 🔥 High |
| 3517086 | Non-Security Parameters for ABAP in ECS | 📋 Medium |
| 3336611 | Standard Service Ports in ECS | 📋 Medium |
I recommend creating a dedicated folder in your SAP Notes viewer and subscribing to updates on these notes — especially the security ones (3250501, 3480723) which get updated regularly as SAP’s baseline evolves.
3. The RACI Triangle: Customer, SAP, Partner — You Need All Three
One of the most common failure points in RISE engagements is unclear ownership. The operating model creates a three-way accountability structure that works brilliantly when everyone knows their lane, and falls apart when they don’t.
The RACI breakdown for SAP systems on RISE with SAP:
- SAP is Accountable for the platform — infrastructure, uptime, managed services, and the software baseline.
- The Implementation Partner is Responsible for configuration, customization, data migration, and project delivery.
- The Customer (Your Team) is Accountable for business outcomes — process decisions, user adoption, organizational readiness, and ongoing governance.
This means your Basis team needs to operate as a cloud service manager, not a server administrator. You’re no longer patching the OS — but you’re accountable for ensuring the patches don’t break your critical business processes. You’re not managing the HANA database daily — but you own the performance governance and capacity planning.
As we discussed in the transition from SAP BASIS to Cloud Architect, this shift requires a fundamentally different mindset — one focused on orchestration, governance, and vendor management rather than hands-on technical execution.
4. Security Doesn’t Get Easier — It Gets Different
Here’s a hard truth: moving to RISE doesn’t make your SAP security posture simpler. It changes the threat model and shifts where you need to focus.
SAP’s ECS team applies a defined security baseline — documented in OSS notes 3250501 (ABAP) and 3480723 (HANA). But the customer remains responsible for:
- User administration and role design across the landscape
- Segregation of duties and GRC compliance
- Application-level security (authorizations, critical transactions)
- Secure configuration of interfaces and integrations
- Managing security for BTP extensions and side-by-side scenarios
- Ensuring compliance with your organization’s audit requirements
SAP applies critical security patches automatically, but only those that can be applied without manual intervention. Everything else — testing, non-critical patches, additional remediation — falls to your team.
This is why I included security as a major pillar in my SAP Security Audit Checklist: Complete Guide for BASIS Administrators. The fundamentals haven’t changed — you still need a robust security framework. What’s changed is how you implement it within the RISE boundaries.
5. Transports and System Copies Still Run Through Your Team
One of the biggest surprises for teams migrating to SAP systems on RISE with SAP is discovering that transport management doesn’t get handed over to SAP. Your Basis team still owns the transport chain — it just works differently now.
Key OSS note 2597323 covers transport directory setup between RISE and on-premise TMS landscapes. And note 3441135 details the system copy service request process — you submit a ticket to ECS, they handle the database copy, but your team handles all pre- and post-copy activities.
Similarly, client administration is restricted in ECS-managed systems (note 3286240). You can’t just create or delete clients at will. Understanding these limitations before you need them will save you a lot of frustrated ticket exchanges with SAP support.
For a deeper comparison of operational tools, check out my analysis of SAP Cloud ALM vs Solution Manager: 5 Critical Functions — because Cloud ALM is the operations backbone for RISE environments.
6. Backup, Monitoring, and Incident Response Require New Processes
Under RISE, SAP handles the standard backup policy (documented in OSS note 3572444), but you still need to:
- Understand the recovery point and time objectives (RPO/RTO) in your contract
- Test backups by requesting system refreshes through the ECS service request process
- Monitor application-level health — SAP monitors the infrastructure, but you monitor the business processes
- Define escalation paths for incidents that cross the boundary between your application and SAP’s managed layer
The incident management process also changes. You don’t SSH into the server anymore — you open a service request through SAP’s ECS portal (see note 3399927 for how to create cases). This means your troubleshooting skills need to shift from “fix it yourself” to “diagnose and describe accurately so SAP can fix it.”
For monitoring specifically, SAP Cloud ALM is the recommended platform, and note 3576114 covers a common issue — no systems showing in the RISE System View. Bookmark that one.
7. Your Career Path Expands — Not Contracts
I hear this concern all the time from Basis colleagues: “If SAP handles the infrastructure, what’s left for me?”
The answer, based on real experience from teams already in RISE: more than you think, and at a higher level.
As SAP systems on RISE with SAP become the norm, Basis professionals are evolving into:
- Cloud Platform Administrators — managing BTP subaccounts, entitlements, and connectivity
- Integration Architects — designing and governing the extension landscape
- Security and Compliance Managers — owning the application-layer security posture
- Vendor and Service Managers — coordinating SAP, hyperscalers, and internal teams
- Automation Engineers — building Terraform pipelines, Automation Pilot workflows, and CI/CD processes
This aligns with what we explored in the 4-Tier Roadmap: From SAP Basis Admin to Cloud Platform Administrator. The trajectory is clear — from system guardian to platform orchestrator.
Conclusion: Know What You’re Signing Up For
The biggest risk with SAP systems on RISE with SAP isn’t technical — it’s assuming that “managed by SAP” means “managed for you.” Your Basis team remains critical to the success of a RISE engagement. What changes is what you manage and how you manage it.
Start by bookmarking those OSS notes. Review the RACI boundaries with your team. And invest in the skills — cloud platform management, automation, security governance — that turn a RISE transition from a threat to your role into the biggest career opportunity in SAP right now.
What’s been your experience with SAP systems on RISE? Drop a comment below or connect with me to share your story.
