Most 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:
It is difficult to set up a general rule for defining the optimal time and frequency of a planned maintenance. You must decide what is best under the given circumstances. However, we recommend a planned maintenance at least once, better twice to four times a year.
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 occur, we can still oblige you to apply single support packages or patches that are newer than those specified in the SP stack.
Independent of a planned maintenance, unexpected issues 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.
In case you plan to upgrade an SAP application or to implement enhancement packages, 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. 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. This means: An upgrade is only possible when a support package level of the target release is available which is equivalent or higher than the implemented support package level of 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. As a rule of thumb, the source release should not contain a support package level higher than the penultimate SP Stack. More information regarding importing support packages prior to an upgrade can be found in note #832594.
The SP stack strategy goes hand in hand with the general combination of the planned maintenance and specific corrections that are provided in between:
In general, an SP stack contains the latest HR support package level that is available at the release date of the SP stack. This means: When you start a planned maintenance phase right after the availability of the SP stack, you will automatically receive the latest HR support package. But: When you perform the planned maintenance at a later point in time, check if a new HR support package level is available and implement the same to meet legal requirements.
In case needed, we will use a Release and Information Note (RIN) to inform you with high priority about the general release of an SP stack and about known problems. Critical errors will also be communicated via SAP HotNews.
Information about additional side-effects related to support packages can be seen directly via the SAP ONE Support Launchpad. You will find more information under Side Effects of SAP Notes and in note 2388572.
Newer support packages or patches than defined in the latest SP stack might be available in the SAP Support Portal. Nevertheless, the general recommendation is to use the combination specified in the SP stack if there are no specific issues. 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 must be manually downloaded from the SAP Support Portal.