Support Package Stack Strategy

Support Package stack strategy in harmony with typical behavior of Support Package application

It has become evident that the majority of customers perform a planned maintenance for each productively used SAP application between once and four times a year. This usually affects all components of the given SAP application.

The actual frequency of a planned maintenance however depends on many factors, like:

  • The specific situation at customer side (e.g. projects, productive status, ...)
  • The SAP application itself (e.g. technical conditions, legal changes, ...)
  • The advantage of already running on the latest Support Package or patch level, especially when SAP support is needed
  • The risk estimation of operating with already known errors (hence incurring unnecessary costs or having to react at short notice)
  • The estimated costs of a planned maintenance

It is almost impossible to set up a general rule for defining the optimal time and frequency of a planned maintenance. You have to decide what is best under the given circumstances. However, we recommend a planned maintenance at least once, better twice to four times a year, in order to avoid the above mentioned risks becoming too heavy - even without arising problems beforehand.

We assume that during the proactive planned maintenance the latest available Support Package stacks (SP stacks) are implemented and that the SP stacks used are not older than one year. Nevertheless, in case problems do occur, we can still oblige you to apply Support Packages or patches that are newer than those specified in the SP stack.

In case you plan to upgrade an SAP application or to implement enhancement packages in the near future, you need to take care about the availability of the so-called upgrade equivalences. Upgrade equivalences synchronize the error correction level in the source and target release.

This means: An upgrade is possible when a Support Package level of the target release is available which is equivalent or higher than the implemented Support Package level in the source release. Thus, it is not recommended to implement the latest SP stack in the source release without verifying the availability of the equivalent Support Package level in the target release prior to the upgrade procedure.

For every Support Package implemented in the source release a corresponding equivalent Support Package in the target release is required; this includes SAP NetWeaver, SAP application, add-ons etc.
As a rule of thumb, the source release should not contain a Support Package level higher than the penultimate SP Stack.

Independent of a planned maintenance, unexpected problems can occur and need to be solved as quickly as possible and with minimum effort. For such situations different mechanisms are available, which depend on the technology of the affected component and the type of problem. Correction instructions for ABAP-based tracks can resolve problems relatively locally and specifically, while kernel patches are less specific and - due to technical reasons - mostly include solutions for several problems.

Hand in hand with the general combination of planned maintenance and specific corrections

The SP stack strategy goes hand in hand with the general combination of the planned maintenance and specific corrections that are provided in between:

  • The quarterly or half-yearly frequency of SP Stacks complements the frequency of planned maintenance, although this does not mean that planned maintenance must always take place in quarterly intervals. Depending on the factors mentioned earlier, SP Stacks can initially be ‘postponed' provided that there are no problems that require the application of newer Support Package levels or patches. The Support Packages that are omitted in this way can be applied with the next SP Stack.
  • The SP Stacks provide pre-set combinations of Support Package levels and should only be deviated from in exceptional cases, for example, if the specific problem can only be solved in this way. Variations should be kept to a minimum and as local as possible.
    Subsequent Support Packages can of course be applied preventatively, if the general circumstances of a problem exist and it is feared that the problem will occur. In many cases, however, a local correction will be possible, for example, using the correction instructions of an SAP Note or by applying a patch.
  • Due to legal changes, SAP HR applications require a higher maintenance frequency compared to the "normal" SP stack frequency. Therefor, additional support packages or Country Legal Changes Packages (CLC) are provided between two SP stacks. Usually, a SP stack contains the latest HR support package level at SP Stack release date. Customers starting a planned maintenance phase right after SP stack release date will also receive the latest HR support package. Customers starting planned maintenance some time later should implement the latest available HR legal changes (if not yet implemented) along with the SP Stack to meet legal requirements.
  • Software components contained in an SP stack that are not used productively do not need to be patched during the implementation of the SP Stack, unless a technical or logical dependency to the used components exists.
    However, the Support Package or Patch levels of used components may not fall below the combination required by the SP Stack.

If unexpected problems relating to a SP Stack have been identified, these will in most cases only affect a few amount of customers. It is therefore not absolutely necessary to change the general recommendation for most customers and hence intervene in the planned maintenance schedule.

Instead, SAP will use a Release and Information Note (RIN) to inform all customers about the general release of a SP Stack and about known problems with high priority, if there are any. Critical errors would also be communicated as before via HotNews Notes.
Information about additional side effects related to Support Packages of any kind can be requested using a special reporting tool in the SAP Support Portal (Quick link / >> My Support >> KnowledgeBase >> Side Effects >> Side Effects of SAP Notes).

Usually, the general recommendation of a SP Stack will remain the same for about three to six months and if there are any problems, these will be communicated accordingly. By focusing on certain combinations of Support Packages in a SP Stack, it is easier to detect and resolve potential problems much earlier. If a patch would be considered as relevant for all customers it will be included in the SP Stack definition.

Deviations from the Support Package levels of a SP Stack are similar in nature to SAP Notes and patches and should only be used when there are problems or in special cases (for example, for legal changes or for customers in project or implementation phase). This also applies to Support Packages or patches created after the release of the SP Stack which will become part of a subsequent SP Stack.

There might exist newer Support Packages or patches at SAP Service Marketplace than defined in the latest SP Stack. If there are no specific problems, the general recommendation nevertheless is to use the combination specified in the SP Stack. Support Packages or patches created in the meantime are intended for the above-mentioned special cases.

Additional installed components (e.g. add-ons) may need additional support packages. In case they are not included in the SP stack download, they have to be downloaded from the SAP Service Marketplace manually.