How the SAP S/4HANA system conversion works

The system conversion, often referred to as the brownfield approach, is one of three basic conversion scenarios for migrating to SAP S/4HANA. This involves upgrading an existing ERP system to SAP S/4HANA. The other two variants are the new implementation (greenfield approach) and the landscape transformation, in which not the entire system but only selected parts of the business process are converted.

Since most companies already have an ERP system in use, the system conversion is the most common migration scenario. In addition, it is significantly less costly and time-consuming than the new implementation and the landscape transformation. Even though each company has individual characteristics with regard to its ERP system, there are some general tips to simplify the preparation and implementation of the system conversion.

One of the key issues of the migration to SAP S/4HANA revolves around the required personnel capacities. The system conversion can be divided into three phases: Prepare & Explore (pre-conversion), Realize & Deploy (conversion) and Run (post-conversion). Especially the preparatory activities of the Prepare & Explore phase, which precede the actual conversion, should be given sufficient space by companies, as they can make up a considerable part of the total effort.

What do you need to consider when converting to SAP S/4HANA?

SAP Readiness Check determines requirements

The SAP Readiness Check for SAP S/4HANA is a suitable introduction to the project. The tool analyzes the prerequisites for migration and provides an initial overview of the entire system as a cockpit, without getting lost in details. Both functional and technical topics are in focus. Among the most important aspects are the simplification items, i.e. the relevant functional changes associated with the switch to SAP S/4HANA. Consistency checks, relevant custom code adaptations and a recommendation on the use of the Fiori apps are also part of the SAP Readiness Check.

The reports delivered with SAP notes 2399707 and 2502552 check the system for relevant simplification items. To do this, it is necessary to call up the SAP catalog with the current simplification items online or upload it as a file. After selecting the desired SAP S/4HANA version, the system checks which simplification items are required. The respective SAP note with explanations and details of the required activities can be opened from the check report via a link.

Business Partner as central master data object

The Business Partner is certainly one of the most prominent simplification items. As the central master data object in SAP S/4HANA, it subsumes customers, suppliers and employees. Their basic data, such as name, address, tax number, etc., is maintained at the Business Partner level.

For the conversion to SAP S/4HANA, the Business Partner is a necessary prerequisite, i.e. it must already be implemented before the system conversion, as the technical upgrade routines check whether the business partner link exists.

Technically, the conversion to the Business Partner in the ERP release takes place via customer-vendor integration (CVI). This links the Business Partner with the vendor and/or customer master records. During the initial conversion, the Business Partner is generated via the CVI. During operation, the CVI keeps the basic data synchronized between the Business Partner and the customer/supplier.

Cleansing data

In the course of introducing the Business Partner, comprehensive data cleansing is a sensible step. Certain cleansings have to be performed anyway to generate the Business Partner. Inconsistencies occur, for example, in customer and supplier data that has not been changed for a long time, as validations or mandatory fields may have changed in the meantime. SAP delivers a transaction that analyzes the most common inconsistencies. It can be imported using SAP Note 2743494. Optionally, a duplicate check is also recommended; the duplicates can be cleaned up during the cleansing project.

Universal Journal instead of application-specific tables

The most extensive part of the conversion to SAP S/4HANA is the Finance Conversion. In the finance area there are significant differences in the data model between the ERP release and SAP S/4HANA. Due to the functionality of the HANA database, the summary tables of the individual applications are no longer required. Furthermore, various sub-applications such as FI-AA, CO etc., which in the past had their own (sub)tables, are now merged in the Universal Journal (ACDOCA). This means a common line item table.

This conversion is accompanied by certain migration activities, checks before the actual upgrade and changes in customizing. For example, various check routines in the preparation phase concern customizing and data inconsistencies. After the technical upgrade, the actual conversion activities are still pending.

Process of the Finance Conversion

The preparatory measures for the Finance Conversion are checking the relevant simplification items, correcting data inconsistencies – a prominent example is the reconciliation of summary tables and line items – and examining the consistency in customizing. Check and correction reports can be used to identify and correct inconsistencies even before the upgrade. But “housekeeping” activities are also useful before the conversion – for example, archiving data or deleting company codes that are no longer needed.

The actual Finance Conversion starts after the technical upgrade. First, you need to make some customizing settings for the conversion. Examples are the settings for the migration of the General Ledger, Asset Accounting, CO, Material Ledger and Credit Management. Usually, the customizing settings are made in the course of the first test conversion and are then transported to the subsequent systems.

SAP S/4HANA is based on the new Asset Accounting, which can be introduced in the course of the conversion. In earlier SAP S/4HANA releases, the use of the New General Ledger (New GL) was also a mandatory requirement for the migration. In certain scenarios, however, it is now possible to migrate directly from the classic General Ledger to SAP S/4HANA. The condition for this is that companies use neither the document split functionality nor parallel ledgers. In this case, the intermediate step of the conversion to New GL is omitted, so that the functionality can be subsequently introduced in SAP S/4HANA.

Credit management in FI-AR is no longer supported with SAP S/4HANA

Historically, there are two solutions for credit management in the SAP world: FI-AR Credit Management and SAP Credit Management/Financial Supply Chain Management (FSCM). SAP S/4HANA no longer supports FI-AR Credit Management. Instead, SAP relies here on the newer solution, which is also based on the Business Partner. The conversion to SAP Credit Management is possible in the course of the SAP S/4HANA conversion. However, companies must take into account that SAP S/4HANA only includes a basic version of SAP Credit Management in terms of licensing. This does not include the calculation functions that automatically calculate credit limits based on formulas.

Effects on the custom code

Another highly relevant aspect is checking the compatibility of the custom code with SAP S/4HANA. Adjustments in the data model with S/4HANA may require you to adapt your own Z programs accordingly. In preparation for this, companies should determine early on which programs are no longer required. This can be done by activating usage & procedure logging in the system. It runs in the background for a certain period of time and recognizes which programs are executed how often.

The custom code check can be performed either before the upgrade or during the actual SAP S/4HANA project. A central checking system supports code customization and makes it possible to check SAP S/4HANA compatibility in the ERP system even before the upgrade.

GUI, WebDynpro or Fiori?

In order for the system conversion to SAP S/4HANA to be successful, companies should determine in advance to what extent they want to use the modern UI technology SAP Fiori. Basically there is no compelling necessity to convert completely to SAP Fiori, as most SAP GUI and WebDynpro applications can still be used. Their look and feel is even color matched with the Fiori visual theme.

Furthermore it is important to note that Fiori apps do not replace the existing GUI/WebDynpro applications 1:1. Instead, some SAP GUI transactions are split into several Fiori apps. Conversely, SAP also combines certain GUI transactions in one Fiori app and integrates some new functionalities.

Fiori apps involve a fundamental change in the application and usually have a strong analytical focus. With their user-friendliness, Fiori apps create additional value for the business department. It therefore makes perfect sense to activate selected Fiori apps in the course of the SAP S/4HANA conversion. After the conversion, companies can then gradually expand their use of Fiori. The Fiori Apps Library provides some suggestions for this.

In terms of the required infrastructure, the deployment options for Fiori apps have changed somewhat over time. The apps run on the Fiori front-end server (SAP Gateway), which in the past was often installed on a separate system. In most cases, however, the recommendation now is to run the Fiori front-end server on the SAP S/4HANA system. This embedded deployment leads to a simplification of the system landscape.