SAP Support Package Stack Strategy

SAP Support Package Stack Strategy 

Most customers schedule planned maintenance for each SAP application that is actively used between once and four times per year. This typically impacts all components of the SAP programme in question.

However, the exact frequency of planned maintenance is determined by a number of factors, including:

• The SAP software itself (technical conditions, legal changes, ...)
• The unique scenario you're in (projects, productive status, ...)
• The benefit of being on the most recent support package or patch level, particularly when SAP support is required
• An estimate of the costs of scheduled maintenance.

Setting up a standard rule for determining the best time and frequency for planned maintenance is tough. You must determine what is best in the particular situation. However, we recommend performing planned maintenance at least once a year, preferably twice to four times.

We presume that the newest available support package stacks (SP stacks) are used during proactive planned maintenance, and that the SP stacks used are not older than one year. However, if difficulties arise, we reserve the right to require you to install single support packages or patches that are newer than those mentioned in the SP stack.

Unexpected issues might arise regardless of planned maintenance, and they must be resolved as quickly as possible and with the least amount of work. Various procedures are available for such situations, depending on the technology of the afflicted component and the sort of problem. Correction instructions for ABAP-based tracks can cure problems more locally and precisely, but kernel patches are less specific and, for technical reasons, usually incorporate answers to several issues.

If you plan to upgrade a SAP application or install enhancement packages, you must ensure that the so-called upgrade equivalences are available. Upgrade equivalences synchronise the source and target release's error correction levels. A comparable equivalent support package in the target release is necessary for every support package implemented in the source version; this includes SAP NetWeaver, SAP application, add-ons, and so on. This translates to: An upgrade is only feasible if the destination release's support package level is equivalent to or higher than the source release's implemented support package level. As a result, installing the newest SP stack in the source release without first checking for the availability of the same support package level in the target version is not recommended. As a general rule, no support package level higher than the penultimate SP Stack should be included in the source release. Note #832594 has more information on importing support packages prior to an upgrade.

The General Combination of Planned Maintenance and Specific Corrections goes hand in hand with the General Combination of Planned Maintenance and Specific Corrections.

The SP stack strategy is linked to a general combination of planned maintenance and individual corrections offered in between:

• An SP stack consists of a set of support package tiers for various component versions. Only in extraordinary circumstances should you depart from this mix.
• It's possible that an SP stack contains software components that aren't being used. They don't need to be patched during the implementation of the SP stack unless the employed components have a technical or logical dependency on them.
• SP stacks are scheduled on a quarterly or half-yearly basis, which corresponds to the frequency of planned maintenance. This does not imply that planned maintenance must always be performed every three months. SP stacks can be initially "postponed" depending on the parameters described above if no issues arise that need the adoption of newer support package levels or fixes. The omitted support packages can be applied with the next SP stack.
• SAP HR applications require a greater maintenance frequency than the "standard" SP stack frequency due to legal changes. Between two SP stacks, additional support packages called Country Legal Changes (CLCs) are given.

In general, an SP stack contains the most recent HR support package level available at the time of the SP stack's release. This means that if you begin a planned maintenance period soon after the SP stack becomes available, you will automatically obtain the most recent HR support package. However, if you undertake planned maintenance at a later date, check to see if a new HR support package level is available and implement it to comply with legal requirements.

If necessary, we will use a Release and Information Note (RIN) to notify you about the general release of an SP stack as well as any known issues. SAP HotNews will also be used to communicate critical errors.

Additional side-effects associated with support packages can be viewed directly through the SAP ONE Support Launchpad. More information can be found in SAP Notes: Side Effects and note 2388572.

The SAP Support Portal may have newer support packages or fixes than those defined in the latest SP stack. If there are no special difficulties, however, the general guideline is to employ the mix provided in the SP stack. In the meanwhile, support packages or patches have been prepared for the aforementioned particular scenarios.

Additional support packages may be required for additional installed components (for example, add-ons). They must be manually downloaded from the SAP Support Portal if they are not included in the SP stack download.