upgrade – Saptechnicalguru.com

Upgrading SAP Focused Run

All new functions and innovations for SAP Focused Run are delivered in either upgrades or feature packs. This blog will explain how to plan and execute upgrade for SAP Focused Run.

Questions that will be answered in this blog are:

What is the SAP Focused Run release strategy?
How to prepare for the SAP Focused Run upgrade?
How do I execute the SAP Focused Run upgrade?

Release strategy of SAP Focused Run

In the SAP Focused Run overview document created by SAP there is one slide containing the SAP Focused Run release strategy:

All new functions and innovations are delivered in either upgrades or feature packs.

Preparations for SAP Focused Run upgrade

First look up the specific upgrade OSS note. In case of upgrade to Focused Run 4.0 SP02 these are OSS notes SAP Note 3374888: Focused Run 4.0 FP02 and 3394504 – SAP Focused Run 4.0 Feature Pack 02 – Update Preparation and Postprocessing Documentation.

In this note you will find:

HANA database version needed
Needed versions of the SDA (simple diagnostics agent)
Scenario specific pre and post actions required
Updates to authorizations in SAP Focused Run
Updates to authorizations in the connected systems
Pre upgrade and post upgrade actions to be performed

The HANA database can be upgraded before the actual upgrade or can be combined with the upgrade. The same applies for the SDA agent.

Best practice is to execute the HANA and SDA upgrades before. Upgrade your Focused Run test system first, leave the versions there for a few weeks to prove stability, then deploy on productive Focused Run system.

In case of changes to authorizations in the connected systems, you can already update these before the upgrade.

In case you use custom descriptions in the metrics, you must download them before the upgrade and upload them again after the upgrade. More information in OSS note 3077162 – Backup and Restore of MAI Custom description BEFORE and AFTER system Update/Upgrade.

ZDO upgrade option

As of Focused Run 3.0 you have the choice to go for a ZDO (Zero Downtime Option) upgrade to reduce the downtime of the upgrade.

Read the following notes carefully before deciding to go for this option:

Executing the SAP Focused Run upgrade

Start your upgrade first on your SAP Focused Run development system and write down all the steps you execute. You will need to repeat all steps in your productive system later on.

During the technical upgrade, you will have to perform with the SUM tool, you will need to execute the SPDD and SPAU technical upgrade actions. Store the actions in transport to be used in productive upgrade. After SPUA is done, also apply the updated collective notes listed in the central note 3374888 – Release Information Note for SAP Focused Run 4.0 FP02.

After the technical upgrade has been completed, follow and document carefully all the steps in the OSS upgrade note. For example running extra tasks lists, programs, redo SSI for JAVA, etc.

It can also be you come across items and issues that are not documented in the OSS note. Please write them down in your own runbook for production. When upgrading to SAP Focused Run 3.0 we found that the standard jobs are switched to the technical job repository SJOBREPO (since the 3.0 ABAP stack is based on the S4HANA 1909 version).

Apply all collective notes for all functions you are using. The collective note numbers are listed in the Release Information Note.

After the documented steps, update the authorizations in SAP Focused Run to get the new tiles for new functions available.

Rerun the task lists for the initial setup in STC01 (SAP_FRUN_SETUP_FOUNDATION and SAP_FRUN_SETUP_USECASE) with the variants of the use cases that you are using.

Update the monitoring content according to OSS note 2991255 – Manual content update for FRUN-CONT 300 in SAP Focused Run (FRUN-CONT). For the steps in detail, read this blog.

Check in the upgrade manual if any SSI needs to be redone. This is often the case with JAVA systems.

Finally when all actions are done, refresh your browser cache and backend FIORI cache (follow all steps from this blog).

Testing

Before deploying the Focused Run upgrade in production, you must test all your functions in the Focused Run development system. It is very helpful if you have a set of documented test cases that you can easily repeat each upgrade. With testing first focus on testing the current functions you are using. In a later stage you can explore, activate and test new functions.

While testing you will find issues. Solutions are normally:

Updates in authorizations
OSS notes to be applied
SICF services and Gateway services activation
Forgotten step in the activation

Capture all fixes in either transports or in your runbook.

If you still have key issues with bugs, you will need to raise a message to SAP.

<< This blog was originally posted on SAP Focused Run Guru by Frank Umans. Repost done with permission. >>

Reducing S4HANA upgrade downtime: ZDO, zero downtime option

Next to nZDTM (near zero downtime) there is now a new option called ZDO (Zero Downtime Option). This new option even further reduces the downtime of an upgrade to a newer version.

The ZDO option is primarily available for S4HANA upgrades (for example upgrade from S4HANA 2020 to S4HANA 20201), but is also available for products based on the same ABAP version, like SAP Focused Run.

How does the ZDO work?

ZDO is the next evolution of the shadow system. Now not only the code is duplicated, but also the data and settings. This is done in a so called bridge system. Postings are duplicated in the main and in the bridge system.

In this way the business downtime is further reduced:

A ramp down, restart and ramp up is still required.

Technical background

All the technical background and restrictions are listed in OSS note 2707731 – Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA and training ADM330e.

The note states as well that the basis person must have followed the training ADM330e before the customer is allowed to perform the ZDO option. The option is released for customer, after training. Why is training required? The option is technically very nice, but also complex (updates are done in both the old and new release). The restrictions and execution must be done correctly and in high quality fashion. This cannot be done without proper training.

You should also do a full dress rehearsal of the ZDO upgrade including people posting data in the system during the bridge phase.

The most common use case is an S4HANA upgrade. But the ZDO upgrade can be used in other used cases as well. For example SAP Focused Run can also be upgraded with ZDO. There are special notes, instructions and restrictions: 3269755 – SAP Focused Run 4.0 Support Package 00 – Update Preparation and Postprocessing Documentation. Check the notes carefully for your specific use case.

Memory

ZDO will use more memory since it will have 2 database schemas. Check and monitor this carefully on your test upgrades and extrapolate to production. A ZDO upgrade does require a test run on full production copy size.

Execution of ZDO issues

During execution of ZDO, you will get far more issues and errors as compared to the downtime optimized scenarios. For this reason, the first ZDO upgrade you execute should be on a sandbox system. Preferably as a copy of your productive system. You will learn a lot of things on the sandbox upgrade, to make the real upgrade later on go smooth.

Addons

Some addons might block the upgrade. Some can still be allowed in the upgrade, but cannot be upgraded along with the upgrade and have to remain at the same version. At the bottom of note 2707731 there is an always up to date excel file containing the Allow List for addons.

OSS notes in ZDO checks phase

During the prechecks and later even in shadow system build up, SUM will come with list of OSS notes that need to be applied in main system or in shadow.

For the real upgrade: already apply all the notes on the development system before the upgrade and transport these to production.

Database inconsistencies

All database inconsistencies must be resolved. Repair via SE14, see blog.

BI system settings

ZDO is currently only supported for embedded BI scenario. This might mean you need to get help from your BI team on de-activating some BI content.

To find out what is blocking: go to transaction SE24 and enter class CL_RS_UTILITIES. Start the test tool and launch method GET_SYSTEM_SCOPE. If the answer is DATA_WAREHOUSE, this will block the upgrade. Use your debug skills (or ask ABAP developer) to see which items are throwing roadblocks. Then de-activate or delete that content (with help of your BI team).

Old HANA transport containers

Some old HANA content might block the ZDO upgrade. Read more on this in OSS note 2982320 – HTA for HDI: Error in execution of HDI call: insufficient privilege. Steps to solve: repair privileges on the ABAP HANA user. Run program SCTS_HTA_ADMIN in repair mode.

Background

Background blog from SAP: read here.

Set up parallel landscape for upgrades and conversions

When doing a conversion from SAP ECC towards S4HANA you will face a long period where the system is frozen for changes. In most cases business changes still need to continue. For this situation setting up a parallel landscape is a good solution. A parallel landscape might be required for other major upgrades or large data conversions.

How does a parallel landscape work?

How does the parallel landscape work? Initially we have a DEV, UAT and PRD system landscape where transports move from DEV to UAT to PRD system.

With a parallel landscape we install a second development and UAT environment of the same version as the production system. Let’s call them DE2 and UA2.

Now we can start to convert and upgrade the DEV and UAT system to the new target version.

Now 3 development moves are happening:

From DE2 to UA2 to PRD the changes that business is needing (automated support via STMS).
From DE2 to DEV system there is manual synchronization required (dual or double maintenance): all code changes and settings need to be redone (or in some cases even redeveloped).
Transport from DEV to UAT (automated support via STMS): here is where you make your future fixes and developments and move these from DEV to UAT system for testing.

Conflicts between points 2 and 3 often need manual resolution.

At the go-live moment, all transports are imported into PRD from the UAT environment. After live the DE2 and UA2 system can be decommissioned.

Costs of a parallel landscape

Don’t underestimate the costs of a parallel landscape:

Your infrastructure for Development and UAT system will double.
If you are unlucky you also need parallel landscape for connected systems like BI and SCM.
You need basis resources to install, setup, monitor and update the extra systems.
More transports to monitor and to keep track of.
The double maintenance is a lot of work to be done manually. You need also extra person to keep track of administration that the double maintenance is done properly.

Tooling might exist to help, but in practice it cannot cover too many use cases. So don’t get your hopes too high on them.

Alternatives for parallel landscape

There are alternatives for a parallel landscape:

Accept the freeze period
Set up an emergency repair box: copy productive system to a special system for emergency repairs only

These alternatives can be an option for smaller landscapes and organizations.

S4HANA upgrade preparations

When you are already using S4HANA, you will still want to regularly upgrade to the newest version. This blog will explain the preparation steps for a next upgrade.

If you are looking for information about S4HANA conversion (from ECC to S4HANA): read this dedicated blog on S4HANA conversion preparations.

Questions that will be answered are:

What do I need to check as part of an S4HANA upgrade?
Where do I find information on the HANA database revision upgrade?
Do I need to run the simplifications check again?
Do I need to check my addons again?
How can I check for differences in SAP FIORI apps?
How can I reduce downtime for my S4HANA upgrade?
How can I know about changes to security parameters after the S4HANA upgrade?
If I am upgrading an existing S4HANA system to a higher version, do I still need to do the simplification items?

HANA database revision

For each S4HANA upgrade, first you must apply the minimum revision published by SAP before you can start the upgrade.

You can apply this revision already in your running system as well.

HANA DB revision usage for S4HANA can be found in this OSS note: 2655761 – SAP S/4HANA – restrictions and recommendations regarding specific revisions of SAP HANA database for use in SAP S/4HANA.

Add ons

For each upgrade, you need to validate that the addons you use are already released for your target upgrade version.

Generic OSS note is 2214409 – SAP S/4HANA: Compatible Add-Ons. This will refer to version specific OSS note you must read.

Simplification items

For each upgrade, you must update the TCI note for the simplifications items and run the checks. See blog. So you still need to do simplification items between the versions!

For an ECC to S4HANA conversion this list is long to very long (can contain over 100 items). For an upgrade from S4HANA lower to higher version, the list is typically only 10 or less items.

FIORI apps impacted by the upgrade

FIORI apps can change between versions. Older apps are replaced by new ones. You might need to act on this if the apps are used by the business. To get a list of SAP FIORI app differences, follow the instructions from this SAP blog.

Readiness check

Also for S4HANA upgrades from older to newer S4HANA version, you can run the readiness check. Read more about it in this blog.

SLT triggers

If you are using SLT triggers, also check this OSS note carefully: 2755741 – Potential Impact of SLT During SAP S/4HANA System Conversion / Upgrade of S/4HANA System. In some cases it is better to drop the triggers and recreate after the upgrade.

Custom code checks

A quick check on the use of unreleased SAP objects in custom code can help to avoid upgrade issues. To execute the run, check this blog.

Downtime reduction

An S4HANA upgrade can take a long time to run in productive system. It can take a complete day to execute the upgrade on production.

During your S4HANA upgrade you should really spend time on downtime minimization.

First step is to determine the maximum downtime you are allowed to have by the business. If you have this timing, use the first sandbox and development system conversions to measure the expected downtime as first estimate. You can use the downtime recording from the SUM tool. But you have to add time for many more elements:

Graceful shutdown
Transport imports after the upgrade
System validation before startup
Graceful startup

Test the actual downtime on your acceptance system. If required, you can also create extra copy of production to a special conversion upgrade dress rehearsal system to practice the downtime and your optimizations.

Tips for downtime reduction:

Check the SUM options for downtime reduction
Check the downtime optimization app from SAP: see this blog
Consider to include customer transports in SUM: see this blog
Consider to contact SAP if your system is very large and you outage window requirements are not met by the actual times. SAP can offer tailored services to further reduce your downtime. These services are expensive, but can be worth the money to help your project meet the business maximum downtime requirements

Security parameter changes

After S4HANA upgrade, there are new and updated security parameters. Read more on this topic in this blog.

SAP best practices

SAP has an excellent best practice document “Upgrading SAP S/4HANA: Why, How, and Best Practices”.

SAP downtime optimization app

SAP has create an app for analyzing the downtime for a SAP system upgrade or support package.

Questions that will be answered in this blog are:

How to use the SAP downtime minimization app?

Full references of SAP downtime minimization app

The full specification of the SAP downtime minimization app is maintained in SAP OSS note 2881515 – Introduction to the Technical Downtime Optimization App and on this SAP blog.

Using the SAP downtime minimization app

The app is hosted at SAP and can be reached on this URL: https://launchpad.support.sap.com/#/downtimeoptimization. When you start you come to the intro screen:

You start with the upload button. Here you can upload the UPGANA and APPLANA xml files:

After uploading, you need to wait 3 hours.

When you come back the result should be there:

Now you can analyze the SUM runtime uptime and downtime phase timing (this is tool time without idle time). There are hints given by SAP on which parts improvements could be made.

Reducing downtime

For reducing downtime, you can read the blog on including customer transport in SUM upgrade procedure as one of the means to reduce the downtime.

Also read OSS note 2351294 – S/4HANA System Conversion / Upgrade: Measures to reduce technical downtime, which contains many hints for downtime reduction.

SAP upgrade SPAU and SPAU_ENH handling

At the end of each upgrade or support package SPAU and SPAU_ENH handling is required.

Questions that will be answered in this blog are:

How to execute SPAU processing?
What is SPAU_ENH?
Where to find more background information on SPAU?

SPAU processing

General information on SPAU processing can be found in OSS note 1970888 – How To: SPDD/SPAU handling during the Update/Upgrade.

When you start transaction SPAU it will ask for a Protocol Title. Give it a meaningful name (background information on the protocol is in OSS note 2497863 – A protocol has to be created before SPAU/SPDD can be executed):

Now you enter the main SPAU screen. The first action to do is to push the button Prepare Notes:

This will start a batch job to download latest versions of the OSS notes and will check if they are relevant for your support pack or upgrade. You can monitor this job in SM37:

For a support pack this jobs can take up to 30 minutes. For an upgrade of ECC on large system it can easily run for 4 hours or more.

After the notes download is done SPAU has 3 tabs:

Notes, with assistant and without assistant. For each tab make download or screen shots of the items before starting with SPAU handling. For each item record your action for future reference. If anything is wrong with the note or ABAP object, you can refer back to this recorded decision.

OSS notes processing

First start with the OSS notes processing. Complete all OSS notes before proceeding to the next tab.

The processing sequence is top down: older OSS notes first, then work down all the list.

In principle, you want to return as much as possible to standard SAP. But be careful: the older OSS notes might be valid modification notes which need to be re-applied after support pack or upgrade. Check with these ones with the functional team.

Old modification OSS notes can give a warning like this before you Reset them to original:

Some OSS notes might give download issues:

In some cases the note might not even be available any more on support.sap.com. Check it there. If not available, check if the content can be ignored.

Some notes might give issues with content delivery event:

Check on support.sap.com if the note is still present. Check if the content can be ignored.

Some notes might be locked:

Most likely root cause: in SPDD processing sometimes you have to process OSS notes as well, and have to repeat in SPAU phase. In this case, release the SPDD transport from client 000 and redo the action in SPAU.

If you re-enter SPAU later (next day), you might encounter this screen:

In this case choose Continue with Current Protocol.

With modification assistant

Proceed with the tab With modification assistant only when the Notes tab has been processed. There might be some note items left due to the issues mentioned above. When agreed to ignore, you can proceed with the With modification assistant tab.

Reminder: download the items and record your decisions.

For each item you need to decide to Reset the object (return to standard SAP), or took fully keep the modification, or to do a manual adjustment. SAP can make guided proposals in this section.

It is an expert job to make the right decisions. Never let junior staff deal with this part. And when you do, you will regret it later on. It can take a huge amount of time to discover the issues and find out it was because of wrong handling in SPAU.

Without modification assistant

After you have completely done the With modification assistant tab, move on the to Without Modification tab.

Here the same processing as With Modification Assistant. SAP will not make any suggestions. Same expert warning as above.

Checking and activation

The other 3 tabs in SPAU (deletions, migrations and translations) are optional. Process as much as you can:

After SPAU has been done, goto SE80 and make sure that all objects are activated. If not activated, process each inactive object.

Never report back to the basis team to finalise SUM upgrade if you have inactive objects left. On older releases, when SUM is finalised and you still have inactive objects, you need to call off object keys.

SPAU_ENH

After SPAU, you are not yet done. You need to start SPAU_ENH transaction and take care of all the enhancements (explicit and implicit):

OSS note 2584912 – How to work with SPAU_ENH contains a word manual with tips and tricks.

With an S4HANA upgrade, you will regret the implicit enhancements. The code were they were applied to might simply have disappeared.

Including usage data

In newer versions of S4HANA SPAU processing, you can include SUSG usage data to make SPAU handling easier. Based on usage you can more comfortably decide to return an item back to standard SAP.

TRDIR and TADIR issues

For TRDIR and TADIR issues during upgrades, support packages, read this dedicated blog.

Finding not adjusted items quickly

Run program RS_FIND_NOT_ADJUSTED_OBJECTS to find out quickly which objects have not yet been adjusted. See also OSS note 2742627 – Display of objects still to be adjusted.

Bug fix and reference OSS notes

Reference OSS notes:

Bug fix notes:

Custom Z code

Custom Z code is not part of SPAU handling. This you do after the upgrade.

For S4HANA you need to do custom code adjustments. Read more in this blog.

Further upgrade post-processing

Pending on your use of functionality more upgrade or support package post processing might be required. Read this dedicated blog for more details.

SAP upgrade SPDD handling

When upgrading any SAP system, the data dictionary objects changes done to standard SAP will have to managed. This is done in the SPDD phase of the upgrade.

Questions that will be answered in this blog are:

How to logon to the shadow system?
How to process the SPDD items?
Why is it important to document the SPDD items?

This blog is followed by special blog on SPAU handling.

Logging on to the upgrade shadow system

Logging on to the upgrade shadow system to perform the SPDD processing can be done in two ways:

Create extra SAP GUI entry based on the data from the SAP basis team
Via SM59 connection SAP_UPGRADE_SHADOW_SYSTEM

In SM59 goto the RFC connection SAP_UPGRADE_SHADOW_SYSTEM. Now press the button Remote Logon:

As processor of SPDD, the basis team will need to create your account in the shadow system and inform you on the password.

SPDD processing

Once logged in to the shadow system, start transaction SPDD:

First start with the With Assistant tab and handle all items, before moving to the Without Assistant tab.

Before starting with any processing, make screen shots/downloads of both tabs. Later when processing the SPDD, write down in any way the decisions you have made. Typically the first upgrade (and SPDD) is done on a sandbox system. Also write SPDD decisions down on the sandbox. If anything appears not ok, you can still do the right thing on the real development system.

The SPDD has to be save in one single transport. This transport will be re-used by basis team from the development system for further on upgrades. This tool (SUM tool) can handle only 1 transport. If there were more transport requests created, merge them to one ( use Include objects functionality) and mark it for transport via Utilities -> Assign Transport in SPDD/SPAU.

SPDD with assistance

On the SPDD with assistance, per item first select the option Compare Versions:

This overview is normally too big to analyse. Press the button Delta display to see the differences:

Based on the content you have to decide to:

Reset (reset back to standard SAP)
Adjust (make you own changes)

This decision is not made in the delta screen, but back in the main SPDD screen. Finalize all the items with assistance, before proceeding to without assistance tab. Record all you decision.

SPDD without assistance

Now proceed on the SPDD tab without assistance:

Red items can only be reset to standard SAP.

For yellow, green and white items there are 3 options:

Reset (back to standard SAP)
Adjust with proposal
Adjust (manually)

A proposal can be accepted or adjusted:

Process each item in the list.

Final checks on SPDD

Before reporting SPDD complete, first check in SE80 that there are no inactive objects left:

If any inactive object is left: activate it. Solve all issues.

Under no circumstance leave issues that DDIC objects cannot be activated. The further on SUM processing will stop due to this inactivation, and you have to redo again till this point, and still have to solve this issue.

Check at the end that all SPDD items are done:

If the list is not empty, discuss with your basis team, before concluding if SPDD is done.

This is reason why you need to create screen shots/download the list in the beginning: it is gone now.

TRDIR and TADIR issues

For TRDIR and TADIR issues during upgrades, support packages, read this dedicated blog.

Background

More information can be found in OSS note 1970888 – How To: SPDD/SPAU handling during the Update/Upgrade.

Interesting is also OSS note 2286852 – SPAU/SPDD: Display report for reset candidates.

Bug fix and explanation notes

Bug fix and explanation notes:

S4HANA upgrade sizing

This blog will explain options and tools you have for S/4HANA sizing for both new installations as well as upgrades.

Questions that will be answered are:

How can I execute S/4HANA sizing?
How do I execute the memory sizing for upgrading existing ECC system on non-HANA database to S/4HANA?
How do I execute CPU sizing for S/4HANA?
How do I execute disc storage sizing for S/4HANA?

Executing S/4HANA sizing

For both greenfield and existing ECC systems the SAP specific quicksizer for S/4HANA can be used: S4HANA quicksizer, then launch the tool from that page:

For existing system you can pull data from existing system for greenfield you have to take either existing numbers from legacy system or input from project them.

The term quick sizing can be bit misleading. The tools is nowadays pretty advanced and requires quite some input.

How to fill the quicksizer is explained in OSS note 2467172 – How to size Fiori applications based on number of users.

Memory sizing for upgrading existing system

SAP has delivered a tool to help in sizing memory for S4HANA for upgrading an existing system. In your current ECC system you need to apply OSS note 1872170 – Business Suite on HANA and S/4HANA sizing report. This will deliver ABAP report /SDF/HDB_SIZING. You test this on development system and transport it to production for productive run.

Best to run this in background. You can then get the results in the spool of the batch job.

The results give an as good as possible estimation of memory sizing after the database conversion.

CPU sizing for S/4HANA

More details on CPU sizing can be found in OSS note 1793345 – Sizing for SAP Suite on HANA.

Disc space sizing for S/4HANA

Disc space storage sizing for S/4HANA can be found in extensive document on SAP site.

OSS notes

Before running the /SDF/HDB_SIZING program it is best to update it with the most recently available updates: 3104284 – HANA memory Sizing report – Advanced correction 15 or higher, 3470136 – HANA Memory Sizing Report – Advanced Correction 21 and any higher correction.
Also apply this note: 3125526 – Report /SDF/HDB_SIZING_CLEAN cannot use dynamic variants.

Preparation for SAP upgrade or 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.

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

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.

Aftercare for SAP upgrade or support package

This blog will explain the normal aftercare that needs to happen after an SAP system is upgrade or has been patches with support packages.

Questions that will be answered:

What is the normal processing sequence in SPAU?
What is the new SPAU_ENH transaction?
Which aftercare is needed when using embedded search via TREX or HANA?
Which aftercare is needed for the authorization team?
What are the general sanity checks after an upgrade?
How to regenerate SAP_ALL and SAP_NEW?
How can I check for new or altered security parameters?
What other things to do after upgrade?
SEGW issues after upgrade, how to solve them?

SPAU processing

For extensive explanation on SPAU, read the dedicated blog. The below is a summary.

When starting transaction SPAU in a netweaver 7.50 or higher system the screen will look as follows:

First thing to do is to hit the Reset OSS notes button or Prepare OSS notes button (the name can differ bit per version):

This will download all OSS notes again and automatically mark the obsolete ones and will remove them from the list. Wait until the batch job doing this job for you is finished. This will save you a lot of time.

In a 7.50 or higher system look at OSS note 2532229 that solves a bug with notes in adjustment mode.

Second step is to process all the OSS notes. Don’t start the other activities until the OSS notes are done.

Third step is to process the tab With Assistant. Only when this is done continue with the tab Without Assistant.

The steps Deletions, Migrations and Translations are optional, but best to do as well. Deletions can be many, but here you can select all and reset to SAP quite quickly.

SPAU_ENH to process enhancements

Often forgotten is the post processing with transaction SPAU_ENH.

If there are changes in enhancements made by SAP conflicts with customer implementations can occur. SPAU_ENH will list them, and you can process them. If forgotten the customer implementation might not be called, which can lead to functionality giving errors.

In rare cases you will need to regenerate the enhancement spots via program ENH_REGENERATE. See OSS note 2507482 – ENHO: After System Upgrade, BADI_SORTER for BAdI Implementation is not being triggered:

RTCCTOOL post processing

After any upgrade/support package the basis person must run the RTCCTOOL program. This will check and list any needed updates.

In almost all cases the actions behind the button Addons&Upgr must be triggered by the basis person.

DMIS plug in OSS notes

If you are using the DMIS plugin for SLT, then you need to run the DMIS note analyzer program(s) again after the support package or upgrade. More information: read this blog.

Scenario	Report name
Object Based Transformation (OBT)	CNV_NOTE_ANALYZER_OBT
ABAP Integration for SAP Data Intelligence (DI)	CNV_NOTE_ANALYZER_DI
S4HANA Migration Cockpit (MC)	CNV_NOTE_ANALYZER_MC_EXT
SAP Landscape Transformation (SLT) Replication Server	CNV_NOTE_ANALYZER_SLT
Near Zero Downtime Technology (NZDT)	CNV_NOTE_ANALYZER_NZDT

Embedded search post processing

With an upgrade or support package SAP will deliver new improved version of embedded search models. If you are using embedded search you have to do post processing to make use of these new improved versions.

By default SAP will keep using the old model to make sure the search function keeps working. The basis administrator can then update the search models at their convenience.

To update start transaction ESH_COCKPIT:

Then from the Other drop down select the option Model modified:

Note: if there are no Model modified present, but you do get the message like "update in background started", then wait until the model update background job is finished. This job can take long time. If finished restart transaction code ESH_COCKPIT again.

Select all to be updated (or in case there is a lot a subsection). Then select from Actions menu the Update option:

Then you have to wait (a lot). Even on HANA this will take a long time.

You might get a message that you yourself are locking the update process: in this case, wait until your processes in the background are done (SM66 monitoring) and then try again, or use smaller selection.

Alternative is to delete the search model after the upgrade and redo completely. For setting up search model in S4HANA read this dedicated blog.

Background OSS note: 2468752 – Re-indexing after an application Upgrade.

Authorization post processing

With any upgrade or support package SAP will deliver new authorization objects. These need to be handled as well.

Regenerate SAP_ALL and SAP_NEW

SAP_ALL needs to be regenerated. This can be done simply by starting transaction SU21 and hitting the Regenerate SAP_ALL button:

SAP_NEW can be regenerated with program REGENERATE_SAP_NEW:

See OSS note 2606478 – REGENERATE_SAP_NEW | bridging authorizations for input helps.

SU25 profile generator post processing

The authorization team needs to do post processing in the SU25 transaction to update profile generator.

Upon starting this transaction after the upgrade or support packages it will prompt you for having checked OSS note 440231 (SU25 preparation FAQ note).

Do download the most recent version (redownload the OSS note!) and read the content. The note cannot be applied automatically (it will say cannot be implemented). This is because it is a FAQ note. If you open the content scroll to your version and check the OSS notes. Make sure the notes listed there are applied to your system before continuing with SU25.

Then startup SU25 again and process steps 2a, 2b and 2c:

More background information can be found in SAP note 440231 – SU25 | FAQ: Upgrade postprocessing for Profile Generator.

Standard SAP job updates

After any SAP support package or upgrade, SAP will improve and/or change the standard clean up jobs.

To do this: go to SM36 and click the button Standard Jobs. Then select the Default Scheduling job. Then the system will tell you which jobs will be stopped (no longer needed), changed and new jobs there will be planned. See also the technical clean up blog.

For S4HANA standard jobs, read this blog.

Update of IMG nodes

If you use custom IMG nodes, you have to re-integrate your node into the main IMG using transaction S_IMG_EXTENSION. For more information see the blog on setting up custom IMG nodes.

Updating requirements and formulas

After an upgrade or support package the requirements and formulas might need to be regenerated via program RV80HGEN. More details: read this blog.

Updating ABAP where used list

After an upgrade or support package the ABAP where used list must be regenerated again. Read this dedicated blog.

General sanity checks after an upgrade

The basic sanity checks after an upgrade actually start before the upgrade!

Before the system is being upgraded, you should check following items:

ST22 short dumps
SM37 batch job failures
SM13 update failures
SM58 RFC failures (for idocs and qRFC)
SM21 system log issues

If you check this at regular intervals before the upgrade you get a good mental picture (you can also take screen shots before the upgrade) of the issues already present in the system.

After the system upgrade and/or support package you check these items again. Because you checked before it is easy for you to see and filter out new items. New items can be analyzed for solution (can be SAP note that is needed, custom code that is not properly updated, changes in functionality, etc).

SGEN code generation

After support pack or upgrade you can use transaction SGEN to generate all ABAP code (standard SAP and custom) and check for errors in code generation. More information in this blog.

SEGW issues on standard SAP after the upgrade

In the past you could solve SEGW FIORI ODATA exposing issues directly in the system. Now SAP has forbidden this. See OSS notes 2734074 – Editing of standard SEGW projects for customers is blocked and 2947430 – Editing Standard OData Service Project throws error: Editing Prohibited SAP delivered projects cannot be edited in your system. The emergency workaround is described in OSS note 3022546 – In Transaction SEGW, Error ‘SAP delivered projects cannot be edited in your system’ is encountered during change of the OData Project PS_PROJFIN_MNTR.

Check for new or altered security parameters

After a support pack most security parameters remain the same. After and upgrade you need to check for new or altered security parameters. For S4HANA upgrade there is special note and program to quickly check for new and altered security parameters including the SAP recommendation: read more in this blog.

Other things to do after an upgrade

After an upgrade you can scan and check for new or enhanced functions you can use.

Examples to check:

Update the SCI variants delivered by SAP (see blog)
SAP audit logging will deliver new checks, but these are deselected after the upgrade
If using enterprise search: check if SAP delivered new search models that might be interesting for the business