10.2 Converting Single Systems
This section explains the steps that you’ll have to perform in every system you are converting to SAP S/4HANA. Note that these steps are performed in different phases and probably in different systems of the system group and at different times. For example, you can adapt your custom developments in the SAP S/4HANA development system. Also in the development system, you’ll collect the adaptations in transports, which are then directly installed when you convert the production system.
You can also implement many of the mandatory or optional business process modifications or adjust your custom developments immediately on the SAP ERP start release. In this case, these conversion project steps are carried out in upstream systems. You’ll have to decide for your specific conversion project whether you implement these adaptations beforehand or during the system conversion on the SAP S/4HANA development system.
In addition to the specific SAP S/4HANA conversion project steps, you’ll also have to carry out standard tasks that you already know from other transformation projects, for example:
-
End-user training
If you modify business processes or migrate to SAP Fiori-based user interfaces, you’ll have to schedule specific end-user training sessions and carry them out in a timely manner. -
IT employee training focusing on new technologies
SAP S/4HANA introduces new technologies, such as Core Data Services (CDS) and the new HTML5-based SAP Fiori user interfaces. You’ll have to train your experts accordingly. -
Business process tests
Don’t forget to include application tests.
These standard tasks of transformation projects are not described in detail in this book. Nevertheless, these tasks are also critical for the success of your SAP S/4HANA conversion project and need to be performed.
10.2.1 System Requirements
Basically, you can convert any SAP ERP system to SAP S/4HANA. However, the effort and procedure required depend on the initial release.
Migrating to SAP S/4HANA (or changes to a new release within SAP ERP) is a one-step procedure if you upgrade the software and migrate the database in the same technical step. You can convert your SAP ERP systems into an SAP S/4HANA system using the one-step procedure if the following requirements are met:
-
Start release
SAP ERP 6.0, Enhancement Packages (EHP) 0 through 8, must be installed on the source system. You might already be using an SAP HANA database, but you can also convert SAP ERP systems with other databases in one step. -
Unicode
The source system must be a Unicode system. -
Only SAP NetWeaver Application Server (AS) ABAP
The SAP ERP source system must be a pure ABAP system. Converting dual-stack systems (combination of AS ABAP and AS Java in one system) is not supported.
Systems on which older releases are installed or for which no Unicode conversion has been performed must be converted to SAP S/4HANA in multiple steps.
[»] Unicode Conversion
In mid-2014, SAP announced that all new SAP NetWeaver releases after 7.40 and all products based on higher releases would only be compatible with Unicode. Technically, non-Unicode systems based on SAP NetWeaver releases up to 7.40 cannot be converted into a product with an SAP NetWeaver release that is higher than 7.40. You’ll have to perform a Unicode conversion first.
In general, the following conversion paths to SAP S/4HANA, on-premise, are supported:
- From SAP ERP 6.0 to SAP S/4HANA
- From SAP ERP 6.0 to SAP S/4HANA Finance
- From SAP S/4HANA Finance to SAP S/4HANA
Figure 10.6 illustrates these conversion paths.
Figure 10.6 SAP S/4HANA Conversion Paths
As we described in Chapter 3, Section 3.2, SAP S/4HANA has two on-premise variants. For example, SAP S/4HANA Finance with the new functions is available in accounting, while SAP S/4HANA contains new functions for accounting and for logistics. In system conversions, the two on-premise variants differ in the following ways:
-
Adaptation requirements
Due to the different innovation scope of the two variants, their adaptation requirements also differ. Depending on your requirements and needs, you’ll follow a step-by-step approach for the conversion. If you only want to use SAP S/4HANA’s innovations for accounting, you can use SAP S/4HANA Finance to defer the logistics process adaptations until later in the project. However, as a result, the new logistics functions will not be available until your logistics processes are adapted. These adaptation requirements need to be considered individually during the planning phase. -
Conversion procedures
The two variants differ in terms of technical structures and technical conversion procedures. Technically, SAP S/4HANA Finance is an exchange add-on that is based on SAP ERP 6.0 and requires the corresponding EHP (for SAP S/4HANA Finance 1605, the system must be updated to EHP 8). For system conversions to SAP S/4HANA, in contrast, the entire software core is exchanged. However, for customers, this detail in the technical procedure is unimportant because they can use SUM to execute the one-step approach for both variants.
10.2.2 Simplification List
The simplification list describes the potential adaptation work that is required to convert your SAP ERP system to SAP S/4HANA at the functional level. Simplification list items (for short, simplification items) illustrate the business adaptation requirements and effects to custom developments for each function described. For more complex modifications, the simplification items provide the relevant guides to support you.
The simplification list is an important tool for planning the conversion project and should be used at an early stage. You can implement many of the necessary adaptations on your existing SAP ERP source system. As a result, you’ll be able to start the conversion project before actually installing any SAP S/4HANA software. Consequently, the simplification list is an important source of information to schedule necessary conversion project tasks and assign the required resources.
The simplification list is supplemented by program-based analysis tools to help you identify relevant adaptation tasks, such as the Maintenance Planner, prechecks, and the custom code migration worklist, which we’ll describe in detail in the following sections.
The SAP Help for each SAP S/4HANA release includes the simplification list as a comprehensive document. In addition, the individual simplification items are available as separate SAP Notes.
In general, the functions listed in the simplification list can be divided into three categories:
-
Functions that are modified in SAP S/4HANA
Simplification items in this category refer to functions that are generally available in the same form in SAP S/4HANA but have been adapted in such a way that might affect existing processes and custom programs.[eg] Change of the Material Number Field Length
An example of a simplification item in this category is the extension of the material number field. In an SAP S/4HANA system, the MATNR domain has a field length of 40 characters. The field length of the MATNR domain in an SAP ERP system is 18 characters. Although the function of the MATNR domain in the material master of each system remains essentially the same, this difference in field length may affect your custom code. Usually, this change in the length of the field doesn’t affect your business processes because, after the system conversion, you can choose to use the longer material number field. If you want to use with 40 characters, you’ll have to take into account how this choice may affect other integrated systems. For more information on potentially necessary modifications regarding the 40-character material number, see SAP Note 2267140.
-
Functions that are no longer available in SAP S/4HANA in this form
Simplification items in this category refer to functions that are not available in SAP S/4HANA. In these cases, you can usually change to an alternative function already available in SAP ERP.
An example of this category is the credit management function as described in Section 10.2.1. For system conversions to SAP S/4HANA, you’ll have to consider changing to an alternative function and then implementing this function (for example, the advanced credit management function, SAP Credit Management). For more information on potentially necessary credit management adaptations, see SAP Note 2270544. -
Functions that do not map to the SAP S/4HANA target architecture
Simplification items in this category provide information on changes that are planned for SAP S/4HANA. This category includes functions from SAP ERP that are the same in the current SAP S/4HANA version but do not map to the target architecture. Usually, alternative functions are already available.
An example in this category is the warehouse management function of SAP Warehouse Management (SAP WM, see Chapter 1, Section 1.3.2). You can continue to use this function after the SAP S/4HANA system conversion, but SAP WM is not part of the target architecture. The target warehouse management architecture is SAP Extended Warehouse Management (SAP EWM).
Distributed across the various categories, the simplification list for SAP S/4HANA 1610 contains about 400 simplification items. Figure 10.7 shows how simplification items are distributed among these categories.
Figure 10.7 Simplification List Categories
Figure 10.8 shows how simplification items are distributed among functional areas.
Figure 10.8 Simplification Items in the Different Application Areas
Our experience from previous SAP S/4HANA conversion projects has shown that the average number of simplification items that customers may need to adapt is between 30 and 50.
[»] Additional Information
The SAP S/4HANA documentation for each release includes the simplification list as a comprehensive PDF document: https://help.sap.com/s4hana. In addition, the simplification list is also available in XLS format (including the corresponding application components) in SAP Note 2313884.
Each simplification item has a corresponding SAP Note (so-called business impact notes) that provides basic information and sometimes additional information and how-to guides. You can find the appropriate SAP Notes in the XLS document. Examples of individual business impact notes for simplification items include the following:
- SAP Note 2265093 (S4TWL – Business Partner Approach)
- SAP Note 2270544 (S4TWL – Credit Management)
10.2.3 Maintenance Planner
Using the Maintenance Planner is the first step in the prepare and planning phase of your SAP S/4HANA conversion project. The Maintenance Planner helps you simulate and plan the system conversion. The result is a comprehensive system landscape and maintenance plan. You can also decide whether to install the frontend server as a separate SAP Fiori installation or in combination with the backend server (see Chapter 9, Section 9.3).
The maintenance plan generated in the Maintenance Planner forms the basis for the subsequent steps in the system conversion. In addition, the Maintenance Planners checks the add-ons currently installed on your SAP ERP system and whether the enabled business functions are compatible with the SAP S/4HANA target release.
The SAP Support Portal provides the Maintenance Planner as a cloud-based application. Figure 10.9 shows how the Maintenance Planner accesses information about the customer landscape.
Figure 10.9 System Landscape with Maintenance Planner
The Maintenance Planner accesses the landscape data stored in your customer profile in the SAP Support Portal. The system landscape data in your customer profile is regularly updated via the Landscape Management Database (LMDB) of SAP Solution Manager and the System Landscape Directory (SLD) of your landscape. To access your individual customer data, you’ll require an S-User for the SAP Support Portal (or its predecessor, SAP Service Marketplace). The SAP Solution Manager user must be assigned to the S-User.
Call the Maintenance Planner as described in Chapter 9, Section 9.1, and select the Plan an SAP S/4HANA conversion of an existing system option to plan a single system conversion. In the guided steps, enter the SAP ERP system you want to convert, select the SAP S/4HANA target release, and specify the frontend server for the SAP Fiori user interface. After entering this information in the Maintenance Planner, you’ll receive the maintenance plan and a so-called stack XML, which contains information on the calculated start and target combinations. The maintenance plan is also available as a PDF document that includes a link to the SAP S/4HANA software that you want to install. You’ll need the stack XML that was generated in the Maintenance Planner during the system conversion. You can use the stack XML for the prechecks (which we recommend) and will use the stack XML in SUM to ensure that only compatible maintenance operations can be executed.
Not only can you use the Maintenance Planner to plan your future system landscape, you can use its guided procedure to check the add-ons currently installed on your SAP ERP system (SAP add-ons or partner add-ons) and whether the enabled business functions are compatible with the SAP S/4HANA target release. If add-ons or business functions in your SAP ERP source system are not (yet) supported by SAP S/4HANA, the Maintenance Planner will output an error message. However, future support for currently unsupported add-ons and business functions may be expected, so you should contact SAP or your partner provider. In some cases, you can also uninstall add-ons that are installed but no longer used to proceed with the system conversion.
If you have business functions active on your SAP ERP source system with the ALWAYS_OFF status in the SAP S/4HANA target release, you will not be able to convert the system to SAP S/4HANA. With SAP S/4HANA 1610, however, you’ll rarely encounter this problem.
[»] Additional Information
You can find additional information, links to blogs in the SAP Community Hub, and best practice guides in the SAP documentation for the Maintenance Planner at: http://help.sap.com/maintenanceplanner.
SAP Note 2214409 provides more information on supported SAP add-ons, and SAP Note 2392527 contains details on supported partner add-ons. Note that SAP cannot make any compatibility statements for uncertified partner add-ons. Consequently, the Maintenance Planner outputs a warning message for this category of partner add-ons. SAP Note 2240359 provides further information on this procedure.
10.2.4 Prechecks
SAP S/4HANA Pre-Transition Checks (prechecks) let you evaluate the adaptation requirements for your business processes when migrating to SAP S/4HANA. The prechecks are SAP programs (delivered in SAP Notes) installed and executed on the SAP ERP source system release, which will output a results log. These results correspond to simplification items, which we discussed in Section 10.2.2.
Prechecks are responsible for two tasks: identifying the relevant simplification items for the system conversion and ensuring that tasks that need to be executed before the system conversion are actually performed.
An example of a task that needs to be executed before the system conversion is included in the simplification item for the customer/vendor integration for business partners (see SAP Note 2265093). In SAP S/4HANA, SAP business partners must be used to benefit from IT-related advantages such as nonredundancy and data integrity. The corresponding precheck (provided in SAP Note 2210486) verifies whether a business partner exists for each customer and vendor. This precheck results in a list of customer and vendor masters that have not been implemented yet.
You’ll execute prechecks in the conversion project twice. You can (and should) first execute them in the prepare phase of the project 1. Additionally, further prechecks are automatically executed in the execution phase 2, called automatically by SUM when checking the prerequisites. If the mandatory activities have not been performed or if the prechecks have not been installed in the target system, the conversion procedures will pause, and an error log will be output.
For example, implementing customer/vendor master records for SAP business partners is a mandatory activity. Implementing this master data is a prerequisite for converting existing application data to the new data structure. Figure 10.10 shows when the prechecks are executed for the system conversion.
Figure 10.10 Execution of Prechecks
When executing the prechecks in the prepare phase (which we recommend), you can provide the conversion path if you include the stack XML that was generated in the Maintenance Planner. Based on the stack XML file, the SAP S/4HANA target release is taken into account when prechecks are executed, which can have an impact on the results log.
Executing Prechecks in the Prepare and Planning Phase
SAP Note 2182725 provides the central check report, R_S4_PRE_TRANSITION_CHECKS. Follow these steps to execute the prechecks:
- Implement SAP Note 2182725 (and all detailed notes listed therein) in Client 000 of all systems (i.e., DEV, QA, and PRD) of the system landscape you want to convert to SAP S/4HANA.
- Execute the R_S4_PRE_TRANSITION_CHECKS program in the client of all systems (using Transaction SE38 or Transaction SA38). Ensure that you are using the latest version of SAP Note 2182725.
To use information from the maintenance plan (for example, the target release), you should also use the stack XML that was generated in the Maintenance Planner to execute the prechecks in the planning phase. In general, the checks in accounting are also executed using the R_S4_PRE_TRANSITION_CHECKS report. Note, however, that the check for Asset Accounting (FI-AA) needs to be implemented and executed separately. For this purpose, implement the report provided in SAP Note 2333236.
Executing Checks in the Software Update Manager Check Phase
As described in the previous section, SUM will call and execute the prechecks again. Only if the prechecks do not have negative results will SUM proceed with the next step. If results are negative or if the precheck classes in the conversion system have not been implemented using SAP Notes, postprocessing work will be required.
[»] Additional Information
The check logic we described in this section is relevant for system conversions to SAP S/4HANA 1511, 1610, and higher releases. You can find more information on the check logic for converting SAP S/4HANA Finance 1605 in the documentation at https://help.sap.com/sfin.
The SAP S/4HANA Community blog at https://blogs.sap.com/2016/12/10/pre-checks-in-system-conversion/ also provides detailed information and instructions.
10.2.5 Adapting Custom Developments
Enterprises run business processes that differ from customer to customer and have had to adjust their SAP ERP system to these processes in the best possible way. In the past, enterprises frequently developed custom programs if the SAP Standard could not map these specific requirements.
The majority of SAP ERP systems probably contain additional custom program logic. SAP ERP provides various custom enhancement options from user and customer exits to Business Add-Ins (BAdIs) to modification of SAP Standard objects.
However, these enhancement options affect the release compatibility and the work required when changes are released . As with business functions, you’ll also have to check whether your customer-specific ABAP developments are still compatible with SAP S/4HANA’s data structure and functional scope when migrating to SAP S/4HANA. To check this compatibility, SAP provides the custom code migration worklist, a basic tool that enables you to check your enhancements, modifications, or custom developments for compatibility before the system conversion.
However, you should also leverage the migration to SAP S/4HANA to analyze your customer-specific ABAP developments in general. For example, modifying custom programs without checking whether they are used does not make sense. As a result, you should always carefully check automated inspection programs and service offers that some consulting firms provide for SAP S/4HANA conversions.
We recommend performing these steps for analyzing and adapting your customer-specific ABAP developments for the system conversion in the following order:
-
Analyzing and adapting custom developments in general:
- Transparency for custom developments (not used/hardly used, standard custom development)
- Optimization of custom developments (scale back, proven methods, performance optimizations)
-
Analyzing and adapting custom developments for the database migration to SAP HANA:
- Adaptation of custom developments that use specific characteristics of the predecessor database
- Performance optimizations on the basis of SAP HANA
-
Analyzing and adapting custom developments for the migration to SAP S/4HANA:
- Adaptation of custom developments that are no longer mapped in the solution scope and data structure of SAP S/4HANA
- Optional adaptation of custom developments with regard to functions that are not included in the target architecture of SAP S/4HANA
- Analysis and implementation of possible performance optimizations
[»] Additional Information
The following link provides information about the custom code adaptation process with links to related information: https://blogs.sap.com/2017/02/15/sap-s4hana-system-conversion-custom-code-adaptation-process/.
Analyzing and Adapting Custom Developments in General
Depending optimization needs, SAP customers have enhanced, modified, or added custom logic to standard business processes. This individual business process optimization can lead to increased costs for operating SAP software. For example, additional effort might be required for custom developments when releases are upgraded and support packages need to be installed. In general, system complexity increases with the number of custom developments. Considering the costs of custom developments, be sure to check them at regular intervals. As our experience from various customer projects have shown, 30% to 50% of custom programs are not used at all after a few years.
Consequently, you should first obtain an overview of your custom developments. You should always perform this basic task when migrating to SAP S/4HANA. To create this overview, use the SAP Custom Code Lifecycle Management tool set (CCLM) to analyze and manage the lifecycle of custom developments. Usage Procedure Logging (UPL) allows you to gain detailed usage information on custom objects.
Based on these analyses, you can now optimize your custom developments. The Decommissioning Cockpit lets you identify redundant or obsolete development objects and remove them from the customer system. You should also check whether your custom developments still in use correspond to the recommended programming and performance guidelines (best practices). Furthermore, you should determine whether your customer-specific enhancements can now be mapped by SAP Standard processes.
Of course, you can also perform these optimization tasks prior to the actual SAP S/4HANA conversion project. When migrating to SAP S/4HANA, you should also make yourself familiar with the new enhancement options in SAP S/4HANA, which were introduced in Chapter 3, Section 3.4.
[»] Additional Information
You can find blogs on enhancements and exchange information in the ABAP Development Community at:
You can find information about Usage Procedure Logging (UPL) at the following link:
For SAP Best Practices for the Decommissioning Cockpit, go to:
Analyzing and Adapting Custom Developments for the Database Migration to SAP HANA
Migrating to the SAP HANA database and the related database architecture changes (i.e., from a row-based to a column-based database) can affect custom developments. Although ABAP code continues to run on SAP HANA, you’ll have to adapt the custom developments that use specific characteristics of the predecessor database. Examples include:
-
Usage of native SQL
You’ll have to replace native SQL statements. -
Implicit sorting of results lists
You should insert explicit ORDER BY statements instead. -
Direct access to pool and cluster tables
You’ll have to modify code from pool and cluster tables.
In addition, you should analyze the performance optimization options in the SAP HANA database. Examples include:
-
Optimization of SELECT statements
You should replace general SELECT* FROM statements with SELECT statements with a restriction to the mandatory fields. -
Use the code pushdown option
You should analyze whether so-called code pushdown methods can be leveraged, that is, whether the data calculation logic can be moved to the SAP HANA database. Code pushdown methods use CDS technology (Core Data Services) and SQLScript.
To identify conversions that are mandatory or recommended for the database migration to SAP HANA, SAP Note 1935918 provides three check variants (FUNCTIONAL_DB, FUNCTIONAL_DB_ADDITION, PERFORMANCE_DB) for the Code Inspector.
The Code Inspector (which you can call using Transaction SCI, for example) is a generic tool to check repository objects for various aspects of static code. The SQL Monitor, which is available in SAP NetWeaver 7.40 (see SAP Note 1885926 for earlier releases), enables you to analyze the SQL statements in your customer systems.
[+] Optimizing Custom Code Using SAP Standard Tools
You can analyze your custom developments and prepare for migration before you start the actual SAP S/4HANA conversion project. The corresponding tools are available in SAP NetWeaver.
[»] Additional Information
To adapt custom developments for the migration to SAP HANA, see SAP Note 1912445. You can access a sample scenario at the following link:
For more information on code pushdown, go to:
For more on optimizing ABAP applications for SAP HANA, read ABAP Development for SAP HANA by Gahm, Schneider, Westenberger, and Swanepoel (2nd edition, SAP PRESS, 2016, www.sap-press.com/3973).
For more information on SAP HANA database migrations, go to:
For more information on the Code Inspector, go to:
Analyzing and Adapting Custom Developments for the Migration to SAP S/4HANA
Due to SAP S/4HANA’s new data structures and functional simplifications, you might have to adapt your existing custom developments when migrating to SAP S/4HANA. The custom code migration worklist identifies which custom developments you’ll need to adjust for migrating to SAP S/4HANA. Separate SAP Notes with instructions for the code adaptations are available for each adaptation result in the custom code migration worklist.
The custom code migration worklist contains migration tasks for custom developments. Based on Code Inspector technology, customer-specific repository objects are checked to determine if they use SAP entities that will change after migrating to SAP S/4HANA. Figure 10.11 provides an overview of how customer-specific ABAP developments are checked.
Figure 10.11 Custom Code Migration Worklist
- SAP entities that change with the migration to SAP S/4HANA are available as files in the SAP Support Portal (for more information, see SAP Note 2241080) and are imported to the so-called simplification database of the custom code migration worklist.
- The Code Inspector accesses the update information in an evaluation system (a customer system based on SAP NetWeaver 7.50 or higher) with the relevant SAP S/4HANA check variants (S4HANA_READINESS). Customer objects in the connected SAP ERP system are accessed via a remote connection.
- After the Code Inspector check has been executed, you’ll receive a results list containing the required adaptation items. References to the corresponding SAP Notes describe the relevant adaptation requirements for your custom developments.
[»] Additional Information on the Custom Code Check
You can find up-to-date custom code check content (i.e., simplification database content) in the SAP Support Portal. SAP Note 2241080 provides information on how and where you can download the content.
SAP provides the SAP S/4HANA simplification database content as a ZIP file on the SAP Support Portal. To download the file, open the SAP Software Download Center (https://support.sap.com/swdc) and search for the component “CCMSIDB.” Then, upload the file to your evaluation system. You can import the ZIP file using the SYCM_UPLOAD_SIMPLIFIC_INFO report or Transaction SYCM. In the transaction, choose Simplification DB • Import ZIP File (see Figure 10.12).
Figure 10.12 Importing the Content of the Simplification Database
Because SAP allows you to download the update information in a ZIP file, you can access this information anytime whether you use SAP S/4HANA already or not. SAP updates the ZIP file with every SAP S/4HANA release, feature package, and support package. You should therefore always use the most current version of the ZIP file.
You can analyze your custom developments using the Code Inspector (Transaction SCI). Based on the check variants provided for SAP S/4HANA, you can determine the set of objects to analyze and start the inspection run. The inspection run takes place in the evaluation system, which is based on SAP NetWeaver 7.50 or 7.51. From the evaluation system, the Code Inspector accesses objects in your SAP Business Suite system via a remote connection. Figure 10.13 shows the entry screen of the SAP Code Inspector with a check variant, the set of objects, and the inspection run.
Figure 10.13 Code Inspector for Analyzing Custom Developments
The S4HANA_READINESS check variant (see Figure 10.14), which is provided in SAP NetWeaver 7.51, allows you to compare custom objects to updated information for SAP S/4HANA. The included test variant, S/4HANA: Search for usages of simplified objects, checks custom developments by comparing them to the content of the simplification database.
S/4HANA: Field length extensions is an additional test variant that specifically checks for places in custom code that refer to the material number with 40 characters in SAP S/4HANA (see the example in Section 10.2.2).
Figure 10.14 Check Variant S4HANA_READINESS
To analyze your custom developments, you should restrict the set of objects to be evaluated, for example, to packages in the Z namespace, as shown in Figure 10.15.
The check variant and the set of objects to be analyzed are merged in an inspection run, as shown in Figure 10.16.
Figure 10.15 Restricting the Set of Objects
Figure 10.16 Inspection Run in the Code Inspector
As a result, the inspection run outputs a list of the custom developments that need to be checked and probably adapted (see Figure 10.17). The results list does not include customer objects that are not affected by changes in SAP S/4HANA.
Figure 10.17 Results List of the Inspection Run
In our example, the Code Inspector statistics indicate that about 25,000 objects in the Z namespace were analyzed in 13 minutes. The Code Inspector found that 259 objects of the 1,000 objects probably needed to be adapted. The results list breakdown shows details about the objects. In our example, 43 recommendations refer to SAP development objects that are no longer available in SAP S/4HANA. For each object in the results list, an SAP Note is provided that explains in detail which adaptations you’ll have to make for this type of object. Adaptations notes can include the following information, for example:
-
Adaptations resulting from the extension of the material number to 40 characters:
- SAP Note 2215424 (Field Length Extension for Material Number—General Information)
- SAP Note 2215852 (Field Length Extension for Material Number—Source Text Adjustments)
-
Adaptations resulting from data model changes in Sales and Distribution (SD):
- SAP Note (SAP S/4 HANA—Changing the Data Model in Sales and Distribution)
-
Adaptations resulting from data model changes in inventory management:
- SAP Note 2206980 (Stock Management: Changing the Data Model in SAP S/4HANA)
A list of modified SAP objects is maintained, and a corresponding adaptation note is provided, for each change that affects your custom developments described in a simplification item.
You can view the total list of modified SAP objects for SAP S/4HANA using Transaction SYCM. However, to do so, the ZIP file with the simplification database content must be imported. The list provides the type of modification (has the function or data structure changed, or is the function no longer available?) and the corresponding adaptation note for each SAP object. Table 10.1 illustrates this concept with some example SAP objects.
| SAP Object | SAP Object Name | Change Category | Adaptation SAP Note | Note Name |
|---|---|---|---|---|
| FUNC | FT_BASIC_OBJECTS_READ_DB | Function not available | 2223144 | SD Foreign Trade |
| PROG | MV52AF01 total | Function not available | 2223144 | SD Foreign Trade |
| TABL | MAZO | Function not available | 2223144 | SD Foreign Trade |
| … | … | Function not available | 2223144 | SD Foreign Trade |
| FUNC | /BEV1/RP_MIGERP01 | Function not available | 2224144 | Beverage solution |
| PROG | /DSD/ME_CPT | Function not available | 2224144 | Beverage solution |
| TABL | /BEV1/CAMF | Function not available | 2224144 | Beverage solution |
| … | … | Function not available | 2224144 | Beverage solution |
| TABL | FDSB | Modified function | 2270400 | Cash Management |
| PROG | RFLQ_ASSIGN_FI | Modified function | 2270400 | Cash Management |
| … | … | Modified function | 2270400 | Cash Management |
| TABL | BSAD | Modified function | 1976487 | FIN data model |
| TABL | BSAK | Modified function | 1976487 | FIN data model |
| … | … | Modified function | 1976487 | FIN data model |
Table 10.1 Sample Information in the Object List of the Change Database
Depending on the change category, the adaptation required varies. For customer projects that include functions that will be unavailable in SAP S/4HANA, you can assume that specific custom developments will become obsolete. As a result, you’ll have to check during the conversion project whether the successor function provided by SAP S/4HANA covers the business process, and you’ll have to consider alternative business process extensions. If the data structure has changed (for example, the material number extended to 40 characters), you’ll have to adjust the custom code according to the specifications in the SAP Notes.
The update information for SAP objects in the ZIP file from the SAP Support Portal always contains information on the latest SAP S/4HANA release so that you can analyze your custom developments regardless of the desired SAP S/4HANA target release, for example, if you have not chosen an SAP S/4HANA target release yet but want to analyze your custom developments. In addition, you should also analyze your custom developments based on the latest update information early on in an SAP S/4HANA release upgrade project (for example, upgrading from SAP S/4HANA 1511 to SAP S/4HANA 1610).
Distribution of the Adaptation Tasks in the System Group
The following lists the individual adaptation tasks in the SAP ERP and SAP S/4HANA system groups.
You can carry out the activities from Table 10.2 as preparatory steps in your existing SAP ERP system group.
| System Role | Activity |
|---|---|
| PRD system | Activating analysis tools such as SQL Monitor (SQLM), Usage & Procedure Logging (UPL), and Workload Monitor (Transaction ST03) |
| DEV system |
Analyzing custom developments considering three adaptation categories:
|
Table 10.2 Preparatory Measures in the SAP ERP System Group
The activities from Table 10.3 are then carried out in the SAP S/4HANA system group.
| System Role | Activity | ||
|---|---|---|---|
| Before the Conversion | During the Conversion | After the Conversion | |
| DEV system |
Analyzing custom developments considering three adaptation categories:
|
||
| QA system |
|
Functional tests and performance tests | |
| PRD system |
|
||
Table 10.3 Activities in the SAP S/4HANA System Group
10.2.6 Database Sizing for SAP S/4HANA
When migrating to SAP S/4HANA, you’ll also have to migrate the SAP HANA database if you do not already operate your SAP ERP system with SAP HANA. You’ll have to procure the required hardware and perform appropriate sizing for the database server before migrating to SAP S/4HANA and consider these steps in your planning.
Various options are available for sizing the SAP HANA database. One option is the Quick Sizer—a web-based tool designed for sizing new implementations of SAP HANA-based systems. For more information on the Quick Sizer, go to http://service.sap.com/quicksizer.
For system conversions, choose the /SDF/HDB_SIZING ABAP sizing report, which is provided with SAP Note 1872170. This sizing report analyzes the SAP ERP source system’s current memory and processing needs and outputs a report providing information on the requirements for the SAP HANA database.
[»] Additional Information on Sizing
You can find more information on sizing for SAP HANA at https://service.sap.com/sizing.
In addition, read SAP Note 2303847 for more information on the /SDF/HDB_SIZING sizing report including guidelines and FAQs.
10.2.7 Using Software Update Manager
The Software Update Manager (SUM) performs the technical steps for converting a single system. SAP Basis administrators have known about SUM since 2011. SUM is designed to reduce downtimes during software installation. The steps that SUM performs for SAP S/4HANA system conversions do not differ from the steps that SUM performs for SAP Business Suite upgrades. This section therefore focuses on steps specific to SAP S/4HANA or that are new.
SAP S/4HANA System Conversion Steps in Software Update Manager (SUM)
In general, SUM carries out three core tasks of various system conversion phases in one step:
-
Converting the software to SAP S/4HANA
SUM installs the new SAP S/4HANA software on the SAP ERP source system. For example, SUM replaces the SAP_APPL software component with the S4CORE SAP S/4HANA Basis component. -
Migration to the SAP HANA database
If your SAP ERP system is based on a different database, SUM migrates the database to SAP HANA using the Software Update Manager Database Migration Option (DMO). -
Converting the application data to the new SAP S/4HANA data structure
Because some data structures in SAP S/4HANA change (for example, data structure changes for stock management—table MATDOC), SUM converts the application data from the old data structure to the new data structure.
Figure 10.18 provides an overview of the different SUM phases.
Figure 10.18 System Conversion Phases in SUM
Based on the stack XML file generated in the Maintenance Planner, which contains the maintenance information, the system determines the best path to converting to SAP S/4HANA. Note that the conversion procedure cannot continue without the stack XML for the conversion system. Figure 10.19 shows the screen where you specify the location of the stack XML file.
In the first execution step, SUM analyzes prerequisites for the SAP S/4HANA system conversion. In addition to technical version checks for the operating system and the database version, SUM also analyzes the business requirements. The prechecks (see Section 10.2.4) are performed again. This check phase verifies, for example, whether the business partners have been assigned to customers and vendors. If not, the SUM procedure stops because this is a prerequisite for the next step: converting your application data from your old data structure to the new data structure in SAP S/4HANA.
Figure 10.19 Specifying the Stack XML file
In general, the system switch upgrade procedure is used for the SAP S/4HANA system conversion. With this procedure, an additional instance of the target release (shadow instance) is generated parallel to the live system. On this shadow instance, various SAP S/4HANA system conversion steps are then performed. During these steps in SUM, the administrator will be asked to specify the relevant target information for the new database. Figure 10.20 shows the screen for entering the SAP system ID (SID) and instance number.
Figure 10.20 Shadow Instance Access
The SAP Basis tables from the target release are then installed on the shadow instance. In parallel to the activities performed by SUM on the shadow system, normal operations can continue in your SAP ERP production system. When the production system is shut down, the downtime phase of the system conversion starts. In this SUM phase, the application data is converted from the old data structure to the new data structure, for example. Ideally, you only see that the SUM execution process is running, as shown in Figure 10.21.
Figure 10.21 SUM Steps during Downtime
The length of downtime depends on various customer-specific factors and optimization measures implemented in the conversion system. For example, the system resources used, the database size, the number of application data to be converted, and basic factors such as the customer network play important roles in downtime. Of course, downtime also depends on the system category. For example, you could accept other downtimes and might reserve less system resources for converting a test system.
After all conversion steps have been performed successfully, the SUM execution phase is completed, and the system will display the final screen shown in Figure 10.22.
The end of the execution phase sets the stage for the postprocessing phase during downtime. One postprocessing task is to convert accounting and controlling data and their corresponding Customizing data. For more information on converting financial data, see SAP Note 2332030, which includes reference to a conversion guide for accounting.
You can trace the execution of all steps in the SUM analysis file (UPGANA.XML), which provides detailed information on the system, the database size, and the runtimes of the individual SUM phases.
Figure 10.22 End of the SUM Execution Phase
The Different Procedures in Software Update Manager
SUM differentiates between three procedures and options for SAP S/4HANA system conversions:
- Default procedure
- Database Migration Option (DMO)
- Downtime-optimized procedure
The default procedure in SUM is when an additional shadow instance is generated on the same hardware to perform the conversion in parallel to running operations. You can use this default procedure (also referred to as in-place migration) for SAP S/4HANA if customers already use an SAP HANA database on their SAP ERP source system.
If the SAP ERP system is based on a different database, SUM migrates the database to SAP HANA. For this purpose, the Database Migration Option (DMO) is used. This SUM procedure is the same as the combined software update and database conversion within SAP Business Suite and is now also available for system conversions to SAP S/4HANA. In the first step, you’ll generate a shadow instance on the database of the source system in parallel to running operations. Next, the new SAP HANA database is built in parallel and filled with data from the shadow instance. During downtime, you’ll migrate your data to the new database. In SAP S/4HANA system conversions, you would then convert the application data to the new data structures. After these steps are completed and the postprocessing work done, you’ll use the system as an SAP S/4HANA system on an SAP HANA database. The source database remains unchanged with this procedure and is available as a fallback solution.
To optimize downtimes, you should monitor system loads in test runs and optimize if required. The DMO Migration Control Center (see Figure 10.23) lets you monitor running R3load processes.
Figure 10.23 DMO Migration Control Center
The downtime-optimized procedure allows you to implement further optimizations and is currently provided as a pilot procedure but poses higher requirements on system resources. For selected applications, the application data is converted from the old data structure to the SAP S/4HANA data structure during uptime, that is, in parallel to running operations. With this procedure, you’ll then only have to convert the new application data that accumulated during uptime and was recorded using a delta mechanism.
[»] Additional Information on Software Update Manager
You can find more information on the Software Update Manager (SUM) at:
The SAP Community Hub for SAP S/4HANA provides a SUM-specific blog at:
Also, you can read application-specific SAP Notes for system conversions. The following blog contains a collection of these SAP Notes:
10.2.8 Migrating to SAP Fiori User Interfaces
The simplification resulting from migrating to SAP S/4HANA is also directly connected to the new user experience provided by SAP Fiori. In the fourth quarter of 2016, SAP published its second-generation user interface with SAP Fiori 2.0. The new interface schema, Belize, generates an even more attractive user experience.
Chapter 2, Section 2.4, discussed the basic characteristics of these user interfaces, while this section explains how to switch from traditional, SAP GUI-based user interfaces to the new SAP Fiori interfaces. First, you’ll have to perform basic installation steps for SAP Fiori. A relevance analysis helps you determine which SAP Fiori apps are relevant for you. This relevance analysis is based on your transaction usage statistics. When implementing the SAP Fiori apps, you can migrate the applications gradually depending on the requirements of your users.
Installing SAP Fiori during the SAP S/4HANA Conversion
To use SAP Fiori, you’ll have to install it when converting to SAP S/4HANA. As described in Chapter 9, Section 9.3, you’ll need to install a frontend server.
After installing SAP Fiori components, you can configure the infrastructure including SAP Fiori launchpad. Analogous to installing SAP S/4HANA, the installation is integrated into the software logistics tools of the Maintenance Planner and Software Update Manager. Figure 10.24 illustrates selecting an installation variant in the Maintenance Planner.
Figure 10.24 Selecting SAP Fiori for Installation in the Maintenance Planner
You can use SAP Fiori 2.0 in combination with SAP S/4HANA 1610. However, this release is not yet available for SAP S/4HANA 1511. Technically, SAP Fiori 2.0 is based on SAP Fiori Frontend Server 3.0. To use SAP Fiori Cloud (see Chapter 9, Section 9.3.2) for SAP S/4HANA, SAP S/4HANA 1610 needs to be installed with a separate license.
Relevance Analysis for SAP Fiori Apps
The Relevance and Readiness Analysis in the SAP Fiori apps reference library is an analysis tool that helps you identify the SAP Fiori apps that are relevant for you. The tool analyzes which transactions you use in your source system and generates a list of recommended apps. Figure 10.25 shows a common results list of the relevance analysis.
Figure 10.25 Relevance Analysis for SAP Fiori Apps
You can use the Workload Monitor (Transaction ST03) to perform the usage analysis of the transaction data, for example. This usage data is then uploaded into the tool as a CSV file, and the tool analyzes the relevance of individual transactions and determines which SAP Fiori apps correspond to your most-used SAP GUI transactions.
Customizing the Conversion
The options provided by SAP S/4HANA’s new, attractive, intuitive, and efficient user interfaces are just one dimension of a conversion project. Another dimension is how to migrate to the new user interfaces and their new way of working.
In this section, we’ll address migrating from traditional user interfaces to the new SAP Fiori-based user interfaces, which will be available after the conversion project is completed. However, you can continue to use SAP GUI transactions after converting your system to SAP S/4HANA. In general, all of your users’ transactions and favorites before the upgrade will still be available in the ABAP backend after the system conversion. Exceptions include transactions that are omitted in SAP S/4HANA for simplification reasons and for which the simplification list communicated modifications.
Note that SAP S/4HANA’s new functions are usually only provided with SAP Fiori-based user interfaces. Thus, the question is not whether you migrate to the new user interfaces but how you perform the migration and which steps you carry out.
Figure 10.26 illustrates a possible gradual migration from traditional SAP ERP user interfaces to a target architecture based on SAP Fiori.
Figure 10.26 Gradual Migration to New User Interfaces
Following this model, you would first introduce SAP Fiori launchpad, which will serve as the central, web-based entry point for all users that will use the SAP S/4HANA system. In SAP Fiori launchpad, you can consolidate applications from various user interface technologies (for example, SAP GUI, portals) on multiple devices (desktop PC, tablet, or smartphone).
You can integrate traditional user interfaces and continue to use your functions and business processes in the same way as before the system conversion.
For example, you can integrate a selection of Web Dynpro-based and SAP GUI-based applications from your ABAP backend or integrate entries from the SAP Easy Access menu with SAP Fiori launchpad. As of SAP S/4HANA 1610, on-premise, the design of traditional interfaces has also been adjusted to match the design of SAPUI5-based SAP Fiori apps to support a uniform user experience.
Immediately after you have converted your system, you should grant end users role-based access to the SAP Fiori launchpad. In role-based access, you’ll break down complex applications into useful task-based subunits. End users will only access the user interfaces they require for carrying out the steps for which they are responsible and authorized to perform.
For example, managers need different information than administrators. Managers often process approval steps on their mobile end devices, while administrators often need access to detailed interfaces to process exceptional cases. If you use predefined roles and authorizations, you can define which apps, and what data, users are authorized to access.
The App Finder (the app store in SAP Fiori launchpad) enables users to select the apps for their roles that support their tasks in the best possible way. In this context, whether the app is an SAP Fiori, SAP GUI, or Web Dynpro ABAP application does not matter. You can also integrate custom SAP Fiori apps into the App Finder.
In a next step, you can decide whether to use SAP Fiori apps even further and replace all of your traditional user interfaces. Many enterprises start this migration by modifying their individual process steps.
For example, you can adapt approval processes or processes for travel expenses mainly for mobile end devices, which may be used most often. Next, you can adjust core business processes that affect a limited number of users. Then, you can modify business processes that affect the majority of your end users.
Ultimately, you’ll have to decide yourself how and how quickly you want to migrate to the new SAP Fiori user interfaces.
[»] Additional Information
You can find additional information about the SAP Fiori’s Relevance and Readiness Analysis in the SAP Fiori apps reference library or via the following link: https://fioriappslibrary.hana.ondemand.com/sap/fix/externalViewer/docu/Relevance_and_Readiness_Document.pdf.
The “SAP Fiori 2.0 Administration and Developer Guide” (https://experience.sap.com/documents/sap-fiori-2-0-administration-and-developer-guide.pdf) explains how to integrate Web Dynpro-based applications and SAP GUI-based applications into the SAP Fiori launchpad.
For more information on the new interface schema Belize and its availability in SAP GUI for HTML, SAP GUI for Java, and SAP GUI for Windows, read SAP Note 2365556.
For more information on the App Finder, go to https://experience.sap.com/fiori-design-web/app-finder/.