In the previous blog post, we learned about the different transformation paths of an SAP S/4HANA implementation. Since each implementation method brings its own challenges, it is advisable to plan carefully. In the second part of the blog series, we will focus specifically on the challenges that can arise during a brownfield migration (conversion of an SAP ECC system to SAP S/4HANA). However, these are challenges that potentially play a role in every system transformation.
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.
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.
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.
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.
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:
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.
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.
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.
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.
In summary, whether it is a greenfield system conversion or a more complex landscape transformation, a system conversion is always a game between the precision and complexity of a process. It is wise to discuss with an implementation partner how to balance these two aspects while addressing the challenges as efficiently as possible.
Expert Solution Architecture
Your contact person
Grigor CoricExpert Solution Architecture
© 2023 Scheer GmbH
Necessary cookies enable basic functions and are required for the proper functioning of the website.
Statistics cookies collect aggregated information about how the website is used. This anonymous information is used internally to improve the functionality, attractiveness and content of the website.
Marketing cookies come from third party providers, these collect information to play out targeted content.
In order to display content from video platforms and social media platforms, cookies are set by these external media.