Ready for Hana?

The Hana Readiness Audit provides a neutral, market-compliant review of SAP systems with regard to the migration of the database to Hana.

This makes it possible to achieve better plannability of an upcoming Hana project for IT and the business side and cost savings in Hana migration through good preparation and automated fact gathering.

The process begins with a detailed measurement of the SAP systems in question. These are compared with a body of experience that has the SAP market knowledge of over 4500 analyzed SAP systems.

Using SAP systems measured over a period of time both on AnyDB and after conversion to Hana, Alegri can make statements about the expected behavior of the system on Hana.

The focus of the survey is the analysis of the database, in-house developments and add-ons as well as the migration to S/4 Hana.

Database:

It is the core of the data conversion from AnyDB to Hana. This should be analyzed beforehand, as DB size and growth is crucial for Hana sizing.

In addition, a provisioned Hana instance is not easy to change - unless it is sourced from the cloud. A migration is also a good time to clean up in a GDPdU-compliant manner.

Part of the data stored by SAP are (technical) logs, such as: DBTABLOG, or transferring IDOCS, like the tables EDIDC or EDIDS.

Only transparency about existence and data size can underpin an informed decision on how to proceed.

There are also various criteria for archiving or housekeeping for other data. This not only saves expensive hardware, but also improves performance and facilitates migration.

Proprietary developments/add-ons:

With every change to the SAP system, in-house developments play a special role and are usually cost drivers. During the first migrations of ERP systems (not SAP BW) to Hana, the disillusionment was often great after the project that the response time had not improved, but had even worsened in places.

In-house developments and add-ons played a large part in this. Both were optimized for the traditional line-oriented databases for years.

Transparency about usage and load behavior is a great relief here. Knowing how in-house developments are used saves money and time in omitting unused in-house developments, and knowing the load behavior of in-house developments allows them to be optimized more quickly.

Add-ons come from third-party manufacturers. These cannot and should not be optimized by yourself. Here it is essential to get an overview of the important and most used add-ons: Then a release optimized for Hana or S/4 can be requested from the manufacturer.

Application Level:

In the case of a migration to S/4 Hana, it is also necessary to look at the application level. Based on the business processes used, a report is created on:

Check which transactions used in S/4 Hana will be replaced Specify which transactions will replace the replaced ones List new functions in S/4 Hana that are suitable for the previous business processes Checklist of which functions change with S/4 Hana This analysis is particularly important for a conversion (migration of an existing SAP system/brownfield approach).

In the case of a new setup (greenfield approach), the analysis supports the design of the new business processes.

Information:

In addition to the points mentioned, the Hana Readiness Audit provides further information (release statuses, usage areas, load volumes and other variables) for the changeover. These are compiled automatically so that manual, potentially error-prone work is avoided.

Summary

For most customers, the question is no longer whether to migrate to Hana, but when. The Hana Readiness Audit uses market experience and applies it to the SAP system to be migrated. This leads to realistically planned projects when migrating to Hana as a database or S/4 as a system.