How Much of Customers’ SAP Customer Code is Used?

Executive Summary

  • SAP constantly tells customers to get rid of their custom code and to use SAP standard functionality. This old point has been brought up again with S/4HANA.
  • How much of customers’ custom code is actually used by customers?


SAP proposes that very few custom coded objects for SAP systems are actually used. SAP has proposed that for companies that plan to implement S/4HANA, that the custom code is evaluated for removal. This has been a long-term strategy by SAP to get customers to use standard functionality, the problem being, SAP is always sold with the amount of functionality that will meet the customers being overstated, which we covered in the article How to Understand the Overamapping of ERP to Functionality.This leads to the question of how much custom code in SAP systems is relied upon by customers.

SAP Nation 2.0 on the Percentage

The book from SAP Nation 2.0 provides an explanation of how much custom code is used.

“According to Panaya, a tool vendor, “Our data shows approximately 50 percent of customers use 60 percent or less of their custom code. Being able to easily identify which parts of that code can be safety cleaned from the system can help reduce the future cost of such upgrades.“”

That is no the level of code used by customers communicated by SAP, which attempts to make the percentage utilized seem far less.


The fact is, that SAP customers do not think the latest versions of ECC are worth the time and expense to upgrade. Furthermore, many customers that do upgrade, would not have if they had fully accounted for the costs. One cannot listen to either SAP or to SAP consulting companies for objective advice as to whether to upgrade, as both entities make money from the upgrade process.

Financial Disclosure

Financial Bias Disclosure

This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.

SAP Contact Form

  • Interested in Our SAP Research?

    The software space is controlled by vendors, consulting firms and IT analysts who often provide self-serving and incorrect advice at the top rates.

    • We have a better track record of being correct than any of the well-known brands.
    • If this type of accuracy interests you, contact us and we will be in touch.



Enterprise Software Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Rethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.


Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model