SAP BW 7.3 is composed of ABAP and Java, each with its own database. The SAP BW upgrade for ABAP from 7.3 to 7.4 and above is challenging as it involves equal efforts from—and coordination between—the SAP BW functional and Basis teams. To ensure that the SAP BW upgrade is successful, cooperation and communication between the two teams is vital. How the SAP BW upgrade tasks are categorized and how they should be divided between these two different teams can sometimes be confusing. I’ll provide some tips as to who should be executing the jobs/programs and how the responsibilities are divided in a way that makes the most practical sense.

The SAP BW upgrade for Java is pretty straightforward and follows the same steps as the ABAP upgrade—SAP has not made any changes to Java as it did with ABAP. I have provided more details about the SAP BW upgrade for ABAP as there are more changes, and also provide do’s, don’ts, and important tips to facilitate this upgrade.

DO clearly document each step as to which team will do what to alleviate any confusion.

DON’T have the SAP Basis administrator/developer execute SAP BW’s job/task/program—this execution is the responsibility of the SAP BW functional team. This should be made very clear to all the team members involved before the start of the upgrade.

(Note: For an SAP Basis administrator to execute SAP BW’s job/task/program, they need roles/authorization for executing it and they might not know if they are taking the right as this falls entirely under the SAP functional team’s area. As a result, the SAP functional team is more knowledgeable about this than the SAP Basis would be. Moreover SAP Basis administrators do not have the roles/authorization to the production server.)

Tip! >Schedule a meeting with the SAP BW functional ABAP and Basis teams and create a checklist for the upgrade. Checklists should be created based on documents such as the Master Guide, Upgrade Master Guide, and Upgrade/Update Guides. These guides can be downloaded from https://help.sap.com/nw74.)

The first step is to download the files needed for the upgrade.

Download Files

First, check to ensure that Solution Manager is connected to the system identifier (SID) that will be upgraded. This should already be in place. Once this has been confirmed, select the SID to be upgraded and generate the .xml files for the upgrade. Next, download the latest version of Software Update Manager (SUM), as recommended by SAP. SUM can be downloaded from https://support.sap.com/sltoolset.

(Note: The SUM tool is used for upgrading SAP BW systems. SUM is a multi-purpose tool that supports various processes, such as performing a release upgrade, installing enhancement packages, applying Support Package Stacks, installing add-ons, and updating single components.)

In my example scenario, one challenge I faced is that the content repository (CR)/common information model (CIM) content was not up to date on the SAP Solution Manager system. According to SAP’s best practices, the CR/CIM content should be updated in Solution Manager on a quarterly basis or at least three weeks before an upgrade starts. It’s part of the SAP Basis administrator’s routine job to address CR/CIM content on a quarterly basis. To ensure that this happens, download the files in advance after confirming with your company what version and patch level they would like to go to, and if it’s feasible to go to that version. In this case, since the CR/CIM content was not up to date, it had to be updated for Solution Manager in accordance with SAP Note 669669.

DO ensure that the current CR/CIM files are downloaded at least three weeks in advance of beginning the upgrade on the Solution Manager system.

DON’T wait until the last minute to download these files. This is because there could be network issues that may result in only partial files being downloaded (not complete files). If this happens, you need to additional time to ensure that all the files are downloaded completely in time for them to be used. Another reason to download early is if the network connection turns out to very slow. If this happens, you want to make sure there you’ve built enough time into the schedule so that these files can be downloaded in time.

(Tip! Every quarter, plan for CR/CIM updates to the Solution Manager system and other systems that require CR/CIM.)

Upgrade Phases

After SUM is started, it goes through all the below phases one by one in sequence. There are eight phases for an SAP BW upgrade, as follows:

Initialization
Extraction
Configuration
Checks
Pre-processing
Execution
Post-processing
Finalization

There is one important thing to keep in mind during these eight different phases. It critical that you note the timings of the upgrade as noted in Table 1. This helps companies with planning when upgrading their quality/acceptance systems and production systems.

Phase number	Phase name	Phase details	Start date	End date	Total time	Remarks
1	Initialization	When the SUM tool is started, it starts the first phase, initialization. This is the start of the upgrade itself. In this phase, the system is checked to make sure it is up and running; once that's confirmed, the next phase begins immediately.
2	Extraction	In the extraction phase, the SUM tool scans the download directory and it extracts the files to the Electronic Parcel Service (EPS)/in (directory in Unix or Windows). It requires the password of the user ID DDIC, the required pre-upgrade SAP Notes (during this phase, the SUM tool automatically detects what SAP Notes need to be applied to the BW system), and the latest Support Package Manager (SPAM) that is needed. SPAM must be updated before any upgrade. A SPAM update contains updates and improvements to SPAM. There is always one SPAM update for each release. A SPAM update is mandatory before any support package upgrade.
3	Configuration	Determine what configurations are going to be provided for the upgrade. For example, these questions need to be answered: Will archiving be set to on or off? What will the strategy be for system generation (SGEN), Number of batch/background (BTC) process uptime/downtime, and Increment (Table) Conversion (ICNV)? (Note: When a system is upgraded, you need to execute transaction code SGEN. BTC is the batch/background where the SAP programs can be executed in the background and the user doesn’t have to be logged on for the same. With transaction code ICNV, you can perform conversions before the upgrade—that is, during production.) What will be the maximum number of processing allowed during the upgrade in parallel import processes? What Support Package Data Dictionary (SPDD)/repository object (SPAU) numbers of the transport requests will identify any objects where the hot package overwrites changes are made through SAP Notes? During this phase, it also has to be decided whether to use near-Zero Downtime Maintenance (nZDM), which reduces significant downtime. The benefit of nZDM is that table structure adjustment is allowed, including conversions and main Import. Almost all the upgrade guidelines from SAP recommend using nDZM.
4	Checks	Sum determines the locked SAP objects in a transport request and informs the system administrators to release the transport request. SUM also checks for database space requirements and performs activation/conversion checks.
5	Pre-processing	The pre-processing phase is a pre-downtime step. In this step, the system is available to all the users until the system is locked. Once the system is locked, it cannot be used for development. Pre-processing is a crucial step for the upgrade (as are the shadow instance load and SPDD steps). During the shadow instance, the system creates the same system Identifier (SID) but a separate instance. For example, if your current instance is 00 and when SUM requests the instance number and you give 03, SUM creates a shadow instance of 03 with a separate shadow (ABAP) repository. The ABAP repository is a specific part of the database. It consists of development objects such as programs, database tables, and so on. This is the last online phase; after this phase is completed, the actual downtime (execution) phase can begin.
6	Execution	This is the downtime phase where the actual upgrade to the system takes place. During this phase, the shadow instance and real instance are merged, and the table conversion takes place. During this phase the system is not available to anyone, including system users.
7	Post-processing	This is the phase after the upgrade has been performed. During this phase you can make SPAU changes to the development system. You must check that all objects are identified in SPAU and decide whether you need to reapply the SAP Note or reset the code to the original SAP settings. These can only be done in the development system; then the changes can be put in a transport request and imported to the quality and production systems.
8	Finalization	During this phase, provide a summary of all the upgrade phases and note that each phase has been done successfully and there were no issues reported in any of the phases. This phase takes less than 20 minutes to complete.

Table 1
A checklist of the eight phases for an SAP BW upgrade with brief descriptions

Table 1 lists each phase and what needs to take place during that phase and also includes blank columns to keep track of when tasks are started and finished, as well as space to keep notes.

When upgrading to SAP BW 7.4, there are two phases that are the most critical in the latest upgrade: the checks phase and the finalization phase. In both these phases, Basis administrators need to liaise closely with the SAP BW functional team.

In the following, I discuss the new and most important changes in the latest upgrade to SAP BW 7.4 Support Package (SP) 13 and above. The tasks SAP_BW_HOUSEKEEPING, SAP_BW_BEFORE_UPGRADE and SAP_BW_AFTER_UPGRADE are introduced in this SAP BW upgrade. These tasks are executed via SAP transaction code STC01 and the output can be viewed by executing transaction code STC02. All these tasks are executed by the SAP functional team.

The Checks Phase

At the end of the checks phase, the BW functional team needs to execute transaction code /ASU/Upgrade, and tasks SAP_BW_HOUSEKEEPING and SAP_BW_BEFORE_UPGRADE. The Basis team is responsible for uploading the /ASU/Upgrade template from SAP Note 1000009. Table 2 lists the different tasks and to which team—SAP BW functional or Basis—they are assigned in transaction code /ASU/Upgrade.

Team responsible	Task
Basis team	Initial system check using transaction code SM21 (system logs) and transaction code SICK. Check if there are no unusual errors in systems logs. This is a usual check Basis Administrator do on daily basis and normally no issues are expected.
Basis team	Check for any inconsistencies in the secure storage with transaction code SECSTORE
BW functional team	Re-activate the source system
BW functional team	Repair InfoObjects
BW functional team	Activate BEx history
BW functional team	Check compounding consistency in MultiProviders
BW functional team	Application Link Enabling (ALE): Generate and read change pointers after the upgrade
BW functional team	Program for transformation activation: Sometimes the object transported from the development system to the quality system is deactivated in the quality system. When that happens, it needs to be reactivated. This can be done via transaction code SE38 and executing program RSDG_TRFN_ACTIVATE.
BW functional team	Create dropped-fact views

Table 2
Team responsibilities and their tasks when executing transaction code /ASU/Upgrade

In an SAP transaction code /ASU/Upgrade, there is an option to select a tick mark (green checkmark) when a task is completed successfully. Use it so that both teams know that the task is completed. If this is not done, it makes it difficult to confirm if a task is completed or not. In my scenario, I had to inform the SAP BW team to use that option.

According to SAP’s upgrade documentation, SAP suggests executing either transaction code /ASU/Upgrade or task SAP_BW_BEFORE_UPGRADE via transaction code STC01. These are tasks that need to be executed after the checks phase is completed. SAP_BW_BEFORE_UPGRADE has a list of approximately 15 tasks that need to be completed by the BW functional team. After task SAP_BW_BEFORE_UPGRADE is completed, the BW functional team executes the task SAP_BW_HOUSEKEEPING. Task SAP_BW_HOUSEKEEPING is done manually, such as repairing indexes and cleaning statistical data. It has approximately 12 tasks. SAP_BW_HOUSEKEEPING is also executed via transaction code STC01 by the BW functional team.

DO discuss these tasks (SAP_BW_HOUSEKEEPING and SAP_BW_BEFORE_UPGRADE executed via transaction code STC01) with the SAP BW functional team and have them execute them. Also have the BW functional team check transaction code /ASU/Upgrade.

DON’T have the SAP Basis administrator execute these tasks as it’s the responsibility of the SAP BW functional team. However, do ensure that the SAP Basis team checks the tasks in transaction code /ASU/Upgrade and works closely with the SAP BW functional team. There are two tasks for SAP Basis administrators, as mentioned in Table 2.

(Tip! Check the output of the tasks with STC02 to be sure that that tasks were executed.)

The Finalization Phase

After the finalization phase, the SAP functional team executes transaction code /ASU/Upgrade and also executes task SAP_BW_AFTER_UPGRADE. This is the final and most important step of the upgrade, and is executed after the upgrade is complete. These tasks are executed via transaction code STC01. You can view the output by executing transaction code STC02. All these tasks are executed by the SAP BW functional team.

DO take screenshots of each step so that it’s well-documented during the upgrade process.

DON’T assume that these tasks are done. Check the output via transaction codes STC02 and /ASU/Upgrade. In my case, the Basis team didn’t assume that these tasks were completed in the development system unless they saw it themselves via transaction code STC02.

Quick Tip: A List of Dos and Don’ts When Upgrading to SAP BW 7.4

Reading time: 33 mins

Learn the dos and don’ts for upgrading to SAP BW 7.4, as well as some quick tips to help functional teams and Basis administrators plan a successful SAP BW upgrade to 7.4.