How Long Until SAP Customers Adopt ERP Upgrades?

Executive Summary

  • SAP likes customers to upgrade their ERP software as soon as possible as this maximizes SAP and their consulting partner’s revenues.
  • The actual update lag is quite surprising.


In SAP upgrades are major expense items for a company. This is explained by Rimini Street in the following graphic.

This cost to upgrade is nearly always dramatically underestimated by IT departments. This is because the costs are hidden in the ERP budget.

The Cost and Effort of Upgrades

Cost is one reason that SAP ERP customers upgrade far less than is generally understood, and wait far longer to upgrade. Another reason is the overall disruption to IT, and to sometimes the business. The book SAP Nation 2.0 provides the following explanation for the lag in adoption of the latest version.

“Not all customers adopt every new SAP version. Even the most adopted EHP 4 research a peak adoption rate of approximately 35 percent, and three years after becoming generally available (GA). The time it takes a new version to reach peak adoption is approximately 18-24 months after GA. In addition, we can see that EHP 7 (the latest version, and the required version to support Business Suite on HANA as well as Fiori), has a steeper adoption rate and has the potential to become the most adopted version. Unlike Android or mobile applications, the expected upswing in ERP adoption is measured in years, not months.”


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