Operational debt in SAP landscapes accumulates one reasonable decision at a time. The hotfix transport route was created during an emergency and made sense then. The direct RFC connection was added when the middleware was unavailable and it worked, so it stayed. The authorization role was copied from the previous consultant’s setup because building one from scratch would have taken another week. None of those decisions were mistakes in isolation. The debt is the sum of them, compounded over years.
The signs below are not catastrophic failures. They are the architectural patterns that add operational cost slowly, show up as hours of investigation time per incident, and make every system change more complicated than it should be. Each one is recognizable. Most SAP landscapes have at least three of them.
Sign 1. SM59 contains RFC destinations that fail the connection test and nobody knows if they are still needed
Open SM59 in your production system. Run the connection test on every type 3 RFC destination. Count how many fail. Then ask the team which of the failing ones can be safely deleted.
In most landscapes that have been running for more than four years, the honest answer is: we are not certain. Connections were added during projects, during emergency integrations, during migration activities, and during consultancy engagements that ended years ago. The system they pointed to may have been decommissioned. Or it may still exist and is actively receiving calls from a program that the connection test does not exercise.
The operational consequence is not the dead connections themselves. It is the hidden dependency web they represent. When a connected system is decommissioned, the people making the decommission decision do not know that three RFC destinations in production point to it. They find out when an interface fails in production and the investigation leads back to a destination that was pointing at a server that no longer exists.
An SM59 audit that documents every destination, its owner, its last successful call date, and the business process it supports costs half a day. It removes the ambiguity permanently and reveals which connections can be cleaned up versus which are genuine operational dependencies that need to be monitored.
Sign 2. The batch schedule exists in SM36 and also in a spreadsheet and also in the service management tool, and none of them agree
This is the most common form of operational debt in SAP batch management. The official schedule is in SM36. A project created a parallel tracking spreadsheet three years ago that has not been updated since the last consultant rotation. The ITSM has recurring tasks for the most critical jobs that were added for SLA tracking and reflect the schedule as it was when they were created, not as it is today.
When a job needs to change, one or two of these three places gets updated. The others drift. A job that moved from 03:00 to 02:00 still has an ITSM recurring task checking for completion at 04:30, because nobody updated it, and it passes every morning based on a completion time that is no longer the right reference.
The operational cost shows up when something goes wrong. The investigation uses the spreadsheet or the ITSM task as the reference, not SM36, because it is faster to check. The reference is wrong. The investigation goes in the wrong direction. An additional 45 minutes of analysis time per incident is invisible in any single post-incident review and completely visible when you add up the hours across a quarter.
Sign 3. The “hotfix” transport route is used more often than the standard development-to-production route
Every SAP transport landscape has or has had a hotfix route: a path that allows transports to move from a correction system directly into production, bypassing the quality gate. The hotfix route exists for legitimate emergencies: an OSS note that must be applied immediately, a legal change with a fixed effective date that cannot wait for the next release cycle.
The sign of operational debt is when the hotfix route is the default path for a significant fraction of transports. When the team has stopped using the development-to-QA-to-production route for most changes because QA is three versions behind, or because the QA testing cycle takes longer than the business is willing to wait, or because the transport approval process for the standard route has become a bottleneck. At that point, the quality gate is not a gate. It is an optional step for changes that are not urgent, which in practice means almost no changes.
The consequence is not visible in the transport system, which shows all transports as approved and imported. It is visible in production incidents where a change was not tested in an environment that matched production, and the failure that would have been caught in QA is instead caught by a user.
Sign 4. Quality and production systems run different HANA versions or have data volumes that differ by more than an order of magnitude
QA exists to catch problems before they reach production. Its value depends entirely on how accurately it represents production conditions. A QA system running an older HANA version, or a QA system that carries 15% of production data volume, provides a different type of assurance than one that matches production closely.
The specific failure mode this creates is the problem that is not reproducible in QA. A performance issue that only occurs at production data volumes cannot be tested in a 15% copy. A behavior change introduced by the HANA version difference between QA and production only appears after the production system is updated. Each of these failures required a production incident to discover, at which point the organizational response is “this should have been caught in QA” and the technical response is “it could not have been caught in QA given how QA is configured.”
Keeping non-production environments reasonably current with production is an operational discipline that requires budget and planning. The budget for regular system copies and version alignment is consistently cut in favor of more visible project spending. The debt accumulates every time a production incident could have been caught in a properly maintained QA environment and was not.
Sign 5. Authorization roles are copies of copies, and nobody can explain why specific transactions are included
Ask the authorization administrator to explain why a specific transaction code is included in a critical role. If the answer is “it was in the role when we copied it” or “I think a consultant added it for a specific requirement,” the landscape has authorization debt.
The mechanism is straightforward. A role is created by copying an SAP standard role. It is modified for the specific requirement. Later, someone needs a similar role and copies the modified one rather than starting from the standard. The copy inherits everything from the first modification, including authorizations that were specific to the first use case and irrelevant for the second. The second role is then copied for a third case. By the fourth generation, the role contains authorizations from three different use cases, each of which has evolved since the role was copied, and none of which anyone can fully trace.
This is not a security failure in the sense of unauthorized access. It is a governance failure that makes access reviews misleading and audit findings inevitable. The role contains more than it should contain, for reasons nobody can document, in a system that handles financial transactions.
Sign 6. Custom ABAP enhancements are undocumented and the person who built them is no longer at the company
The enhancement exists. It modifies standard SAP behavior. It has been running in production for four years. When a new ABAP enhancement package is installed and a standard SAP function changes, the enhancement breaks. The team opens the code to fix it and discovers that it contains no comments, uses non-standard techniques, and accesses database tables directly in ways that the standard SAP APIs would have handled differently.
The time to fix it is three times what a well-documented enhancement would require, because the investigation is reconstructing the original intent before the fix can be designed. The risk of the fix is higher because the original design constraints are unknown.
This pattern compounds every time the landscape is upgraded, every time a standard program the enhancement relies on changes, and every time a new consultant touches the codebase and discovers an undocumented behavior that was producing results the business depended on without knowing it was custom.
The operational debt is not the existence of custom ABAP. It is the existence of custom ABAP without documentation. One is an architectural choice. The other is a maintenance liability with a cost that compounds with every system change.
Sign 7. The “known issues” list has grown every quarter for two years and has not been reduced
Every SAP operations team has a known issues list. It contains items like: the SM37 failed job history from a cancelled migration project in 2021 that should be cleaned up. The RFC destination pointing to the decommissioned CRM system that still shows in SM59. The development client that was accidentally unlocked six months ago and has not been relocked. The background job that was cancelled manually during an incident and never rescheduled.
The list grows because resolving these items requires effort that is always lower priority than the current active work. Each item is small enough to defer. Collectively, they represent the explicit debt register of the landscape: a documented list of known-wrong conditions that the team has accepted as permanent background noise.
The operational cost is not the items themselves. It is what they do to incident investigations. When a failure occurs in a landscape with 40 known issues, the first question in the investigation is whether the failure is related to one of the known issues. That disambiguation step, checking whether the new incident is connected to an existing known problem, adds time to every investigation in a landscape where the known issues list is long enough to be a real reference list rather than a short exception list.
| In practice: A known issues list that has not been reduced in two years is not a backlog. It is an acceptance that those conditions are permanent. The correct response is not to close all the items immediately but to decide explicitly which items are tolerated indefinitely (with documentation of the reason) and which are targeted for resolution on a defined timeline. The list that is actively managed, even slowly, produces less operational friction than the list that grows without bound because the team has implicitly accepted its contents as normal. |
Operational debt in SAP landscapes is not an accident and it is not the result of bad intentions. It is the cumulative effect of reasonable decisions made under real constraints, accumulated without a mechanism to review and address them before they compound.
The review that identifies these signs does not require a lengthy architecture engagement. It requires someone to look at the landscape with the question of which patterns are creating operational cost rather than which ones are architecturally elegant. Most of the signs above are visible in a half-day of looking at the right transactions: SM59, SM36, SE01, PFCG, and the team’s own known issues list.
What the review requires is the willingness to treat the findings as actionable rather than as the accepted background condition of a system that has been running for years. The debt does not stop compounding on its own.
Redpeaks monitoring surfaces several of these operational debt indicators continuously: RFC connection health, batch schedule integrity, authorization change events, and configuration drift from documented baselines. See the landscape health monitoring features.
