Key takeaways
|
TABLE OF CONTENTS
- What RISE with SAP monitoring covers, and what it leaves to you
- The black box problem: what you lose access to
- SAP Cloud ALM vs. purpose-built SAP monitoring
- Seven monitoring strategies for RISE with SAP
- SLA verification: proving the 99.7% number
- Integration monitoring across Cloud ERP and BTP
- How Avantra closes the visibility gap
- Frequently asked questions
Moving to RISE with SAP Private Cloud does not reduce your operational responsibility. It changes where the visibility gap sits. Your team still owns the application layer, configuration, performance tuning, custom code, and compliance. You lose direct access to OS logs, database consoles, and infrastructure diagnostics. When something breaks, you file a ticket and wait.
For teams mid-transition, the gap doubles. You run traditional ERP and Cloud ERP side by side for a year at minimum, often longer for complex estates. Two toolsets. Two escalation paths. No single view of the SAP estate at the exact moment you need one most.
| “We had thousands of performance tickets a year. With Avantra, business users could self-check. We saved Basis time and eliminated entire ticket categories.”
Darko Rozac, Principal Software Architect, Shutterfly. Read the Shutterfly case study |
What RISE with SAP monitoring covers, and what it leaves to you
The appeal of Cloud ERP centres on a fully managed service with less day-to-day technical work for your team. Private Cloud ERP works differently. It is a hybrid model. Customers keep significant operational responsibility at the Basis and business application layers while giving up hardware access.
Patching schedules, custom code monitoring, interface health, and compliance evidence stay with you. The split between what SAP manages and what you manage is documented, but the document runs past 50 pages of spreadsheet. Many teams read it only after the first incident.
Several organisations add Basis headcount during the transition rather than reducing it. The work does not disappear. It changes shape.
Responsibility split at a glance
| Layer | SAP manages (Private Cloud) | You manage |
|---|---|---|
| Hardware, storage, network | Full ownership, covered by infrastructure SLA | No access, no telemetry |
| Operating system | Patching and availability | No shell access, no OS-level metrics |
| Database (HANA) | Backup, base availability | Query performance, growth, application impact |
| SAP Basis layer | Kernel and release baselines | System parameters, transports, jobs, users |
| Application and custom code | Nothing | Configuration, ABAP, performance tuning, testing |
| Interfaces and business processes | Nothing by default | IDocs, RFCs, queues, batch chains, SLA evidence |
Deciding between deployment models first? Compare the options in S/4HANA or RISE with SAP before you commit to an operating model.
The black box problem: what you lose access to
You keep the ABAP layer. SM37 for background jobs, ST22 for dumps, SM21 for the system log, SM12 for lock entries, SM58 and SMQ1 or SMQ2 for queues, WE02 for IDocs, ST03N for workload. Those transactions still open.
What disappears is everything beneath them:
- OS shell access. No sapcontrol from the command line, no trace file inspection under /usr/sap, no live process view.
- Database administration. HANA cockpit and DBACOCKPIT rights are restricted, so expensive statement traces and index analysis need a ticket.
- Infrastructure telemetry. Storage latency, hypervisor contention, and network path metrics sit with the provider.
- Correlation. ST06 style OS data no longer lines up with your application metrics, so you cannot tie a slow dialog step to a noisy neighbour or a storage event.
The result is a diagnostic dead end. A dialog response time doubles, ST03N confirms it, and the next step is a support ticket with no evidence attached. Teams report investigation cycles stretching from hours into days on performance and interface issues, purely because root cause analysis stops at the application boundary.
Some incidents resolve as infrastructure or network faults inside the managed estate. Customers had no way to detect those faults or prove them. Setting support expectations early matters. Investing in application-layer observability matters more.
Related reading: agent-based vs. agentless SAP monitoring explains which collection method fits restricted environments.
SAP Cloud ALM vs. purpose-built SAP monitoring
Cloud ALM is included with your subscription and covers standard Cloud ERP health well: SAP-delivered scenarios, business process monitoring, and integration tracking for clean, greenfield implementations. It’s the right starting point for a tenant with little custom code and few external systems to account for.
Coverage naturally narrows as the estate gets more complex. Cloud ALM is built around the SAP-delivered scope, so hybrid landscapes carrying legacy on-premises systems, non-SAP databases (Oracle, SQL Server, SQL Anywhere), heavy custom ABAP or Z-code, and multi-year migrations typically need it complemented with purpose-built SAP monitoring — for automated daily checks with pass/fail evidence, custom-code checks, automated remediation, application-layer SLA evidence for the business, a single hybrid pane of glass across cloud and on-premises, and native ITSM workflows like ServiceNow.
Teams running a mixed estate through a transition generally run both together: Cloud ALM for the Cloud ERP core, and a broader platform for everything Cloud ALM’s scope doesn’t reach.
Seven monitoring strategies for RISE with SAP
Use these seven strategies as the operating model for Cloud ERP observability. Each one addresses a specific consequence of losing infrastructure access.
- Monitor at the application layer with SAP-native checks. Batch jobs, dumps, locks, update errors, and queue depth are visible through the ABAP layer. Automate their collection instead of running transactions by hand each morning.
- Establish a baseline before the migration. Capture response times, job runtimes, and interface volumes on the current systems. Without a baseline, post-migration complaints turn into opinion.
- Verify SLA compliance independently. Measure availability from the application layer on your own schedule. Bring evidence to the provider rather than a description of symptoms.
- Track integrations separately from the core system. IDocs, RFC destinations, queues, and BTP services fail independently of ERP availability. Monitor each endpoint with its own thresholds.
- Automate configuration drift detection. Provider-side changes and transport activity alter system parameters over time. Automated comparison against a known-good state catches drift before it produces an incident.
- Run one platform across cloud and on-premises. Two toolsets during a transition means two alert streams and no correlation. A single platform preserves continuity through the whole programme.
- Automate daily checks and free the Basis team. Manual health checks consume hours per day per engineer. Automation converts that time into migration work and cuts detection time on real faults.
Point four matters more than teams expect. See monitoring SAP hybrid cloud deployments and the challenges of SAP’s hybrid ERP world for the operational detail.
What to monitor at the application layer
| Object | What to watch | Why it matters in Cloud ERP |
|---|---|---|
| Batch jobs (SM37) | Failures, runtime drift, chain dependencies | Job overruns hit period close with no OS view to explain them |
| IDocs (WE02) | Stuck statuses, backlog growth, partner errors | Interface failures are invisible in infrastructure SLAs |
| RFC and queues (SM58, SMQ1) | Connection errors, queue depth, retries | Cross-system calls break during provider maintenance windows |
| Dumps and system log (ST22, SM21) | Frequency, new patterns after transports | Earliest signal of a change-related fault |
| Custom code | Runtime of Z-programs, expensive statements | Fully your responsibility, outside SAP scope |
| Business process availability | End-to-end transaction success | Answers “can we do business today” better than uptime |
SLA verification: proving the 99.7% number
Private Cloud ERP offers a standard SLA around 99.7% and enhanced options with higher targets and faster response commitments. Both apply to the managed infrastructure layer: hardware, virtualisation, and network services.
Neither extends to the SAP application layer unless you contract Cloud Application Services separately. Business processes, configuration, and custom developments sit outside the number.
A system reporting 99.7% infrastructure availability still delivers a failed month end if the payment run aborts twice. Measure what the business feels. Report availability at the process level, hold your own timestamps, and use them in service reviews.
For SLA design guidance, read setting the right SAP SLA to ensure business continuity.
Integration monitoring across Cloud ERP and BTP
SAP systems rarely run alone. Warehouse platforms, banking interfaces, tax engines, CRM, and BTP services all exchange data with ERP. Those dependencies survive the move to Cloud ERP unchanged, and the oversight requirement survives with them.
Monitor each interface as a first-class object with its own thresholds: message volume against expected range, error rate, latency, and certificate expiry. An interface degrading quietly for three days costs more than an outage detected in ten minutes.
How Avantra closes the visibility gap
Avantra is purpose-built for SAP operations, not a generic APM tool pointed at an SAP system. Agent-based and agentless deployment options both work in Cloud ERP Private and hybrid scenarios, so security and access constraints do not block observability.
- Deep application-layer visibility into batch jobs, IDocs, RFCs, and custom development without infrastructure-level access.
- Automated daily checks replacing manual transaction rounds, with pass or fail evidence retained for audit and service reviews.
- Configuration drift detection with automatic alerting, keeping monitoring consistent as systems change.
- Intelligent alerting and root cause analysis at the application layer, so tickets to the provider carry evidence rather than symptoms.
- ServiceNow integration through certified connectors, routing alerts into existing incident workflows.
- One platform across on-premises and cloud estates, giving Basis teams operational transparency through the entire transition.
Teams running Cloud ERP alongside legacy systems typically start with the Avantra Cloud Edition for RISE with SAP or the Avantra Observability Edition. Estates needing automated remediation and enterprise workflows move to the Avantra Enterprise Edition. See how the pieces fit on the RISE with SAP and Avantra page, or review SAP system monitoring automation.
Frequently asked questions
What monitoring can customers actually do in RISE with SAP Private Cloud?
You monitor everything at and above the SAP application layer: batch jobs, IDocs, RFC destinations, queues, dumps, system logs, custom code runtime, user activity, and business process availability. Operating system shells, database consoles, and infrastructure telemetry stay with the provider, so application-layer tooling carries the full diagnostic load.
What does SAP manage vs. what remains the customer’s responsibility?
SAP manages hardware, virtualisation, network, operating system patching, and base database availability under the infrastructure SLA. You keep system health, performance tuning, configuration, transports, custom developments, interface monitoring, and compliance evidence at the Basis and application layers.
How is RISE with SAP monitoring different from on-premises SAP monitoring?
On-premises, application metrics and OS or database metrics correlate in one view, so root cause analysis runs end to end. In Private Cloud ERP the lower layers are abstracted away. Monitoring shifts to application-layer signals plus independent SLA verification, and unresolved issues escalate through support tickets rather than direct investigation.
Can SAP Cloud ALM replace third-party monitoring tools for Private Cloud?
For a greenfield Cloud ERP tenant with little custom code and few external interfaces, Cloud ALM covers standard monitoring. Hybrid estates with legacy SAP systems, non-SAP databases, heavy custom code, or complex integration chains need broader coverage, automated daily checks, and remediation Cloud ALM does not provide.
What happens when there is a performance issue and my team cannot access the infrastructure?
You isolate the problem at the application layer first: workload analysis, job runtimes, lock waits, queue depth, and expensive statements. Then you raise a ticket with timestamps and evidence attached. Teams with automated application-layer monitoring resolve or correctly escalate faster because they arrive with data instead of a description.
What integrations need to be monitored in a RISE with SAP environment?
Monitor every interface leaving the ERP system: IDoc partners, RFC destinations, qRFC and tRFC queues, BTP services, cloud connector links, banking and tax interfaces, and non-SAP applications exchanging data. Track message volume, error rate, latency, and certificate expiry for each one.
Does the 99.7% Cloud ERP SLA cover my business processes?
No. The standard SLA of approximately 99.7% covers the underlying hardware, virtualisation, and network services. Application-layer availability, business processes, and custom developments fall outside it unless you contract Cloud Application Services options. Verify process availability independently.
Why do some organisations need more Basis staff during a Cloud ERP transition?
Basis teams run two environments at once, learn a new toolset for Cloud ERP, and keep the existing on-premises estate running, all without a single point of control. Responsibilities treated as included in standard cloud services remain customer-owned in Private Cloud ERP. Automating daily checks is the fastest way to reduce the load.
Trust, but verify
Cloud ERP delivers scalability and a faster innovation cycle. The value holds only while the system stays available to the business. Availability at the infrastructure layer is the provider’s promise. Availability at the application layer is your evidence to produce.
Talk to an Avantra expert about monitoring your Cloud ERP and on-premises SAP systems from one platform, or explore the Avantra platform. Book a demo.