SAP performance testing: load, concurrency and tools

SAP performance testing proves, before go-live, that critical transactions, background jobs and interfaces meet agreed response times when many users and jobs run at once. In my experience the concurrency tests are the ones that matter, run on masked data at production volume, against pass and fail criteria the business agreed before the first run.

This guide is for CIOs, programme directors and test leads on S/4HANA programmes, including RISE with SAP. It covers what to test, the data you need, how to write acceptance criteria, which tools do the job and who owns what. For where performance sits among the other test types, start with my overview of SAP testing explained.

Performance problems in SAP programmes are rarely a surprise.

Fiori tiles time out when hundreds of users log in at the start of a shift. A custom report freezes because someone ran an open-ended fiscal-year selection against a very large table. Background jobs overlap at month-end and the posting run aborts.

These are predictable. The only question is whether the programme tested for them, or whether the business finds them with real orders running.

Performance testing across SAP Activate

1. 01

   Explore

   Identify performance risks in the design. Architecture and report shape decide outcomes before code is written.

2. 02

   Realize

   Run volume and load tests as configuration stabilises. Partial config produces misleading results.

3. 03

   Pre-UAT

   Complete the full performance cycle before UAT, not as part of it.

4. 04

   Cutover

   Approve cutover against the pre-agreed acceptance criteria, not against opinion.

5. 05

   Hypercare

   Watch the live KPIs for 30 to 60 days. Most regressions surface in the first close cycle.

In an ECC system on a traditional database, performance testing meant load-testing the application server and database: ABAP runtime, SQL performance and job scheduling. The front end was SAP GUI, which rarely surprised anyone.

On S/4HANA, with Fiori front ends, extensions on SAP BTP and integration through SAP Cloud Integration, performance depends on several layers at once. A slow Fiori tile could be a long ABAP call, a gateway timeout, an OData service not designed for concurrent requests or network latency in a hybrid set-up. Testing the back end alone will not find it.

1. 01Tile launchLogin storms at shift start
2. 02OData callGateway timeouts, services not built for concurrency
3. 03ABAP processingLong-running ABAP calls
4. 04Database readOpen-ended selections on large tables
5. 05RenderingPlus network latency for distant sites

One response time, measured end to end

SAP HANA performance testing has its own twist on a conversion. Stable ECC code behaves differently on an in-memory database. Many programs get much faster, while some produce unexpected profiles on particular data patterns, so conversion-specific regression of the heavy custom code is not optional.

Integration flows add their own risk. Flows that worked in development with single test messages can queue up or fail silently at production volumes. The symptoms look like something else: intermittent order failures, invoice mismatches, data present in one system and missing in another.

Performance testing must happen before go-live. The tests I treat as the important ones are the concurrency tests: many users and jobs hitting the same transactions, tables and services at the same time.

A single user running a sales order in two seconds proves almost nothing. The same order with 150 people entering orders, a delivery run in the background and an interface posting inbound messages is the test that predicts day one.

This table shows what each type of test proves and when to run it:

Test	What it proves	When to run it	What it usually finds
Concurrency	Many users and jobs can work on the same objects at once	Realize, once configuration is stable, and again before UAT	Lock waits, login storms, gateway bottlenecks
Load	The system meets response times at expected peak volume	Realize, after concurrency scripts work	Slow OData services, heavy custom reports
Stress	Where the system breaks above design limits	Before UAT, if growth is expected	Sizing gaps, queue limits
Soak	The system holds steady load for hours	Before UAT, ideally across a simulated close	Memory growth, job-chain contention across repeated runs
End-to-end	The full path a user waits for meets the target	Alongside load tests	Problems invisible when each layer is tested alone

The key word in load testing is expected. You need real transaction volumes, user counts and session patterns. A load test built on volume estimates everyone already knew were optimistic gives a pass that means nothing.

Soak testing is the one most often skipped. Volume testing in general is the shortcut programmes take most often when the timeline compresses, and regret most.

Script these first. They cover most of the failures that reach production.

1. Shift change and peak login. When a few hundred users open the Fiori launchpad at the same time, authentication and launchpad rendering spike. A system that is fine off-peak can be unusable in that window if concurrent logins were never tested.
2. Month-end and year-end close. High-volume postings, job chains with strict sequencing and a finance team racing a fixed deadline. Run the close job chains end to end against closing-period volumes, not average daily counts.
3. Overlapping background jobs. Batch jobs are usually tested one at a time, which does not reflect reality. One poorly optimised job can block several others, and the close runs past its window.
4. Open-ended custom reports. A report that returns instantly on test data can run for minutes on a full fiscal year. Test typical and worst-case selections, and block the open-ended ones.
5. Multi-region users. Network latency affects every transaction. RISE moves hosting to SAP, but latency still depends on the region you choose and the routing to your users, so test from the sites that are furthest away.

My ECC to S/4HANA migration guide covers where conversion testing fits in the wider plan.

Production-level test data

The data decides whether any of this means anything. I insist on masked data at production level: production volume and production realism, with personal and sensitive fields masked.

A customer with 200,000 open order lines behaves differently from one with 5,000. Filters that return instantly in a thin test client time out in production. Seed volume for the high-risk areas, use a representative transaction mix and make real interface calls where you can.

How to get that data safely, through copies, selective test data tools and masking, is covered in my guide to SAP test data management. Plan the refresh before the first performance cycle, because it takes longer than most test plans assume.

Agree criteria with the business in the Prepare phase, before any test runs. Each one names the transaction or job, the load and the threshold.

These examples show the shape. Set your own numbers from operational needs:

Item	Load condition	Pass threshold	Owner
Sales order creation (VA01 or Fiori app)	150 concurrent order-entry users	Under 3 seconds for 95% of transactions	Order-to-cash process owner
Fiori launchpad first load at shift start	Peak concurrent logins for the largest shift	Under 5 seconds for 95% of users	IT operations lead
Month-end close job chain	Closing-period volumes, full sequence	Completes inside the agreed close window with no aborts	Financial controller
Inbound order interface	Peak hourly message volume	No queue backlog older than 15 minutes	Integration lead
High-volume custom report	Full production data volume, typical selection	Under 60 seconds; open-ended selections blocked	Report owner

"The system should be fast enough for business operations" cannot be tested or accepted. Changing criteria after results arrive defeats the point of having them.

If the system passed because UAT users said it felt fast, you have an opinion, not an acceptance criterion. Make the results a formal gate before cutover, the way my guide to SAP quality gates describes. The overall cycle plan, with entry and exit criteria for each test phase, belongs in your S/4HANA testing strategy.

SAP performance testing tools

A performance test needs three things: a load generator that can drive SAP protocols, monitoring on the SAP side and a place to manage test cases and results. LoadRunner is the load tool I have had teams use on SAP programmes. Name the tool in the test plan early, because licences, load generators and scripting skills all take time to arrange.

The main options in 2026:

Tool	Role	What to know
OpenText Professional Performance Engineering	Load generation	The product formerly called LoadRunner Professional. Its protocol bundles cover SAP, SAP GUI and SAP Web
Tricentis NeoLoad	Load generation	Tricentis lists SAP GUI, Fiori, RFC and IDoc support, and it can reuse Tricentis Tosca assets
Apache JMeter	Load generation	Open source. Drives HTTP traffic such as Fiori and OData calls
SAP Cloud ALM	Test management	Prepares and runs manual and automated test cases and tracks defects. It does not generate load itself
SAP Solution Manager	Test management	Mainstream maintenance ends on 31 December 2027, so plan new work in Cloud ALM

For a wider view of functional and automation tools, see my comparison of SAP testing and validation tools. The tool matters less than the scripts, the data and the criteria.

RISE with SAP splits the responsibility

Under RISE with SAP, SAP owns infrastructure: sizing, hyperscaler region, network and platform availability. The client and partner own the application layer.

SAP's RISE roles and responsibilities document is plain about it. Load test execution and the tuning of expensive SQL statements are SAP Cloud Application Services at additional charge. If you do not buy them, the customer does the work.

A common failure on RISE programmes is the assumption that SAP will catch performance problems because it runs the infrastructure. It will catch infrastructure problems. Write the split into the charter and the test plan:

1. SAP: infrastructure availability and platform-level response
2. Partner: application performance under the defined load, including extensions and integration flows
3. Client: process-level outcomes such as close runtime and order throughput, and the acceptance decision

Public cloud narrows the scope

On the public edition of SAP's cloud ERP, the system runs on a shared, SAP-operated platform. Before you plan any load test against a tenant, ask SAP in writing whether it is permitted and what notice it needs.

Your testing then shifts to what is yours: custom integrations, extensions, high-volume reports, the close sequence and the network path from your sites. Platform performance problems go to SAP support.

Common mistakes

1. Treating functional testing as performance testing. Functional tests prove a transaction gives the right result. They say nothing about 150 people running it at once.
2. Leaving performance to Basis. Basis owns sizing and job scheduling. It does not own report design, OData service architecture or integration flow design, and those drive application performance.
3. Giving ownership to QA alone. QA runs tests and reports results, but the decisions that cause performance problems are made in design. A programme-level test lead or architect needs the authority to challenge them early, and the RACI should say who can block go-live on performance grounds.
4. Accepting gaps as known issues. Most programmes with performance problems in production did not skip testing. They tested without agreed criteria, or tested and then accepted the failures under schedule pressure.

Write the five or six acceptance criteria for your highest-risk transactions and jobs, with a named owner for each. If you cannot fill in the table above, you are not ready to test, and you have found the first gap.

Then check two things: that a masked, production-volume data refresh is in the plan, and that the concurrency cycle finishes before UAT starts.

If you want an independent view on a performance test plan or a go-live decision, I help organisations with this. You can contact me here.

What is SAP performance testing?

It checks how SAP behaves under realistic load: response times for user transactions, runtimes for background jobs, throughput for interfaces and resource use when many people work at once. It must be done before go-live.

Functional correctness and performance are different properties. A transaction that is correct for one user can time out for 200.

When should performance testing start in an SAP programme?

Risk identification starts in Explore, because architecture choices set performance outcomes. Active testing starts in Realize, once configuration is stable enough that results mean something.

Finish the final cycle before UAT, not during it. Performance defects found in UAT squeeze the schedule and create pressure to accept them as known issues.

What is the difference between load testing and concurrency testing in SAP?

Load testing checks response times at the expected peak volume. Concurrency testing checks what happens when many users and jobs work on the same transactions, tables and services at the same moment. That is where lock waits, login storms and gateway bottlenecks show up.

In my experience concurrency tests are the important ones. Run them first, then build the full load test on top.

What test data should SAP performance testing use?

Masked data at production level. That means production volume and realism, with personal and sensitive fields masked. Thin test data hides the slow filters, heavy reports and long job runtimes that appear on day one.

Which tools are used for SAP performance testing?

Load generators such as OpenText Professional Performance Engineering (formerly LoadRunner Professional), Tricentis NeoLoad and Apache JMeter drive the load. SAP Cloud ALM or SAP Solution Manager manage the test cases and results, and SAP-side monitoring shows what the system did under load.

Who owns performance testing on RISE with SAP?

SAP owns infrastructure: sizing, region, network and platform availability. SAP's RISE roles and responsibilities document leaves load test execution and expensive SQL tuning with the customer unless SAP Cloud Application Services are bought at extra charge.

The client and partner own application performance and the acceptance decision. Write the split into the acceptance criteria so each threshold has an owner.