Skip to Content
Author's profile photo Former Member

n-1 Release Upgrade Approach

Hello everyone, this blog post details a practice/approach to upgrading an SAP product/any product for that matter. I shall be referring all examples in this blog to the SAP portal as it is where I have the majority of my SAP experience.


SAP portals have three types of delivered updates provided from SAP. They are Enhancement packs (EHP), Support Packs (SP), and Patch updates. An EHP will usually offer increased functionality to the portal, whereas a SP will usually fix issues with the current components installed on the system. Patches are applied to individual components within a specific SP level. For the purpose of this blog, I shall be providing examples referring to patches and SP upgrades.


Drawing on past experiences it is far safer to upgrade a system to the n-1 release (n being the current release available) of a SP rather than moving to the latest package available, especially if the latest SP is relatively new to the market. Upgrading is not always a question about what issues will be fixed, but also what new issues can be introduced.


If there are urgent needs to fix very critical issues addressed in a recent SP, issues that are having a high impact on business activities, upgrading to the current SP may be ideal in this case, but would need to be tested thoroughly to ensure that no existing functionality has broken as a direct result of the upgrade, placing the system in a worse state. I would also suggest (ideally) creating a production copy of the portal on a system outside of your usual transport track, and deploying the upgrade to this isolated instance, so that any issues can be encountered and solved separately, while still allowing development to occur on the usual transport track (possibility of workaround).


When dealing with patch upgrades, it is usually a lot safer to install the latest available for a given SP, as they are fixing issues pertaining to an isolated portal component, and therefore, have a much smaller domain to introduce new issues. They are also usually easier to rollback in a system, where in most cases, deploying the older component will perform an effective rollback. SP upgrades are much more difficult to rollback, where usually a restore from backup is required.


I hope this post may help some people out there that may need some guidance about an approach to upgrading a SAP portal, or any product for that matter. At the end of the day, you do not want to turn your career or company into beta testers for the vendor.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Thanks for the very short and brief article.