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.
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.
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.
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.
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).
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.
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.
Also for S4HANA upgrades from older to newer S4HANA version, you can run the readiness check. Read more about it in this blog.
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.
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:
Transport imports after the upgrade
System validation before 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.
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.
After SPAU, you are not yet done. You need to start SPAU_ENH transaction and take care of all the enhancements (explicit and implicit):
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.
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
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.
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.
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 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
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.
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.
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.
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?
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.
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.
Object Based Transformation (OBT)
ABAP Integration for SAP Data Intelligence (DI)
S4HANA Migration Cockpit (MC)
SAP Landscape Transformation (SLT) Replication Server
Near Zero Downtime Technology (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.
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:
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.
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.
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