Author: Marçal Oliveras

The challenge of bringing customization to S/4 HANA

Today a blog in which we challenge you not to write off your valuable custom work in SAP ECC, but to take it with you to S/4 HANA.
We assume that you want and can make maximum use of the advantages that the new techniques offer you.

There are several paths, with or without side-by-side development on SAP Cloud Platform or other solutions as low-code. This blog is limited to migration of ABAP customization to an S/4 HANA On-Premise as a 'to be' situation.


S/4 HANA Custom Code Conversion Technical Challenges

As early as 2015, the first release of SAP S/4 HANA was released, and support for the SAP Business Suite was coming to an end by 2025. This deadline is due to pressure from SAP users. postponed to 2030. After that, the Extended Maintenance will stop.

This new deadline offers SAP users the advantage of more time and thus more possibilities to migrate existing applications to the new platform. This has the disadvantage that new innovations that SAP develops exclusively for S/4 are therefore also postponed for the customer.

S/4 HANA is not just an update from ERP 6.0 to an in-memory database. It is a totally new product with a number of fundamental changes:

  • SAP GUI transactions have been replaced by Fiori applications.
  • SAP Functionality has been implemented in the Simplified Data Model to simplify their overgrown data model.
  • Functionality that is no longer relevant or has been revised or no longer has place in S/4
  • Specific adjustments, such as extension of the article code (MATNR)
  • The HANA database brings the power for online processing, but expects other programming techniques , such as Code Push Down.

It is clear that S/4 HANA offers many possibilities and opportunities, but that something must be done to achieve this.


1. Fiori Launchpad as a replacement for SAP GUI

In the S / 4 On-Premise environment, most transactions still work to a greater or lesser extent, but are redundant [1] and not intended for end users. If transaction-level customization is implemented, you may need to add functionality to the replacement Fiori application.

2. Simplified Data Model

Traditional modules have been redesigned to make better use of the new HANA database and to simplify the complex data model. This has grown over the years that SAP has added new functions to the ERP.

An example is the SD module, the entire data model is greatly simplified [2] based on 2 scenarios:

  • Redundant tables whose main purpose was to increase reading speed to specific data has been removed because HANA DB makes them obsolete.
  • Tables whose data can be stored in another existing table have been deleted and their fields added to the respective tables. In some cases new document types are generated.

[1] See for instance the MM module obsolete transactions:

[2] SD module model simplification: (see also note 2267306)


A specific example is the VBUK table with the status of the sales order in ECC. This table still exists in S/4 HANA, but is no longer populated with data when a sales order is created or modified. It has not been removed yet because some standard function modules still use the structure.

In the new model, ABAP may not cause an error because the table still exists, but it will not return the expected data, if your ABAP custom selects data from the VBUK table. To customize your custom code, SAP provides specific instructions called “cookbooks” for each Simplification and all implications. The cookbook for the VBUK table can be found as an appendix in note 2198647.

In addition to customizing your own code, if you have created an append structure in the VBUK, you must add the fields to the corresponding table for the relevant document type: VBAK, LIKP, or VBRK. Finally, adjust the code where the append structure is used.

3. Outdated functionality

For many years and releases SAP has delivered multiple solutions for the same functional areas. However, with the new S/4 product, many of these duplicates have been removed or marked as obsolete, but it is possible that your ABAP customization is still using them.

For example, the Credit Control module for Sales and Distribution is no longer available and you have to use SAP Credit Management instead. Another example are the industry specific objects that were present in SAP ERP and will not be available in S/4 HANA.

Even if the APIs of these legacy modules are not used by your ABAP code, developers trying to follow best practices of the past may reuse data elements or structures to avoid creating new custom objects where possible. In any case, all code using the deleted or obsolete objects should be modified according to SAP recommendations.


As its name implies, S/4 HANA is designed to run exclusively on the in-memory HANA database. To ensure that your ABAP customization continues to work properly and to optimize it for the new HANA DB, a number of mandatory adjustments must be made.

** Although SAP ERP 6.0 is not designed to use all the power of HANA DB, the system will perform better when the code is developed with the new DB in mind. Therefore, most customers start by replacing their SAP ERP SQL database with the HANA database.

The purpose of this blog is not to provide technical tweaks that will help you correct and optimize the performance of selections for HANA DB, but just to point out that there are mandatory changes to your ABAP code for your transition to S/4 HANA.

For more information on this topic, visit the following blogs:

To identify the HANA-specific problems in your code, SAP has provided a number of Code Inspector variants, called FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION, that can help to scan all of your custom code and identify the points where it needs to be corrected. In addition to the performance recommendations, the two main issues to fix immediately are the specific database code and the expected implicit primary key sort.

5. Field Length Changes and Similar Functional Adjustments

Probably the best known technical change in S/4 HANA is the extended material number length from 18 to 40 characters. Another similar change is the extended length for all currency fields up to 23 with 2 decimal places.

In these cases, if the developer used custom types in the code or in the Data Dictionary, the mapping may be incorrect. The example below is very simplistic, but it illustrates the problem of using custom data types for a material number.



The migration to S/4 HANA presents several technical challenges that require the adjustment of your ABAP customization. Some of the necessary changes can already be implemented in your current SAP ERP environment, even before you consider your migration to S/4.

At Oliver IT we can help you with the analysis, preparation and execution of your SAP system upgrade. Contact us to discuss your roadmap and get the best advice from our technical experts.

Specific questions?

Enter your e-mail address and Oliver IT will contact you as soon as possible!

Done! We will contact you soon!
Peter Schults SAP Net weaver expert
Peter Schults