You have system access. You may or may not have documentation. The previous Basis engineer left either last month or three years ago, and what they documented either does not exist or describes a landscape that has drifted significantly from the current reality. The business knows the system is running. They do not know how it runs, and neither, yet, do you.
This is the standard starting position for anyone taking over an existing SAP landscape. The guidance in this article is for that situation: how to orient yourself quickly, what to look at before touching anything, how to set up monitoring that actually reflects this specific environment rather than a generic SAP template, and what the realistic timeline is for getting from “just got access” to “genuinely understand what is happening here.”
The advice is sequenced in the order it matters. Resist the temptation to skip to the monitoring configuration section. The configuration is only useful after you understand what you are monitoring.
What you actually inherit when you take over a running SAP landscape ?
The documentation problem
Every SAP environment has documentation. Almost none of it is current. The runbook describing the backup procedure was written when the system ran on a different server. The interface inventory lists six connections to an external ERP system that was decommissioned two years ago while omitting the four connections to the logistics platform that were added last year. The monitoring threshold configuration guide describes thresholds from the initial go-live that were adjusted during the first stabilization period and never updated.
This is not negligence. It is the normal state of a production system that has been running and evolving for years. Documentation is updated during projects and during incidents. Between those events, the system changes and the documentation does not.
The implication for onboarding is that you cannot trust existing documentation as an accurate picture of the current state. You can use it as a starting point for investigation: if the documentation says there are RFC connections to three external systems, go verify that those connections exist and are active, and look for RFC connections to systems not mentioned in the documentation.
Why the first task is discovery, not configuration
The instinct on arriving at a new SAP environment is to get monitoring configured quickly, to show visible progress, and to have something in place before the first incident. That instinct is understandable and worth resisting for the first few days.
Monitoring configured before you understand the environment generates alerts you cannot interpret. An alert fires at 03:00 saying dialog work process utilization is at 87%. Is that normal for this system during the overnight batch window? Is it abnormal but has been happening for months without anyone noticing? Is it genuinely new behavior caused by a recent change? Without baseline knowledge of this specific system, you cannot answer any of those questions. You have an alert with no context.
The first two to three days spent reading the system rather than configuring it produce the context that makes subsequent monitoring meaningful. Transactions run read-only. No changes. Just observation.
The first 48 hours: reading the system before touching it
Transactions that give you a health snapshot
These are the transactions to work through in the first hours of access. They do not require any configuration. They show the current health state and recent history of the system.
ST22 is the short dump monitor. Open it and look at the last seven days in production. A healthy production system has few or no short dumps per day. What you find here tells you immediately whether there are recurring program errors that the previous team was dealing with, and how frequently. Pay attention to the dump class distribution: MEMORY_NO_MORE_PAGING suggests memory pressure, TIME_OUT suggests programs running too long, DBIF_RSQL_INVALID_RSQL suggests data inconsistencies. Each class points to a different part of the system.
SM13 is the update monitor. Any failed update requests here represent saved transactions whose database writes did not complete. If there are entries in error status, find out whether they are being managed or whether they have been accumulating silently. A list of 400 failed update requests in SM13 that nobody has addressed is a data integrity situation, not a routine operational item.
SM12 shows the lock table. Scan for entries that have been held for more than a few minutes. Long-held locks in a production OLTP system indicate either a user who started a transaction and left it open, or a batch job holding locks across a long processing sequence. Neither causes an immediate incident but both create risk under concurrent load.
SM37 is the background job monitor. Look at the last 48 hours of job history in production, filtered for ABORTED and CANCELLED statuses. You want to understand which jobs fail regularly and which failures are genuinely new. A job that has been failing every other day for six months is a known condition. A job that failed for the first time yesterday is something different.
BD87 or WE05 shows IDoc status. Filter for error statuses in the last seven days. Any significant volume of errors in status 51 (error posting) indicates either a systematic data quality issue in an inbound interface or a configuration problem that has been producing failures.
SM21 is the system log. Open it for the last 24 hours in production and scan for work process terminations, memory overflow events, and roll file events. These system-level events are often the missing context for performance issues that users have been reporting.
Understanding what normal looks like in this environment specifically
After the health snapshot transactions, spend time in the workload monitor. In newer systems this is accessible via /SDF/MON or the performance overview; in older systems via ST07 or the workload analysis. Look at the last two weeks of dialog response time data and try to identify the pattern: when is peak load, when is batch-heavy, when is the system quietest.
Look at the HANA memory trend in HANA Studio or in whatever monitoring access you have been given. What is the current utilization against the allocation limit? What does the trend look like? A system at 70% utilization that has been growing 2% per month is a different situation from one that has been stable at 70% for two years.
The goal of this reading phase is not to produce a report or a risk assessment. It is to develop intuition about what this system normally looks like, so that when you start receiving monitoring data, you can distinguish expected behavior from genuine anomalies. That intuition cannot be transferred from a previous role. It is specific to this system.
| In practice: Ask specifically about month-end. Every SAP environment has a month-end processing pattern that is significantly different from daily operations: more batch jobs, longer runtimes, higher HANA memory utilization, different interface volumes. If you onboard in the middle of the month, your baseline observation does not include month-end behavior. Make sure someone tells you what to expect, and build time into your first month to observe the real month-end pattern rather than treating it as an anomaly. |
Setting up a monitoring user without undermining authorization controls
What authorizations a monitoring user actually needs
A SAP monitoring user needs read access to the system views and transactions that collect performance data. It does not need authorization to change anything. The distinction matters because authorization profiles that grant change access alongside read access create compliance problems in regulated environments and expose the monitoring connection as an attack surface if the credentials are compromised.
The core authorization objects for ABAP-layer monitoring are S_RFC for RFC access (the monitoring tool connects via RFC), S_TCODE for access to the relevant transactions (SM50, SM66, SM37, SM12, SM13, SM21, ST22, and others depending on the tool), and S_ADMI_FCD for system administration functions used by monitoring. For HANA-layer monitoring, a separate database user with MONITORING and CATALOG READ system privileges is sufficient for most metric collection needs.
Most monitoring tools provide a technical user setup guide that specifies the exact authorization objects and values required. Use that guide rather than building authorizations manually from scratch. Where it does not exist, ask the vendor before provisioning. The answer “just use SAP_ALL for the monitoring user” from anyone is a sign to push back.
The SAP_ALL temptation and why it creates problems you do not want
Provisioning the monitoring user with SAP_ALL is the path of least resistance during setup. No authorization errors during testing, no back-and-forth with the security team over missing object values, no delays. The monitoring tool connects, data starts flowing, setup appears complete.
The problems come later. In a regulated environment, SAP_ALL on a service account fails audit reviews and requires remediation under time pressure. If the monitoring platform is ever compromised, the monitoring user credentials provide unrestricted system access. When the security team runs an authorization report and finds a service account with SAP_ALL, the question of why it was set up that way requires an answer that does not exist in any change request.
The correct approach takes more time upfront. It requires identifying the minimal required authorizations, creating a custom role, testing it against the monitoring tool’s connection requirements, and adjusting where the tool reports authorization failures. In most monitoring tools, this process takes two to three hours. The authorization profile created is maintainable, auditable, and does not create downstream problems.
| Watch out: Authorization testing for a monitoring user should be done in a development or QA system first, not in production. An incorrect authorization setup that causes the monitoring connection to generate RFC authorization errors in production creates noise in SM21 and may trigger security alerts in environments with active SIEM monitoring. Get the profile right before connecting to production. |
Connecting your monitoring platform: what the initial setup actually requires
RFC destination setup and what to verify before going further
Most SAP monitoring platforms connect via RFC, creating an RFC destination of type 3 (ABAP connection) in SM59 on the monitored system, or connecting inbound from the monitoring collector via an RFC-enabled function module interface. The setup procedure varies by platform but the verification steps are consistent.
After creating the RFC destination or configuring the monitoring connection, verify three things before assuming setup is complete. First, run the connection test in SM59 and confirm it succeeds. Second, run the authorization test in SM59 and confirm the monitoring user has access. Third, and this is the one most setup guides omit: verify that data is actually being collected by opening the monitoring platform’s dashboard and confirming that metrics are appearing and updating at the expected interval. A connection test passing and data actually flowing are not the same thing. They fail independently.
In HANA environments, the HANA monitoring connection is separate from the ABAP connection and uses the HANA database user credentials rather than SAP user credentials. Both connections need to be set up and verified independently. A monitoring platform that shows green for the ABAP connection but has never successfully connected to HANA is not monitoring the most critical performance layer in an S/4HANA environment.
The difference between connected and actually monitored
A monitoring platform with a working connection to the SAP system is not the same as a monitoring platform that is providing useful coverage. The connection is the prerequisite. What determines whether monitoring is useful is the configuration that follows: which metrics are being collected, at what frequency, with what alert thresholds, and routed to which people.
In the first week, the monitoring platform should be collecting data and you should be reading it to understand what it shows about the system you just learned about through the health snapshot transactions. It should not be configured to alert yet, because you do not have the baseline data needed to set meaningful thresholds. Alerts configured in the first week without a baseline are threshold-based guesses, and threshold-based guesses produce either too many alerts (operations team starts ignoring them) or too few (the monitoring catches nothing).
The transition from connected-and-collecting to actively-alerting happens after two to four weeks of baseline data, which is covered in the section on baselines. The interim period is not wasted time. It is the period where you learn what the system looks like under normal conditions, so that abnormal conditions become visible.
Rebuilding the documentation you needed but did not receive
Interface inventory from the system itself
If the interface inventory documentation does not exist or is out of date, the system itself contains the authoritative record. SM59 lists all RFC destinations configured on the system. WE20 lists all IDoc partner profiles. BD54 shows the logical systems configured for ALE. SMQ1 and SMQ2 show the active qRFC queues. The ICM monitor shows active HTTP connections.
Building an interface inventory from these transaction views takes a few hours but produces something more reliable than any documentation written more than six months ago: a picture of what connections actually exist and which ones are currently active. An RFC destination in SM59 that was last used three years ago and shows errors on the connection test is a candidate for decommissioning. An RFC destination not mentioned in any documentation but showing high daily usage in the statistics is an undocumented dependency worth understanding before it fails.
The inventory does not need to be exhaustive on day one. Prioritize interfaces that carry business-critical data: order processing interfaces, financial posting interfaces, logistics execution connections. These are the ones where a failure has an immediate business impact, and they are the ones worth understanding deeply rather than documenting in passing.
Job schedule documentation from SM37 history
SM37 with a date range of 30 days in production and no filter on user or job name gives you a complete picture of what has actually been running. Export this to a spreadsheet if the volume is large. Group by job name. For each job, record the average runtime, the success rate, the scheduled frequency, and the last execution date.
This exercise typically reveals three things that the documentation did not mention. First, jobs that appear in the documentation but have not run in months, either because they were decommissioned without being deleted from the schedule or because they have been failing consistently and nobody has addressed it. Second, jobs that run regularly but are not documented, created ad hoc at some point and never formally recorded. Third, jobs whose runtimes have grown significantly, which is visible when you compare the 30-day average against whatever baseline is in the documentation.
The job schedule documentation you rebuild from SM37 history becomes the operational baseline for job monitoring: the expected completion window, the normal runtime range, the dependencies. It is work that should have been done before you arrived and was not.
Alert escalation paths: finding out who actually gets called
The escalation documentation probably lists names and phone numbers. Some of those people may still be in the organization. Some may not. The actual escalation path, who gets called when the production system has a problem at 02:00 on a Sunday, is a piece of institutional knowledge that lives in people’s heads rather than in documents.
In the first week, have a direct conversation with at least three people: the IT manager responsible for SAP, the most senior business process owner who uses the system daily, and whoever was handling overnight incidents before you arrived. Ask each of them what happens when something goes wrong at 03:00. The three answers will be different and collectively more accurate than any escalation document.
The outcome of these conversations is a practical on-call runbook: who gets called for what kind of incident, what the expected response time is, which incidents can wait until business hours and which cannot. That runbook is what you write and maintain. It is not what you inherit.
Building a baseline before configuring alerts
Why alerting on day one produces noise rather than signal ?
Alert thresholds configured without baseline data are calibrated against intuition or against SAP’s generic recommendations. SAP’s generic recommendations are starting points for a typical system. Your system is not typical. It has a specific workload profile, a specific batch schedule, a specific HANA memory consumption pattern, and a specific set of interfaces with specific traffic volumes. Generic thresholds applied to a specific system will fire for conditions that are entirely normal in this environment.
The operations team that receives ten alerts per day for conditions that are normal here learns very quickly to ignore alerts. Alert fatigue, once established, is difficult to reverse. The threshold that gets muted because it fires every morning during the batch window stays muted when it fires for a real problem. Starting with no alerts and building them from baseline data rather than building from generic thresholds and reducing noise is the approach that produces a monitoring configuration worth relying on.
The two to four week collection window and what you do with it
Two weeks is the minimum baseline period for a system you have just taken over. Four weeks is better because it captures a month-end cycle. What you collect during this period is the actual distribution of values for each metric you plan to alert on: not the average, the full distribution including peaks.
For dialog work process utilization, you want to know the 95th percentile value across all business hours, the peak value during batch windows, and the typical overnight minimum. An alert threshold set at the 98th percentile of the baseline distribution will fire only for genuinely unusual conditions. An alert set at 80% will fire for the top 15% of normal observations.
For HANA memory utilization, you want the same distribution plus the month-end peak if your baseline window includes one. For each background job in the Tier 1 list, you want the runtime distribution across normal days and the runtime on month-end to set separate duration thresholds.
At the end of the baseline period, you have enough data to configure the first set of meaningful alerts. Not all alerts for all metrics, but the highest-priority ones: HANA memory approaching allocation limit, dialog work process saturation, critical batch jobs running past their expected completion window, HANA log volume growth, and update task failures. These five categories cover the majority of production incidents in a typical SAP environment. Everything else can be added progressively.
Week one, month one, month three: what to have in place when
The timeline below reflects realistic progress for one or two Basis engineers taking over an existing landscape. It is not a project plan. It is a prioritization guide.
By end of week one: system access confirmed, health snapshot transactions reviewed, critical open issues identified (SM13, ST22, SM37 failures), informal escalation path documented from conversations, monitoring platform connected and collecting data in read-only mode without alerting.
By end of month one: interface inventory draft completed from SM59 and partner profile review, job schedule documentation rebuilt from SM37 history, monitoring baseline data collected for the core metrics, first set of alerts configured for critical conditions only (HANA log volume, update task failures, critical job failures), authorization profile for monitoring user reviewed and confirmed as minimal required.
By end of month three: full alert configuration in place based on baseline data, threshold rationale documented, escalation runbook written and tested, month-end behavior observed and reflected in time-aware alert thresholds, monitoring handover documentation written as if you were about to hand the system to someone else (because eventually you will be).
The month three deliverable of monitoring handover documentation sounds premature. It is not. Writing it forces you to articulate why thresholds are set where they are, which alerts are reliable and which still need tuning, and what the on-call engineer needs to know to respond to each alert category. That articulation is the difference between monitoring that continues to work when the team changes and monitoring that needs to be rebuilt from scratch the next time someone new takes over.
The system you inherit is already telling you what it needs
Every SAP production system that has been running for more than a year has developed a character: specific failure patterns that recur, specific performance characteristics that define its normal behavior, specific integrations that require more attention than others. That character is not in any documentation. It is in SM21, in ST22, in SM37 history, in the HANA memory trend graphs, in the sequence of events the previous team responded to.
The reading phase before configuration is not a delay in getting monitoring set up. It is the process of understanding what the system is already telling you, so that when you configure monitoring, you are amplifying the signals that matter rather than generating noise against a template that was designed for a different environment.
Day one monitoring is not about having everything in place. It is about not missing the things that matter while you are learning everything else. That means the health snapshot transactions reviewed, the critical open issues known, and the monitoring platform collecting data before the end of the first week. Everything after that is refinement, and refinement is built on observation rather than assumption.
Redpeaks connects to SAP systems via agentless RFC without transports or SAP-side software. Baseline collection starts from the first day of connection. Alert configuration can be applied progressively as baseline data matures. See how onboarding works with Redpeaks.
