By Caleb Billingsley, Performance Expert at Foulk Consulting
“Shift Left” has become a default assumption in modern software delivery. In cloud-native and web development, teams test early, test often, and catch problems long before users ever feel them.
But SAP?
That’s where the conversation usually stops.
SAP whether on-premise or RISE with SAP (Private Cloud Edition)—are designed for stability and speed, however customizations and 3rd party integrations can negatively impact both stability and speed. Transport controls, rigid change processes, data migrations, and business-critical uptime naturally push performance testing to the end of the lifecycle—often UAT or pre-go-live—when issues are the most expensive to fix.
And yet, the reality is this:
Shift Left in SAP is not only possible—it’s necessary.
It just needs to reflect how SAP actually fails in the real world.
The Real Source of SAP Performance Problems
Before talking about tools, environments, or DevOps models, it’s important to address a common misconception.
Most SAP performance problems are not caused by SAP standard code.
In practice, they break down roughly like this:
- ~80% come from custom ABAP code and 3rd-party integrations
- ~10% stem from configuration or sizing decisions
- ~10% are caused by environment, data, variants, or infrastructure factors
This matters because it tells us where shifting left delivers real value—both on-prem and under RISE.
80%: Custom ABAP Code & 3rd-Party Integrations
This is where the majority of SAP performance risk lives.
These issues commonly surface in:
- Inefficient SELECT statements (missing indexes, SELECT * abuse)
- Nested loops over large internal tables
- Poor buffering or table access patterns
- Chatty RFC, IDoc, CPI, or PI/PO integrations
- Custom logic that works fine in DEV with small datasets but degrades rapidly at scale
The key insight:
These problems do not require massive user concurrency to reveal themselves.
They surface with realistic data volumes and real execution paths—often during early integration testing—long before UAT load tests ever run.
This is true:
- In traditional on-prem ECC or S/4 systems
- In SAP RISE Private Cloud environments
RISE does not change how inefficient ABAP behaves. It simply reduces the tolerance for finding those issues late.
10%: Configuration and Design Decisions
Another meaningful portion of performance issues comes from configuration choices, including:
- Overly complex pricing procedures
- Inefficient ATP or MRP strategies
- Excessive authorization checks
- Enhancement points triggered by configuration rather than necessity
- Undersized or misaligned work process allocation
These are often mislabeled as “system slowness” when the root cause is functional design, not infrastructure.
10%: Environment, Data, and Infrastructure
Infrastructure sizing, stale statistics, missing background jobs, poorly planned MRP variants or unrealistic test data also matter. Testing these earlier with realistic data and running jobs like they will be run in production is critical to success on go-live.
Even under RISE, where SAP owns infrastructure operations, these factors represent the smallest slice of performance risk.
Why Shift Left Feels So Hard in SAP
The resistance to Shift Left in SAP isn’t technical—it’s cultural.
- Teams are rewarded for stability, not experimentation
- Transports enforce linear thinking: DEV → QA → PROD
- Performance is viewed as a late-phase QA activity
- Developers rarely receive feedback on the runtime impact of their custom code
- Under RISE, teams may feel even further removed from system behavior
This stands in contrast to modern DevOps environments—but the gap is cultural, not impossible to bridge.
Shift Left Doesn’t Remove Performance Specialists—it Uses Them Earlier
A critical clarification:
Shift Left does not mean developers replace performance engineers.
Even in cloud-native DevOps organizations, performance is rarely “everyone’s job” in practice. It is typically enabled by SRE or platform teams operating as shared services.
SAP requires the same model—arguably more so.
Performance as a Shared Service in SAP
In an effective SAP Shift Left model, Performance Shared Services engage earlier—most effectively during ITC2 through ITC4, well before UAT.
Performance Shared Services:
- Parametric testing during ITC2
- Identify high-risk custom transactions and integrations
- Focus on the 80%: custom ABAP and interfaces
- Define performance baselines and thresholds
- Focus on end-end test cases that span system integrations
- Guide tool usage and result interpretation
- Partner with developers on remediation strategies
Development Teams:
- Execute enabled performance checks earlier
- Validate custom code and integrations with realistic data
- Catch regressions before promotion
- Collaborate with performance specialists when thresholds are breached
This mirrors the SRE model in DevOps: central expertise, decentralized execution.
Why ITC3 / ITC4 Are the Sweet Spot
ITC3 and ITC4 are where SAP performance risk becomes visible:
- Custom code is functionally complete
- Integrations are active
- Data volumes are closer to production reality
- Changes can still be isolated to specific transports
At this stage, performance teams can:
- Detect regressions tied to specific customizations
- Validate integration behavior without full load
- Provide actionable feedback while fixes are still affordable
UAT should confirm performance—not discover it.
Tooling Supports the Model—It Doesn’t Replace It
SAP already provides the necessary technical tooling:
- ST03 – Used to gather data from production
- SM38/SAT – Use selectively during performance testing to find configuration and code issues
- SQL Monitor (SQLM) – Database access validation
- ST05 – SQL trace with realistic data
- ATC / Code Inspector – Prevention of known antipatterns
- Synthetic performance scenarios in early integration environments
The value comes not from the tools themselves—but from how Performance Shared Services enable their use earlier in the lifecycle.
Why This Matters Even More Under RISE
Under RISE, late discovery often means:
- Limited tuning windows
- Dependency on SAP operations
- Escalations instead of fixes
- Increased go-live risk
Because RISE limits last-minute maneuvering, early detection of custom code and integration issues becomes even more critical.
So, Is Shift Left in an SAP World Really Possible?
Not as a developer-only responsibility.
Not as a pure DevOps ideal.
But as a shared service model, focused on the real sources of SAP performance risk—custom ABAP and integrations—and engaged during ITC2/ITC3 instead of UAT?
Absolutely.
Shift Left in SAP isn’t about removing specialists.
It’s about using them sooner, so the 80% of performance problems tied to customization surface early—when they’re cheapest to fix and least disruptive to the business.
Ready to implement a Shift Left strategy that works for your SAP landscape? The path to faster, more stable SAP delivery isn’t found in last-minute testing, but in a refined shared service model that tackles the 80% risk area—custom ABAP and integrations—early in the lifecycle. Don’t let performance issues escalate to UAT. Contact us today to operationalize this model and turn your performance engineers into proactive partners.
