SAP Performance Best Practices for Implementation, Upgrade & Migration


UPDATE: See our recent SAP Performance Testing as a Service announcement.

Optimizing SAP performance of the newly implemented, upgraded, or migrated SAP environment should be one of the top priorities of an application or technology refresh project besides gaining some new functionality or business benefits.  However, our experience shows that most customers either short-cut these efforts or they are done as an afterthought.  Even when it is baked into the plan, often there are controversies about how to best approach performance testing, monitoring, and optimization as part of an overall performance assurance methodology.  The results frequently reflect post-go-live issues which hinder availability, and end-user experience, and cause management and operation teams many headaches.

In this post, we will cover some essential items and best practices to consider when planning performance assurance around the life cycle management of an SAP environment.  We'll also point out some useful tools you can use to implement these tips, where appropriate.


To avoid performance shortfalls and end-user disappointment, we're summarizing the best practices in a complete performance assurance plan:

Phase 1: Sizing & Architecture Design

Phase 2: Business Service Level Agreement

Phase 3: Plan, Build, Deploy, and Test

Phase 4: Monitor, Optimize

Phase 5: Baseline and Continuous Service Level Management


Download SAP Performance Best Practices Guide


Phase 1: Sizing & Architecture Design

Sizing and the design of the architecture that follows is the first important phase of any project.  A step in the wrong direction will likely derail the project.  The topic sounds technical, right? Actually, sizing involves as much of the business as the IT team.  According to SAP, sizing involves 'Translating business requirements into hardware requirements - in an iterative process.'  Gartner in its June 2014 article (Follow Three Best Practices to Optimize SAP Business Suite Application Performance) recommended to 'Perform annual capacity planning for each SAP Business Suite application to ensure sufficient hardware headroom through its life cycle'.

SAP sizing involves the collection of business metrics such as users, business transaction document volume, and line items which equates to SAPS (SAP Application Performance Standard) which is a hardware-independent measurement unit representing a throughput processing requirement.  Certified Hardware partners who provide computing resources to SAP customers often measure the throughput of their platforms using the standard Sales & Distribution (SD) benchmark where 100 SAP = 2000 fully processed order line items per hour (or 6000 dialog steps - also known as interactive GUI screen changes).  For more information, see SAP Standard Application Benchmarks.

There are 2 main approaches and tools associated, other approaches are combinations or deeper dives into the variations.  Sizing needs to take into account whether it's a new implementation, upgrade, or migration as obviously an upgrade or migration may have better numbers from an existing production environment (e.g. SAP EarlyWatch report, or some monitoring report):

  • SAP Quick Sizer is a questionnaire-based tool that does a pretty good job estimating common business scenarios (such as ECC, BW, CRM, etc.).  Visit for further details
  • T-shirt sizing is an approach using 3-4 rough sizes under the assumption that some numbers are better than none when it comes to estimating processing requirements.  It can be useful for the budget planning phase when numbers may not be clear, assumptions can be made and validation can occur later.  For more information visit

Architecture Design: Once the sizing information has been generated as standard SAPS, the customer can submit those to their platform vendor (which may now also include cloud providers).  The vendor architect will map those requirements to CPU, Memory, Disk Size, I/O throughput, and Network load.  Based on those requirements, platform-specific hardware or virtualized infrastructure options are proposed.


  • Customers are to shop several partners for options, assess pros and cons, and if possible perform a proof-of-concept (PoC) on those options.  In earlier SAP days, POC can be costly with leased hardware and services which may get credited by the vendor towards a purchase (if made).  Nowadays, with cloud PaaS (Platform as a Service) and IaaS (Infrastructure as a Service), it's definitely less costly to trial before your buy.
  • Sizing is part art, part science so make it iterative and review often as earlier assumptions become fact or validated as part of PoC or testing.  Requirements also may change over time so just expect them and iterate accordingly.  Of course, the more complex the business scenarios, the more iterations may be needed to address various application needs.

Phase 2: Business Service Level Agreement

Business Service Level Agreements (SLAs) are ways of measuring the quality of service that IT provides to the business units or end-user groups of the application.  Sometimes they may be referred to internally in IT as Operational Level Agreement (OLA), which governs how the IT environment should operate to provide shared services to end-users.  Before building, testing, and delivering any service, IT organizations should establish templates and metrics for which the Business can agree as the baseline for service quality.  These items will become KPI (Key Performance Indicator) which are measured and reported for compliance on a periodic basis.

Common SLA metrics may include:

  • Availability (Planned and Unplanned)
  • Average Dialog Response Times (System wide)
  • Application Response Times (Specific transactions or group of transactions)
  • Batch Processing Run Times
  • Incident Response Times (Incident detection to resolution for specific event types such as job, transaction, and interface failures)


  • IT and Business (or Line of Business - LOB) should agree during this phase to mock-up dashboards that would measure, report, notify, and pre-assemble remediation processes to deal with SLA violations, including service desk queues and team assignments to deal with availability and performance issues or incidents.
  • Poor Performance = Poor Availability

Phase 3: Plan, Build, Deploy, and Test


Figure 1: Plan, Build, Deploy, and Test

Plan: the work and work the plan!  Now that there are clear sizing, architecture, and SLA established, it's time to map out the tasks required to accomplish the delivery of a functional and efficient application environment.  Depending on the size of the project, executive sponsorship must exist to create a project plan that includes availability and performance-related tasks at every step.  

Build: Documentation must reflect the reference architecture chosen to support the availability and performance requirements determined in the previous two phases Sizing & Architecture, as well as SLA.  Often, either a time gap and/or team gap occurs such that the build is done by a different team later and does not look anything like the original design

Deploy: Isn't it the same as Build? It can be if you're building only one system, it's not the case with SAP.  Unless your environment is a single-system landscape, many customers will build development, QA, test/staging, DR, and Production.  Sometimes a Production environment is built initially as a learning exercise for early testing but deployed again with various optimization or automation, especially in virtualized settings or software-defined data centers such as VMware.

Test: Validate the build and deployment to ensure it performs as expected in the areas of availability and performance.  The more testing with objectives the better the operational readiness of the team and environment.


  • Regardless of organization size, a performance task force (either dedicated or virtual) should be established to focus on the performance aspects of everything from architecture decisions to configuration, build, testing, and go-live.
  • Proper testing may sometimes reveal more than just configuration defects but also vendor platform or software defects (aka bugs).  This is part of the burn-in process needed to stress the new environment.
  • Test automation tools will greatly accelerate both functional validation and performance load tests so that iterative testing can be done.  SAP provides for Business Suite the eCATT tool which with trained resources can record and replay transaction testing scenarios, while other vendor tools like HP LoadRunner and Worksoft Certify provide more powerful integrated test automation.  IT-Conductor can integrate tests built by these tools into automated test scenarios that can be scheduled to run and analyzed.

Phase 4: Monitor & Optimize

Monitor: Gartner also listed the top 3 best practices as 'Implement proactive performance monitoring and trending for each SAP Business Suite application and its infrastructure' in its June 2014 article. Whatever SAP monitoring tools you choose, whether native vendor tools such as SAP Solution Manager, CCMS, or 3rd-party tools, consider the 10 Ways to Automate towards Smart Application Management.

Optimize: This can be at the infrastructure level (OS, DB, Storage, Network), application configuration, and custom code.  Apply specific tuning recommendations from each vendor for the technology deployed.  Poorly optimized code can be mistaken as performance issues at the infrastructure level, so application code analysis along with SQL analysis is typically the next level of optimization once monitoring has identified them as top consumers.  Code inspectors can be used to identify poorly formed code which may appear fine when run against small volumes but grinds against large volumes of data.


  • Code review for performance is a critical part of application life cycle management.  Use System trace, ABAP trace, SQL trace, and Root-cause analysis tools to pin-point the deficient resource hogs
  • Tuning should only be done if performance can be measured before and after to gauge the effectiveness of any optimization
  • Use synthetic transaction monitoring to simulate transactions end-to-end on a proactive basis to check their status and response times as well as detect when deviations occur from performance baselines for those transactions

Phase 5: Baseline and Continuous Service Level Management

Baseline: involves the performance measurement at key times to capture what to expect under certain workloads, such as load tests, benchmarks, and other cycles like daily, weekly, monthly, quarterly, and annually.  Pre-go-live tests and measurements should provide estimates of what to expect after going productive in the new environment.  After go-live, the actual production workload at those cycles like month-end or some key peak workload times should be captured for comparisons and analysis.

Continuous SLM: Performance is dynamic and constantly changing based on business usage patterns and data volume over time, so continuous vigilance in monitoring, analysis, and optimizing is required to ensure capacity and configuration continue to meet demands.


  • GoingLive Check and EarlyWatch are some SAP services customers often leverage, but they can lack the dynamic tools for a deeper dive and can be reactive, even though they are supposed to be proactive.  Look for proactive tools that monitor and manage exceptions as they occur with baseline capabilities for comparisons, as well as dynamic SLA dashboards based on flexible definitions of KPI
  • Service Impact Management monitoring tool is important to relate whether infrastructure or application issues actually have impacts on overall SLA so that appropriate priorities can be assigned to managing those exceptions.  Otherwise, there would be too many unprioritized items fighting for the performance team's resources.

Key Takeaway

SAP Performance management is a complex subject that spans many teams, technology, and processes within the organization, but there are clear best practices with which to guide organizations of all shapes and sizes on ways to manage it as a life-cycle rather than a one-time occurrence.  Whether implementing SAP for the first time, upgrading/patching, or migrating to new platforms, the effort spent will pay back many folds in operational efficiencies that ensure better user experience as well as business availability.

Looking for an integrated solution to help with many of the SAP Performance management needs?  Try IT-Conductor, engineered as a cloud-based SAP Performance management platform.  We also offer SAP Performance consulting via our partner solution at OZSOFT.


Schedule a Demo