SAP S/4HANA Migration Challenges – Part 2

Challenge 1: Sizing

The memory requirements of the SAP HANA database are significantly higher than those of other databases and are directly related to the amount of data in a database. Consequently, a larger amount of memory requires higher CPU performance and more storage space. All this leads to a higher final price of the hardware. On the other hand, undersized servers can lead to a significant drop in HANA database performance. Also, database growth planning should not be forgotten (it might be difficult to resize the hardware later), and there are other systems besides the production system, such as development, test and sandbox systems, that also need to be converted. At this point, it makes sense to contact a conversion partner, as sizing should be done by an experienced consultant who can help avoid these obstacles.

Challenge 2: Data Volume

Data volume management is not only important to keep hardware requirements low and overall system performance high, but is also a crucial activity during conversion preparation.  This not only helps to reduce hardware requirements, but also provides a unique opportunity to get rid of "junk" such as unused master data, outdated logs, obsolete data, and so on. We recommend starting preparations in advance to have enough time to plan and execute activities such as data cleansing and archiving.

Challlenge 3: Custom Code

The data model in SAP S/4HANA has changed significantly compared to SAP ERP 6.0, especially in the finance and logistics modules. In addition, SAP standard code is being adapted to respond to these changes, both in terms of code syntax and execution performance. Customer-specific codes that may exist in the companies' SAP ECC system will still need to be adapted during the SAP S/4HANA implementation process. In the case of a very high number of customer-specific code objects in the system, the amount of work required for this activity can be measured in man-months. Therefore, it is necessary to perform a custom code analysis in advance (e.g. based on the custom code analysis as part of the readiness check) and plan the activity carefully. However, custom code is only one part of RICEFW (an acronym for "Reports, Interfaces, Conversions, Extensions, Forms, and Workflows") that needs to be catalogued, categorized, and managed so that it is either retired, replaced, or adapted.

Challenge 4: Data Preparation for CVI

Since SAP S/4HANA version 1511, Business Partner is the only way to manage customer and supplier master data in the SAP S/4HANA system. This means that all existing customer and supplier data must be integrated before the technical changeover of the system. Although the CVI Cockpit as a central tool for the changeover is a great relief, some steps have to be taken in advance and cannot be automated, e.g. data cleansing (deduplication, removal of obsolete data and determination of relationships between customer and supplier data) and decisions about number ranges.

Challenge 5: New General Ledger (New GL)

The use of New Asset Accounting is required in SAP S/4HANA and this demands the use of the New General Ledger. The migration from the classic general ledger to the New General Ledger can be done in two ways:

1. as a complete migration, in a separate project before the conversion to SAP S/4HANA, with all new functionalities such as document splitting or parallel accounting.
2. migration during the changeover, when only the minimum functionalities are activated (technical upgrade to New G/L). Additional functionalities can be activated after the changeover is completed.

Since the first option is more time and resource consuming than the second, it is important to carefully analyze the business requirements and benefits of a full migration, plan the reengineering of the processes and decide to what extent the new GL should be used.

Challenge 6: Test the Procedure and the Results

Testing is an important activity in any implementation and migration project. It includes unit, integration and user acceptance tests, which are performed in different systems and different migration phases. Since it is more difficult to correct errors in a conversion project than in a new implementation (in most cases, you cannot simply create a new transport request with a fix), it is important to test not only the results of the conversion, but also the conversion process itself. It may be necessary to repeat the conversion several times, in development and test systems, and in one or more sandbox systems (hardware resources!) that resemble the production system as much as possible. This prolongs the project, but shortcuts should not be taken in the hope that successful conversion of one system will necessarily mean successful conversion of another.

Challenge 7: Polish the Conversion Procedure

The methods for system conversions are widely known, but since each system landscape (even one system) is individually different from others, a detailed procedure for converting each landscape must be created. This has to be done during the conversion of the first system (development or sandbox) and refined during the conversion of the other systems. Finally, it should become a detailed script for the conversion of the production system.

Challenge 8: Cut-Over

The conversion of production systems usually takes place during a downtime window (in most cases, during a weekend). In order to complete the conversion under such time-limited circumstances and deliver a converted system to users at the start of their workday, the migration team needs to know the exact sequence of activities and their duration. Therefore, it is necessary to carefully plan the cut-over based on tested and agreed conversion procedures (see above). Furthermore, a "dry run" must be carried out on a system that is largely identical to the production system (new sandbox system) to verify that the conversion can be performed in the planned time frame.