Skip to Content

Get Ready for SAP Enhancement Packages (2): The differences between enhancement packages and release upgrades

Edition of this series: Get ready for Enhancement Packages (1) – 2 – 34


The nature of implementing an enhancement package (EHP) is significantly different from a release upgrade, even though both types of projects also have some common characteristics. It is worthwhile to look at the details of this comparison. Oversimplifying the implementation of enhancement packages leads to unrealistic expectations and unwanted surprises during your implementation project.


With SAP Enhancement Packages, new functions can only be configured, realized and used AFTER the corresponding business function has been activated. This is the most obvious difference between EHP and release upgrade, In other words: All new functionality is hidden behind switches and remains invisible for end-users until you explicitly request to use it. This allows you to separate more strictly between the installation on one hand and the configuration (after the activation) on the other hand.

Lets look at these two steps – installation versus activation – and frame the differences as well as the similarities. The following graphics will help you visualize this explanation.






Partial Installation – A technical upgrade to a new release always means that the coding of all software components is completely replaced – also those objects that might not have been changed since the source release. With SAP Enhancement Package, typically only subsets of software components are touched. The ones that are replaced depend on the functional enhancements that you want to use afterwards. The clearly recommended path is to FIRST select the new functionality of your interest, and SECOND to install only the relevant parts that your selection requires. Please note that this option is designed to leave your system as stable as possible. If you prefer not to use this option, that’s absolutely fine provided that you are willing to accept longer installation times and potentially more objects coming up in the SPAU transaction. (SPAU is the transaction that brings up modifications that you had included in those ABAP objects that are now being updated.)


Delta Update Procedure – For each updated software component, only sublets of objects are replaced. The others are not touched in order to ensure maximum stability of your solution.


Strict development rules – Table splitters and data migrations are strictly forbidden. Applying these principles when developing SAP enhancement packages for SAP ERP means the risks of installing updates are kept to a minimum. No upgrade customizing is necessary after the installation unless new functionality is switched on.


All these aspects relate to new functionality that comes with enhancement packages. Please be aware that you can also install corrections along with the enhancement packages. The methodology concerning corrections has not changed. Therefore, the pure installation of an enhancement package still requires testing activities – even if no business function has been activated yet.


Installation Tools – A common practice of both these scenarios, upgrades and enhancement packages, is the fact the installation procedure can be executed with the transaction ‘SAINT’, just in case you are familiar with this one. For SAP Enhancement Packages, the better way to install is using the ‘SAP Enhancement Package Installer’ which drastically reduces the technical downtime.


To summarize, the aspects explained above reduce hardware costs, lower risk and manual efforts, accelerate the installation of new functionality, and reduce efforts for modification adjustment if compared with a technical upgrade project. The overall installation effort including regression testing is approximately as high as moving on to another Support Package Stack.




Shorter innovation cycles – Once the SAP enhancement package is installed, each business function may be activated separately and as needed by the operating departments. This enables the IT team to schedule new implementations in smaller steps that are easier to handle. Comparatively, temporary peaks of IT projects – as were needed for upgrade projects – are spread into a more even workload and a more constant risk distribution over the time.


Predictable changes – The good thing is – for every business function activated, you will know the affected business processes. This is documented in standardized test case descriptions.

Limited testing – The testing scenarios described in the standard test cases should be included in your end-user test before you go-live with the selected functionality. You may want to use these as testing templates as a baseline for custom test cases which describe custom business processes. It is NOT necessary to do another regression test (across all critical business processes of that system) at that point. It is NOT necessary to make another modification adjustment.


Stability for non-affected end-users – The activated functionality will bring up new fields, reports, business processes, IMG settings, etc… only within the described, limited operational areas of the activated business function. Other end-users, not in these limited operational areas, will not realize any system changes. Thus, allowing them to continue their work without any disruption.


Now you should have the right expectations towards implementing an SAP enhancement package. Please let me know your questions, comments, and what else you are interested in. Your feedback is more than welcome!


Best regards, Doris.

You must be Logged on to comment or reply to a post.
  • Thanks for a very informative blog! At one point, you have stated – “.. the pure installation of an enhancement package still requires testing activities – even if no business function has been activated yet.” – can you please explain this further? As I understand, the new functionality has been separated, and if it is not activated, then why is testing needed?


    • Hello Ashutosh,

      there are two reasons why testing is necessary even BEFORE a business function is activated:

      Reason 1:
      The installation of enhancement packages replaces a number of existing programs by new versions of this program (or object). Every new “program version” can now be executed
      1. either in the “traditional” way (swiched-off mode, so to say) or in the
      2. “new way” (switched-on mode)

      Since customers usually have modifications, they have to adjust these modifications after the installation, and this is usually always followed by a full regression test.

      Reason 2:
      Corrections automatically come along with Enhancement Packages, because each EHP bases on a minimum Support Package Stack. Corrections are not switched – they are delivered as before. I will explain this in more detail in my next blog.

      Implementing corrections has to be followed by a regression test.

      I hope I brought some light into this?

      Regards, Doris.