Skip to Content
Author's profile photo Former Member

Simple checks that can avoid serious issues post patching/ minor upgrades

Over the last years, I was part of the team that undertook various patching and upgrade activities in the SAP landscape. 

In the initial stages, despite meticulous planning, several rounds of brainstorming sessions and a clear project plan, we had always ended up with some serious issues post the installations/ upgrades. And the result was that we always ended up spending lot of effort in resolution and also lost valuable business hours because of such issues.


In the hindsight, at least 95% of those issues were known issues (known to the SAP world) and resolutions/ steps to avoid them available in public domain/ SAP domain.


These made me document a simple check list that can possibly avoid such issues and save lot of time and effort. And let me assure you that this has helped me already to foresee issues, take proactive actions and be able to deliver the patches/upgrades on time without many issues. Most of the items in the check list are all probably known, but it’s important to have them as a checklist so as to not miss it.


Here are the Top Ten checks with some interesting examples:


Check Example/ Remarks
Is the patch that you are going to apply the latest version (n) that is released? [You may want to go for n-1 version rather than the latest version] For e.g., if you want patch SAP EP 6.0 to the latest version SP 25 or if you want wait till SP26 is released (which may resolve some known issues in SP25)
Do you have all the release information (if applicable) concerning the patch downloaded from SAP? SAP’s release documentation/ related documentation provides critical information that should be used when planning patches
Do you have all the related SAP notes (that can impact your patching/ landscape)? [The SAP notes will ensure that all related aspects of the patching are taken care. They may contain fixes to known issues with the releases and specific solutions] In a particular case where we had to upgrade the Oracle Database from to, there were several related SAP notes which suggests running of certain scripts & upgrading of the oracle client also. We faced severe issues because these notes were missed.
Have you searched relevant information from the SDN domain (forum/ other) concerning the patching activities? [A simple search in the forum throws up several similar patching activities/ related issues]. It is also useful to search in other forums. In the case as above, a simple search in the forum like “upgrade from Oracle to” would have thrown up several threads related to the above issues. The idea is that the issues could have been avoided had we known them before hand.
Have you downloaded the patch from the SAP site (or the relevant sites) using the proper target and source stacks. Most of the times we may do this correctly, but is important to ensure.
When you download from SAP market – are the usages (if applicable) selected appropriately? [The usages could be for the various sub components like Mobile, BI etc…] Once, our Basis team had downloaded the patch from SAP without un-checking the irrelevant components for our landscape. This included the “Mobile Infrastructure (MI)” which was not part of our landscape.The whole patching exercise had to be postponed to another day because the patching would not complete – the install, I believe, was trying to patch the MI which was not available and throwing up lot of errors.
For each of the component versions that are available in the download of the patches, have you selected the appropriate OS/ version? For e.g. Solaris on SPARC 64bit or Linux on Power 64bit
Did you request the Side effect reports (if applicable) for the patches in consideration and the components? These reports will enable to proactively consider steps to avoid issues.
Have you patched your Development and Test (QA) systems in the same way as you are considering for the Production? [Here, the differences in the environment are to be considered]. For e.g. there could be differences in architecture that can make us overlook possible trouble when patching production,  there could be some differences in the versions/ patch levels/ customizing, there could differences in the availability of space. In a particular case, our Development/ Test systems had local directories (say not mounted from the NFS), while our Production had directories being mounted from the NFS. This meant that we were unable to see the issue while we patched the test systems and encountered it for the first time in PROD. In another case, our Production systems were in cluster while the test systems were not. This created lot of issues while the production was being patched.
Do you have the rights to perform patching activities? [sometimes we would require certain privileges to perform activities in Production] This may be part of our planning, it is important to ensure that we have enough rights in the production environment before we begin. When we decided to upgrade the TREX application from 6.1 to 7.0, we were stuck because we did not have the root access at the OS level in Production, while we did have in Development / Test systems.


I decided not to extend this list to checks for planning (creating project plans), execution steps, post installation checks etc. as they are not what I intended to blog on. The idea of the blog is to create awareness on the possible areas that need to be looked at before we begin the patching/upgrade exercise.


I welcome readers to contribute to this check list that can help the SAP audience.


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.