SAP HANA Upgrade Analysis app

The SAP HANA Upgrade Analysis app performs an upgrade assessment of your current system for HANA to HANA version upgrades. It produces a project-level Dashboard report, and details reports that help you do the following:

  • Fix impacted standard code.

  • Prioritize standard SAP testing.

  • Surface valuable integration points.

The app searches the Test Repository specified in a Pipeline to find test assets that match used, impacted standard code. The test assets create requirements and test executions in the Test Repository.

Optionally, you can use the app to identify sick modules and test cases in the Test Repository.

  • Sick modules refer to SAP screens that are different in the current and target systems. The app stores these in a virtual folder named Sick Modules - <timestamp>.

  • Sick test cases are test cases that use one or more sick modules. The app stores these in a virtual folder named SickTestCases - <timestamp>.

DevOps categories

Development, Testing

Prerequisites

Before you run the SAP HANA Upgrade Analysis app, do the following:

Create RFC Destinations

Create RFC Destinations for your As-Is (current), To-Be (target), and Usage SAP systems. Run the Collect Performance History Data workflow from the Tools templates folder to download performance history data for the Usage system.

Create Object Links Cache databases

Run the Create Object Links Cache workflow from the Prerequisites templates folder to create Object Links Cache databases for your As-Is and To-Be RFC Destinations.

Create Test Repositories

If you plan to use the app’s Heal Tests functionality, create the Test Repositories that you’ll use in your Pipeline.

Create a Pipeline

If you plan to use the app’s Heal Tests functionality, Create a Pipeline that includes the appropriate Test Repositories. A Pipeline has the following Test Repository fields:

  • The Most-at-risk Search Test Repositories fields store the Test Repositories that will be searched to find test assets that match impacted standard code. Each Most-at-risk Search Test Repository may have one or more search paths to limit the folders that are searched. Each path should begin with the Subject folder, and a backslash (\) should be used to separate path components, for example Subject\Release1.

  • The Most-at-risk Gaps Test Repository field stores the Test Repository in which to create requirements for most-at for most-at-risk objects that don't already have requirements in the Tosca, qTest or ALM Most-at-risk Search Test Repositories. Requirement names have the format LiveCompare_Most-at-risk_Gaps <YYYY-MM-DD HH:MM:SS> <Object Name - Object Description>.

  • The Requirements Path field stores the name of the root requirements folder to be used in the specified Tosca Most-at-risk Gaps Test Repository. If you don't set this field, the app uses Requirements as the default value.

  • The Most-at-risk Hits Execution Test Repositories fields store the Test Repositories in which execution lists are to be created. Do the following for each Most-at-risk Hits Execution Test Repository:

    • Set the Execution Name field to the name of the test execution folder in which execution lists are to be created.

    • Set the Execution Path field to the to the path of an existing Test Repository folder in which to store the test executions, for example Execution/TestExecutions. If you don't set this field, LiveCompare creates the test execution in the default Executions folder.

    • Set the Execution List Path field to the path of an execution list to reuse when creating Tosca test executions, for example, Execution/MyTests/LiveCompare_2026-01-31 09:47:17/MyExecutionList.

    • Set the Options field as appropriate to either create test runs, or to create and run test runs. Executing tests requires Tosca to be configured for DEX.

The Heal Tests functionality of the SAP HANA Upgrade Analysis app supports Tosca Test Repositories only, and requires Tosca version 13.3 or above. Note that only the first Tosca Most-at-risk Search Test Repository is searched to find sick modules and test cases.

Create Test Repository Cache databases

Run the Create Test Repository Cache workflow from the Prerequisites templates folder to create Test Repository Cache database for your Pipeline’s Most-at-risk Search Test Repositories.

Run the app

To run the SAP HANA Upgrade Analysis app, select the app from the Apps screen and create an app variant. Complete the Variant screen fields as follows:

SAP Systems

  • Set the As-is System field to the RFC Destination for your As-Is system.

  • Set the To-be System field to the RFC Destination for your To-Be system.

  • Set the Usage System field to the RFC Destination for your Usage system.

Tosca Tests

  • Set the Heal tests? switch to specify whether the app will identify sick modules and test cases in the specified Tosca Test Repository.

  • Set the Pipeline field to the Pipeline that includes your Test Repositories.

  • Set the Test Cases Path field to the path of the root Test Cases folder in the Pipeline’s first Tosca Most-at-risk Search Test Repository. This field has the default value TestCases.

  • Set the Modules Path field to the path of the root Modules folder in the Pipeline’s first Tosca Most-at-risk Search Test Repository. This field has the default value Modules.

Select Run. When the variant has completed, you can access the results from the App Cockpit screen.

App results

The SAP HANA Upgrade Analysis app generates a Dashboard report which includes the following charts:

Development - Fix your Custom Code

  • The Impacted Custom by Devclass doughnut chart summarizes the custom code objects impacted by the by upgrade, grouped by Development Class.

  • The Top BDC Transactions doughnut chart summarizes the top 5 BDC transactions from the As-Is system. For each transaction, the values indicate the number associated programs using either CALL TRANSACTION or CALL DIALOG statements.

  • The Impacted ENHO Summary doughnut chart lists enhancement implementations impacted by the upgrade. The values indicate the number of impacting objects for each enhancement implementation.

Testing - Impacted Standard SAP

  • The Executables by Type pie chart groups the impacted executables by their type.

  • The Executables by Risk column chart groups the impacted executables by their risk category, either High, Medium or Low. The risk categories are calculated based on each object’s usage and percentage change value in the As-Is and To-Be systems.

  • The Test Coverage by Risk column chart indicates the test coverage for each risk category. Hits are executables that have a matching test in the specified Test Repository. Gaps are executables that don't have a matching test in the specified Test Repository.

Integration - In Scope IDocs

  • The Standard v Custom IDOCs doughnut chart summarizes the standard and custom IDOCs impacted by the upgrade.

  • The Top Standard Segments doughnut chart lists the top 5 standard IDOC segments impacted by the upgrade. The values indicate the number of IDOC segments.

  • The Top Custom Segments doughnut chart lists the top 5 custom IDOC segments impacted by the upgrade. The values indicate the number of IDOC segments.

  • The Impacted Roles column chart lists the number of roles impacted by the upgrade. These roles have authorization objects that have either been added or removed on the To-Be system.

The Dashboard report also includes links to the following reports:

Development Report

This report includes the following spreadsheets.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Impacted~Top Down

This spreadsheet identifies used custom executables that depend on SAP objects with significant differences on the As-Is and To-Be systems. Each used object is listed in the TYPE and NAME columns, and its usage count according to the available performance history data is listed in the USAGE column. The SAP object that impacts each custom executable is listed in the CHILD_TYPE, CHILD_NAME and CHILD_DESC columns. The impacting object name is shown as a hyperlink which allows you to display a detailed comparison report.

The comparison status of the impacting object on the As-Is and To-Be systems is shown in the STATUS column, followed by the custom executable’s Application Area description and Development Class. The user who last changed the custom executable is also shown.

Impacted~Bottom Up

This spreadsheet identifies used custom executables that depend on SAP objects with significant differences on the As-Is and To-Be systems. Each used object is listed in the TYPE and NAME columns, and its usage count according to the available performance history data is listed in the USAGE column. The SAP object that impacts each custom executable is listed in the CHILD_TYPE, CHILD_NAME and CHILD_DESC columns. The impacting object name is shown as a hyperlink which allows you to display a detailed comparison report.

The comparison status of the impacting object on the As-Is and To-Be systems is shown in the STATUS column, followed by the custom executable’s Application Area description and Development Class. The user who last changed the custom executable is also shown.

The Impacted~Top Down and Impacted~Bottom Up reports list the impacted programs, functions, includes, structures and tables called by your used custom programs. It is important to understand how these objects will respond to the custom programs in the upgraded system.

Impacted Enhancements

This spreadsheet lists the enhancement implementations impacted by the used objects on the Performance History system (in the TYPE and NAME columns), and the objects that impact them at a search depth of either 1 or 2 (in the FOUND_TYPE and FOUND_NAME) columns. Select a hyperlink in the FOUND_NAME column to display a comparison report for the impacting object on the As-Is and To-Be systems.

BDC

This spreadsheet identifies custom objects that call SAP transactions using the CALL TRANSACTION statement, or dialog modules using the CALL DIALOG statement. Each CALL TRANSACTION or CALL DIALOG statement is shown, along with its line number in the source code, and the name of the called transaction or dialog module. The VARIABLE column has the value Y for transactions or dialog modules that are called using a variable.

This report shows that custom code can be dramatically affected by an upgrade. Standard SAP transactions are used by custom code. If a standard SAP transaction is changed following an upgrade, then the custom code that uses it will be affected and may fail at runtime.

Screens

This spreadsheet lists the screens that are different in the As-Is and To-Be systems, or that are present in one system only. Each screen’s associated program is also shown. Select a hyperlink in the MODULES column to list any test modules that refer to the screen in the specified Test Repository. Select a hyperlink in the SCREEN_NUMBER column to display a comparison report for the screen on the As-Is and To-Be systems.

Sick Modules

This spreadsheet list modules in the specified Test Repository that refer to screens with significant differences on the As-Is and To-Be systems. The screens are either different in each system or present in one system only. The report includes the module ID, module name and module path from the specified Test Repository.

SPAU and SPDD

This spreadsheet identifies SAP objects on the As-Is system that have been modified, and are included in one or more imported support packs or transports. This report should be reviewed to identify support pack or transport objects that may need to be tested following an upgrade.

ADJUST_TYPE = SPDD: These objects have a type of ENQU, SHLP, TYPE, INTF, TABL, VIEW, DOMA, DTEL or TTYP. They may need to be adjusted using transaction SPDD.

ADJUST_TYPE = SPAU: These objects have types other than those where ADJUST_TYPE is equal to SPDD. These are repository (ABAP) objects that may need to be adjusted using transaction SPAU.

Select a hyperlink in the OBJ_NAME column to display comparison details for the selected object on the As-Is and To-Be systems.

Modified SPAU and SPDD objects will be reported in subsequent runs of the SAP HANA Upgrade Analysis app depending on how the SPDD and SPAU objects were changed:

  • If the objects were reset back to the original, they won't appear in future reports.

  • If the objects were kept and modified, they will continue to appear in future reports.

System Info

This spreadsheet includes details for the As-Is, To-Be and Performance History systems used in the analysis.

Testing Report

This report includes the following spreadsheets.

Help

This spreadsheet provides help for each of the spreadsheet reports.

Home

This spreadsheet lists used programs, transactions and BSP Applications on the As-Is system that will be impacted by screen and child object changes on the To-Be system following an upgrade. The report list each used program and transaction, with its usage count and percentage change score that is based on a comparison of its component screens. The CUSTOM column has the value Y for executables identified as custom according to the naming patterns used by the app.

The RISK column indicates the risk category assigned to each change, either H (High), M (Medium) or L (Low). It is calculated based on an object’s USAGE and CHANGE values.

Test Hit Details

This spreadsheet lists the used standard SAP objects that are impacted by the upgrade and have matching tests in the specified Test Repository. It lists each matched token, along with the matching test name and test path.

Sick Modules

This spreadsheet lists modules in the specified Test Repository that refer to screens with significant differences on the As-Is and To-Be systems. The screens are either different in each system or present in one system only. The report includes the module ID, module name and module path from the specified Test Repository.

System Info

This spreadsheet includes details for the As-Is, To-Be and Performance History systems used in the analysis.

Integration Report

This report includes the following spreadsheets.

Help

This spreadsheet provides help for each of the spreadsheet reports.

IDOCs

This spreadsheet helps to identify where customizations made to standard or custom IDOCs on the As-Is system may need to be applied to the To-Be system following an upgrade. This may be the case if SAP has made changes to the same IDOC as part of the upgrade release. The ORIGIN column indicates whether each IDOC is standard or custom.

IDOCs are made up of one or more segments, which are implemented as structures in SAP. The report lists the standard and custom IDOCs on the As-Is system, and the results of comparing their standard structures with the corresponding structures on the To-Be system. Select a hyperlink in the SEGTYP column to display the comparison details.

The IDOCs report should be provided to the Developers and Functional Leads assigned to the upgrade project. The leads should review the reports and check any IDOC segments with a comparison status of Different.

System Info

This spreadsheet includes details for the As-Is, To-Be and Performance History systems used in the analysis.

Security Report

This report includes the following spreadsheets:

Impacted Roles

This spreadsheet lists the roles impacted by the migration. These roles have authorization objects that have been either added or removed on the To-Be system.

Details

The SAP installation creates a table named USOBT, which contains SAP’s standard for associating authorization objects with SAP transactions. This table controls the authorization checks made by ABAP objects. During an upgrade, customers must perform a step which copies their existing profiles from the As-Is system to the To-Be system, adjusting any differences that the newer USOBT table may contain:

  • There may be new authorization objects not currently associated with As-Is transactions that are required for the new To-Be transactions.

  • Authorization objects that are checked in the As-Is system may have been removed from the To-Be system.

After the copying step has taken place, each of the changed profiles on the To-Be system should be adjusted to meet the customer’s security standard. This usually involves significant effort, and must be given serious consideration when estimating the time and resources required for the migration.

The SAP HANA Upgrade Analysis app extracts the profiles from the specified As-Is and To-be systems, and performs a comparison of the used transactions and associated objects enabled by each of the profiles, excluding any universal or derived roles. The report lists each impacted role, including its associated transaction code and the transaction code’s authorization objects. It also shows the status of each authorization object. REMOVED authorization objects exist on the As-Is system only; NEW authorization objects exist on the To-Be system only.

  • The report’s contents should be compared to your list of critical roles, authorizations or authorization objects. While this report can be large, a quick review of the critical roles and transaction codes is beneficial. Any critical transactions identified should be added to testing scripts.

  • Roles should be reviewed by SAP Security and each authorization object verified.

Obsolete Fiori Apps Report

This report lists used Fiori apps from the As-Is system that aren’t included in an External Data Source of current Fiori apps, obtained from S/4 HANA release 2021 FPS 01. The ID, name and type of each obsolete Fiori app is shown, as well as the number of users of the app, its top user, and its usage count according to the available performance history data.

Analysis Input Data

This Excel report contains a copy of the input parameters used to produce the app’s Dashboard report. The value of each input parameter is stored in a separate worksheet, which is named after the parameter whose value it contains.

Related topics

Add custom object naming patterns

Standard apps