Preparation for SAP upgrade or support package

Support package

This blog explains about preparation you can do for SAP upgrade of support package.

Questions that will be answered are:

  • Where to find support package schedule?
  • Where to find version information on upgrades?
  • Do I need to do delta sizing for upgrade?
  • Do I need to perform extra preparation steps for an S4HANA upgrade?
  • Determining the version: why not to use the latest minus one?

Latest available main version for upgrade

For the latest available version you can check the SAP product availability matrix site. This is also know as the SAP-PAM.

After finding the right product on the first tab you can see the current release details and end of support date.

PAM details release and support dates

On the second tab you see the upgrade paths that are supported:

PAM details upgrade paths

In the middle the target version. On the left hand the versions from which you can upgrade. To the right are even higher versions you can upgrade to.

Also check here the support Linux versions. You might be surprised: you often need to upgrade the operating system first before you can upgrade your application.

Same for the HANA database or database version: newer releases of functional software will force you to upgrade your database as (or upgrade database first).

Latest available versions of support packages

The latest available versions of support packages are published by SAP on the SAP support package stacks page. On this page click on the SAP support package stack maintenance schedule link to download the latest version of the schedule.

Support package version: minus one or latest?

In many companies there is a policy to never take the latest version of a support package. The line of thinking is: let other people solve the bugs of SAP first.

Current delivery of ABAP support packages is quite good. And the frequency is not so high as in the past. For ECC about 2 to 3 support packages per year are released (as compare to 6 to 9 in the past in the 4.6 ages).

In stead of taking minus one, you can also consider this rule: at point of go-live make sure that the support package is at least released 3 months ago. This will counter the risk of having an issue which is not discovered by anyone else before.

People using the rule minus one without thinking should not be trusted. It is like going to Apple and insisting on Iphone 11, because you don't trust Iphone 12 and use the rule minus one...

Delta sizing

Delta sizing for support packages is not needed. Delta sizing for an upgrade might be required if:

  • Upgrade crosses multiple versions (for example upgrade from Netweaver 6.20 to Netweaver 7.51)
  • Upgrade is including a new database (for example migration to HANA database)
  • Specific upgrade manual is specific about delta sizing (for example the upgrade from SAP solution manager 7.1 to 7.2 is specific enough to carry out delta sizing)
  • For ECC to S4HANA conversion

Custom code

For analyzing custom code before the upgrade you can use the CDMC toolset. For more information read this blog.

Also use the clone finder to find clones. You might need to delete the clones or adjust them after the upgrade. More information on the clone finder tool can be read in this blog.

Releasing transports and cleaning up transport pipeline

For both support package and upgrade releasing transports is a technical must. It is wise to start a few months before already cleaning up the transport pipeline (transports that are old and not released in development system, transports that are imported into quality environment, but no imported in productive system).

Check the clients

Check if you still have client 001 or 066. If yes, consider deletion. See dedicated blog.

BI queues

During the upgrade all BI queues must be empty. Check it upfront and/or delete them. For more information on BI queue deletion, read this dedicated blog.

Inactive code and data dictionary objects

Before upgrade or support pack can start all code and data dictionary objects must be activated or deleted.

In some rare cases there are inconsistencies in the data dictionary objects. Check table DWINACTIV in this case.

Side effect report for support packages

Per support package SAP keeps track of the unwanted side effects. OSS note 2388572 explains you how to retrieve them for your support package. Best to scan the side effects and apply the ones you think are needed.

For upgrades the side effects list is too large: here you simply need to test and fix any issues encountered.

New functions

After the upgrade you can start to use new functions. Some main functions are listed in the SAP help pages. The more unknown small features are listed by SAP in the SAP improvements finder xls. This xls has 2 tabs: first with the most recent and second with the long list of improvements since 2014. Per improvement you need to check pee-conditions of release and support package, but if you upgraded to recent version, most of the improvements will be installed. Some improvements are always active, some need extra activation steps. This is documented per improvement item.

New security parameters

After an upgrade (not support packs) new security parameters can be introduced to SAP. Prepare already which ones might impact you. For S4HANA upgrades and new security parameters read this dedicated blog.

S4HANA upgrade preparations

If you are upgrading your existing S4HANA upgrade, read this dedicated blog on S4HANA upgrade preparations. And run the readiness check: read this blog.

S4HANA conversion preparations

An upgrade from ECC to S4HANA requires a different approach. In this upgrade also the simplification items and custom code migrations must be done. Read more in this dedicated blog.

For more S4HANA conversion preparations, read this blog.

Aftercare after upgrade

For aftercare after upgrade or support package read this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.