9.2    System Conversion Options and Approach

This section addresses the conversion options and approach to SAP S/4HANA for organizations that are already using SAP and want to move from their classic SAP Business Suite system to SAP S/4HANA. The system conversion scenario is only applicable for SAP customers who are already using a previous SAP ERP version and want to move to on-premise SAP S/4HANA. It’s not possible to perform a system conversion to SAP S/4HANA Cloud.

Note

The section assumes that a migration scenario is the logical progression for you. If you’re considering a new implementation, refer to Section 9.1.

We’ll cover the adoption road map based on your current starting point by taking into account the SAP system upgrade and conversion scenarios; what to expect from code HANA-tization, including SAP HANA code optimization; and how to perform the migration of data from the old data structures to the new simplified structures.

SAP provides a clear road map and sequence to move to SAP S/4HANA, on-premise edition, while adopting the system conversion transformation scenario (see Figure 9.4). Preparation is key when converting to SAP S/4HANA, and a set of tools and accelerators are available to download via SAP Notes to assess the impact of the move to SAP S/4HANA and determine whether this transformation scenario is an option for you. The tools and related SAP Notes are provided in Section 9.2.3. Given that some functionalities aren’t currently supported, or are supported with restrictions, by SAP S/4HANA, a system conversion may not always be possible.

Figure 9.4    On-Premise SAP S/4HANA: System Conversion Sequence

9.2.1    Scenarios

Depending on your current SAP landscape, there are various SAP S/4HANA adoption scenarios for the on-premise edition. You may convert in one step from the following:

• SAP ERP 6.0 any EHP on a non-SAP HANA database
• SAP Business Suite powered by SAP HANA

We’ll look at each of the adoption scenarios mentioned and evaluate the most suitable option based on your current starting point in the following sections.

9.2.2    Adoption Paths

Depending on your current landscape, a number of paths will help you get to an end state of SAP S/4HANA. However, it can be challenging to understand which conversion path is the correct one for your organization. Assuming a conversion scenario is the logical progression for customers who are running on SAP ERP 6.0 on any non-SAP HANA database, the objective is to move to either SAP Business Suite on SAP HANA or SAP S/4HANA.

For SAP customers who decide to move to SAP Business Suite on SAP HANA as an interim step, enabling the SAP S/4HANA innovations, such as SAP S/4HANA Finance or SAP S/4HANA’s logistics functionality (e.g., SAP S/4HANA Material Management and Operations, discussed in Chapter 4) is the next step. Dependent on the existing SAP ERP version in your SAP landscape, there are different approaches to perform the conversion from an SAP ERP 6.0 system running on a non-SAP HANA database to the SAP S/4HANA end state.

With the release of SAP S/4HANA 1605, SAP has created two SAP S/4HANA adoption paths (see Figure 9.5) for SAP customers. SAP S/4HANA Finance 1605 contains the finance-only simplifications, whereas SAP S/4HANA 1511 and 1610 contain the full SAP S/4HANA Enterprise Management solution. Please note that 1610 contains SAP S/4HANA Finance 1605 by default as part of its code line; SAP S/4HANA 1511 does not.

Figure 9.5    System Conversion Scenarios for SAP S/4HANA

SAP S/4HANA Finance 1605 is an enhancement of the previous SAP S/4HANA Finance version 1503. Although SAP S/4HANA 1605 was released after SAP S/4HANA 1511, it’s not possible to move from SAP S/4HANA 1511 to SAP S/4HANA Finance 1605.

• SAP S/4HANA Finance (versions 1503 and 1605)
• SAP S/4HANA Enterprise Management (version 1511 and version 1610)

Based on the business case, your organization will need to assess whether SAP S/4HANA Finance or SAP S/4HANA Enterprise Management is the right option. SAP S/4HANA Finance can be used as a stepping stone to benefit from some of the SAP S/4HANA functionality while reducing the change impact associated with the overall move to SAP S/4HANA Enterprise Management. Although this may seem like an attractive approach, SAP customers that are looking to benefit from the SAP S/4HANA’s logistics functionality and the other SAP S/4HANA simplifications in the near future will still have to undertake a second system conversion to benefit from these features.

With all of these different scenarios, it’s hard to define which option may be best for you. The decision will need to be backed by a business case, but if you’re currently running SAP ERP 6.0, it’s technically possible to migrate in one step to SAP S/4HANA, assuming the downtime window is acceptable for your organization.

The following subsections describe the two most common system conversion options available based on the SAP ERP release you are currently running on: two-step approach and one-step approach.

Two-Step Approach: Source Release Lower Than SAP ERP 6.0 on Any Database

If you’re currently running your SAP ERP environment on a version lower than SAP ERP 6.0, and you want to pursue the system conversion route, you’ll need to upgrade your existing SAP system to a release that will allow you to perform the system conversion, in one step, using the Database Migration Option (DMO) of Software Update Manager (SUM). If your SAP system isn’t yet Unicode compatible, you can perform the Unicode conversion as part of the first upgrade phase because this is mandatory requirement to migrate to SAP S/4HANA.

You can perform the Unicode conversion at a later stage, however, if your target SAP S/4HANA version will be running on AS ABAP 7.5, the DMO won’t be able to handle the Unicode conversion at the same time. Therefore, you should complete the Unicode conversion as early as possible.

The recommended target version for the first step in a two-step approach is to move to SAP ERP 6.0 EHP 7 or above and perform the Unicode conversion at the same time. If you have a non-Unicode system, it isn’t possible to move directly to SAP ERP 6.0 EHP 8, given that EHP 8 runs on SAP NetWeaver 7.5, and the system requires a Unicode source system, as previously mentioned.

One-Step Approach: Source Release SAP ERP 6.0 or Higher on Any Database

If your SAP system currently runs on SAP ERP 6.0, performing the EHP upgrade and the technical database migration to SAP HANA can be combined, again assuming the downtime window is acceptable for the business.

If the downtime window isn’t achievable, you should consider downtime optimization. Various options are detailed in Section 9.6. The alternative option is to separate these two activities. As a first step, you can perform the upgrade and SAP HANA database migration by taking your current SAP ERP system to SAP Business Suite on SAP HANA.

The second activity consists of converting your system from SAP Business Suite on SAP HANA to SAP S/4HANA. This activity transfers your data from the old data structures to the new simplified structures, allowing your organization to benefit from the new simplified processes available within SAP S/4HANA. A small upgrade is also included as part of the system conversion.

9.2.3    Tools for System Conversion

The conversion to SAP S/4HANA is split into two main areas (see Figure 9.6):

• The technical conversion that consists of installing the new SAP software and/or migrating to the SAP HANA database
• The functional conversion that requires a clear understanding of the simplification list, performing the conversion pre-checks, and assessing the impact that SAP S/4HANA may have on your custom code and enhancements.

In this section, we’ll look at how these tools can support the conversion and what outputs they provide.

Figure 9.6    System Conversion Tasks for SAP S/4HANA

Technical Conversion Tools

SAP has been supporting its system upgrades and migrations for many years. This has given them the opportunity to build a well-established set of tools to support these types of transformation projects. Although SAP S/4HANA introduces additional complexity associated with the simplifications introduced with the new code line, the technical migration remains fairly straightforward and relies on tools that many of you have used in the past.

Maintenance Planner

Most SAP technical architects or Basis consultants are familiar with SAP’s Maintenance Optimizer; however, this is no longer directly used for the system conversions to SAP S/4HANA. Maintenance planner is now the prerequisite to executing the system conversion to SAP S/4HANA.

The maintenance planner is the successor of Maintenance Optimizer and is hosted by SAP to help SAP customers manage their landscape transformation changes. The maintenance planner also generates the stack XML that used to be obtained via the Maintenance Optimizer.

Before the conversion to SAP S/4HANA starts, the maintenance planner checks the system with regard to add-ons, business functions, or even industry solutions. If any restrictions are identified, the maintenance planner stops the conversion from moving ahead. You don’t have to wait to start the system conversion project before running the maintenance planner. This should be run as part of the preparation phase to identify any issues as early as possible. Any remediation items can be managed before the SAP S/4HANA conversion project starts, if the system conversion is still a viable option based on the results provided.

Software Update Manager

Similar to SAP upgrades, SUM is used in the conversion to SAP S/4HANA, on-premise edition. As you’ll see in Section 9.3.2, the latest version of SUM must be used.

You’ll need to run the maintenance planner before running SUM, as explained in the previous section.

Database Migration Option

For those of you already familiar with SAP Business Suite on SAP HANA and have already undertaken the migration to an SAP HANA database, DMO will be familiar.

DMO is what allows SAP customers to move from SAP ERP 6.0 to SAP S/4HANA in one step. In combination with SUM, DMO performs the database migration from any database to SAP HANA. The combination of both tools is referred to as the DMO of SUM.

The DMO of SUM will be used for SAP customers moving to SAP S/4HANA who are running SAP ERP 6.0 on any database. For SAP customers who are already using SAP Business Suite on an SAP HANA database, only SUM is required to move to SAP S/4HANA.

The technical conversion is only one part of the overall conversion process that is required as part of the SAP S/4HANA conversion journey. Additional functional checks must be completed to assess the impact of the new SAP S/4HANA code line and simplifications items on your existing SAP environment.

Functional Conversion Tools

This is the area where the conversion becomes challenging, but SAP has made good progress and provides additional tool sets to support the SAP S/4HANA conversion. Although multiple tools are available, don’t underestimate the time and effort required to get the solution right. Multiple challenges can be expected along the way.

Planning is key to a successful SAP S/4HANA conversion, and the following tools below can help get you started at an early stage.

Simplification List for SAP S/4HANA

The simplification list is a document provided by SAP that helps SAP customers understand the impact of the simplifications associated with SAP S/4HANA. Hence, the simplification list facilitates the planning and effort estimation associated with an SAP S/4HANA conversion project.

Note

The simplification list is version dependent. Each time SAP releases a new Feature Package Stack (FPS) for a given SAP S/4HANA version, a new simplification list is delivered for that version. Therefore, you need to make sure you have the correct simplification list based on your target SAP S/4HANA conversion version.

In this list, SAP describes the functional impact that SAP S/4HANA has on the individual transactions and the associated solutions. In certain cases, solutions may have been merged or simplified with a new architecture compared to the source systems from which you’re performing the conversion.

The document also provides a set of recommendations on how to adjust your custom code based on a series of SAP Notes provided within the document.

Prechecks for SAP S/4HANA

As part of the system conversion, SUM runs a set of prechecks to ensure that all the activities required to convert to SAP S/4HANA have been completed. If any activities haven’t been carried out, SUM stops the conversion process.

To provide additional time and flexibility to carry out these prechecks, SAP has provided the precheck report as a standalone executable that you can complete prior to starting the SAP S/4HANA conversion. Again, similar to the simplification list, this report helps plan the activities and efforts associated with the move to SAP S/4HANA.

Note

Report R_S4_PRE_TRANSITION_CHECKS is available within SAP Note 2182725 (S4TC Delivery of the SAP S/4HANA System Conversion Checks). This SAP Note needs to be implemented in your source system, as well as the SAP Notes mentioned in the manual activities of the same document.

You can run the report as often as needed in simulation mode without creating any logs. With the simulation mode inactive, the report logs are saved in the application log and can be displayed at a later stage if required. Figure 9.7 provides a sample output of SAP precheck report R_S4_PRE_TRANSITION_CHECKS. At this point, you analyze the output and take action accordingly. The green lights (squares) don’t require any specific action, but you must address red lights (circles) before moving forward with the SAP S/4HANA conversion.

Figure 9.7    Sample Output for Report R_S4_PRE_TRANSITION_CHECKS

After you’ve addressed all the precheck issues, you can move ahead with the conversion to SAP S/4HANA.

Simplification Database for SAP S/4HANA

With the release of SAP S/4HANA 1511, SAP has created the simplification database, which is based on the same concept as the simplification list. The simplification database will be updated for each SAP S/4HANA Enterprise Management version (e.g., SAP S/4HANA 1610). The simplification database helps identify the simplification impact SAP S/4HANA has on the existing custom code running in your system.

The simplifications are downloaded in a ZIP file from the SAP Marketplace and need to be imported into an SAP NetWeaver 7.5 system.

Note

Information on how to download the simplification database is available in SAP Note 2241080 (Custom Code Check Content for SAP S/4HANA, On-Premise Edition).

To understand how these simplification items impact your existing SAP system, an extraction of your custom code is required in the source system that you plan to convert to SAP S/4HANA.

After the custom code extraction program has been run, the ZIP files generated from the output need to be loaded into the SAP NetWeaver 7.5 evaluation system where you previously imported the simplification database.

When the load is complete, report SYCM allows you to select the ZIP file that contains the extract of your custom code and run this against the simplification database. An example of the extraction process and output is shown in Figure 9.8.

The output of the report is also referred to as the custom code migration worklist.

Figure 9.8    SAP S/4HANA Custom Code Migration Worklist

Similar to the simplification list, the output from the custom code migration worklist report will provide you with a series of SAP Notes explaining how to adjust your custom code. In addition, drilldown functionality is available to analyze which code line is impacted in the custom program and which functional area the simplification is associated to. This list of tools will help you understand the impact of SAP S/4HANA on your custom code but won’t replace areas covered as part of the Code Inspector, which we’ll discuss in the following section regarding code remediation, HANA-tization, and optimization.

9.2.4    Code Remediation, HANA-tization, and Optimization

As part of the move to SAP S/4HANA, code adjustments will be required; the amount of adjustments will vary based on the volume of custom code and the source version you’re converting from. These code adjustments fall into three main categories: code remediation, code HANA-tization, and code optimization.

Code remediation is required following an SAP upgrade. The upgrade contains code changes and introduces new functionality that can impact the existing ABAP code in your SAP system. Certain features may also become obsolete and may need to be replaced as part of the code remediation process.

Standard SAP code should work as normal; however, custom code may need to be remediated to ensure that it’s still working as expected. Code remediation may be required due to additional fields added in a primary key of a table associated with a sequence of screen changes in a batch data communication (BDC) program, obsolete function modules, or even prior changes to SAP programs using access keys that conflict with the new upgrade code.

Similar to SAP upgrades in the past, adjustments with Transaction SPDD and Transaction SPAU will also be required as part of your move to SAP S/4HANA. The adjustments are required when existing SAP standard objects are overwritten with the objects delivered as part of the higher SAP version you’re converting to. During the SAP S/4HANA conversion, the developer responsible for the code remediation adjustments can decide, in agreement with the business, to retain or overwrite the objects based on any adjustments that may have been made in the previous SAP releases.

As mentioned, these adjustments are split into two categories: Transaction SPDD and Transaction SPAU. Transaction SPDD adjustments refer to the list of all modified Data Dictionary (DDIC) objects, tables, data elements, and so on. Any adjustments required to these objects can be addressed within Transaction SPDD.

Transaction SPAU adjustments refer to note corrections and modification with or without the modification assistant. The developer needs to decide whether to adopt these modifications or reset them to the original statuses. All objects then need to be activated after the change.

Whether you’re running SAP Business Suite on SAP HANA or SAP S/4HANA, an additional type of adjustment is required to allow the ABAP code to run on the SAP HANA database. This is referred to as code HANA-tization and is required to make sure the code is compatible with the SAP HANA database. Previously, most of the code that consumed a lot of the system resources was managed within the application layer. However, to benefit from the in-memory architecture available within the SAP HANA database, the code needs to be adjusted.

With the conversion to SAP S/4HANA, the ABAP code adjustments can be split into two categories:

• HANA-tization
  Represents the mandatory adjustments required to run the existing ABAP code on an SAP HANA database.
• Code optimization
  Refers to the modification in the ABAP code to make it optimal and run faster to benefit from the SAP HANA functionalities. SAP HANA code optimization leverages items such as SAP HANA modeling with code pushdown that delegates the data-intense calculations to the database layer.

SAP provides a set of standard tools to help with code analysis for HANA-tization. The Code Inspector (see Figure 9.9) and ABAP Test Cockpit identify the existing SAP code that needs to be HANA-tized. SAP provides a set of variants within these tools that help identify the mandatory requirements associated with code HANA-tization.

The Code Inspector performs the code analysis based on the selected variant that contains the list of SAP development objects. The Check Variant area of the screen contains the information to perform the analysis, for example, “FUNCTIONAL_DB” in the Name field in Figure 9.9. The Object Set area defines the ABAP objects where the HANA-tization inspection needs to be performed.

Note

You should use the FUNCTIONAL_DB variant in the Code Inspector. This check variant is delivered with SAP Note 1935918 (Downport Code Inspector Check Variants for HANA Migration), and it helps initiate the HANA-tization process.

Figure 9.9    SAP Code Inspector Screen Selection

The FUNCTIONAL_DB variant contains checks that are mandatory for the analysis of ABAP custom code required as part of the move to SAP HANA.

The HANA-tization requirements are classified into seven categories: Native SQL, database hints, location of ABAP Database Connectivity (ADBC) usages, location of special ABAP Dictionary function modules, database operations on pool and cluster tables, problematic SELECT/OPEN CURSOR by statements and depooling/declustering, and location of non-robust ABAP code. A few examples of these categories are described in detail in the following list:

• Native SQL
  Native SQL refers to the custom code that uses Native SQL statements specific to an underlying database. Native SQL bypasses the synchronization of the SAP table buffers and can potentially cause data inconsistencies. An example of a native SQL statement is given in Listing 9.1.

  EXEC SQL
    SELECT WERKS,ALAND,WKREG,WKCOU
      INTO :w_vbrp
      FROM vbrp
    WHERE VBELN = :lv_vblen
  ENDEXEC.

  Listing 9.1    Example of a Native SQL statement

  The adjustments for Native SQL as part of the HANA-tization process means that they have to be rewritten as Open SQL in ABAP. These corrections can be made either before or during the migration project to the SAP HANA database.
• Database hints
  Database hints contain specific database code. In Figure 9.10, the database hint refers to an Oracle database and should only be used in exceptional cases. This can force the underlying database to work in a way different from what is expected as part of the standard SAP functionality.
  

  Figure 9.10    Example of a Database Oracle Hint

  The adjustments for database hints are straightforward. These can be commented out, but this activity can only be completed after the migration to SAP Business Suite on SAP HANA or after SAP S/4HANA has been completed.
• Database operations on pool and cluster tables
  Database operations on pool and cluster tables refers to the ABAP code having direct access to the physical pool. After depooling/declustering, these accesses become hard errors. An example of a database operation on pool and cluster tables is shown in Figure 9.11. After depooling/declustering is complete, the logical table is converted to a transparent table; however, the physical pool or cluster is still there but remains empty. This allows you to benefit from the SAP HANA analytical capabilities.
  

  Figure 9.11    Example of Database Operation on a Pool and Cluster Table (Table Clusters)

  Per SAP’s ABAP best practices, database operations should be avoided on these physical tables but not on logical tables.
  The adjustments for database operations on pool and cluster tables require a rewrite of the code avoiding database operations. These corrections can be completed prior to the SAP HANA migration start.
• Problematic by statements and depooling/declustering
  Depooling/declustering requires a search for SELECT and OPEN CURSOR statements for pool or cluster tables where no ORDER BY clause is specified. This becomes an issue when the order of the returned database entries changes if the database table is modified into a transparent table. An example of a depooling/declustering is shown in Figure 9.12.
  

  Figure 9.12    Example of Depooling/Declustering

  Per SAP’s ABAP best practices, results should be sorted when the result is stored manually in an internal table. These corrections can be done prior to the start of the SAP HANA migration.

In the previous examples, we’ve captured a few areas that require adjustments to run on the SAP HANA database platform. These issues will be flagged by the Code Inspector and classified into three categories (see Figure 9.13):

• Errors (red)
• Warnings (yellow)
• Information (green)
  

  Figure 9.13    Sample of SAP Code Inspector Output

Sometimes these modifications will be mandatory, such as the errors in Figure 9.13, whereas others will just be recommendations.

For the SAP conversion scenarios described in Section 9.2.1, modernization and optimization of the remaining custom code is a separate activity, possibly driven by other business change requirements or transformational requirements. For new implementations, SAP S/4HANA-enabled custom code is the default.

Note

For SAP HANA code remediation best practices and considerations, additional information can be found in SAP Note 1912445 (ABAP Custom Code Migration for SAP HANA - Recommendations and Code Inspector Variants for SAP HANA Migration).

9.2.5    Application-Specific Conversion Steps

In addition to the assessments that are completed with the simplification list, the simplification database, and the SAP S/4HANA prechecks, some application-specific conversion activities are required to complete the data conversion to SAP S/4HANA after the installation of the software.

The activities required for each of these applications will vary based on the target SAP S/4HANA version you’re converting to. For example, if you’re converting to SAP S/4HANA Finance 1605, only the FI activities will be required. The SAP S/4HANA finance and logistics activities will apply if you’ve decided to convert your system to SAP S/4HANA 1511 or SAP S/4HANA 1610.

SAP S/4HANA Finance Data Conversion

The SAP S/4HANA Finance data conversion process is tied closely to the overall SAP S/4HANA system conversion and can’t be executed in isolation.

Prior to performing the application-specific follow-on activities, it’s important to ensure that the steps already addressed in this chapter have been completed, as follows:

1. Complete the system prechecks to ensure that SAP S/4HANA Finance can be installed.
2. Execute the functional prechecks to ensure the completeness of the financial data.
3. Assess and perform any adjustments to custom programs that may be required to ensure a smooth execution of the finance function after go-live.

In addition to these checks, you must have completed the system reconciliation between the different finance applications. This will ensure the data will be merged into the Universal Journal (table ACDOCA) without any issues. Month-end activities for the previous period also must be completed prior to starting the data migration from the old data structures to the new ones that are available with SAP S/4HANA.

Additional migration and configuration requirements are required for the following FI functions:

• SAP General Ledger (new G/L)
• New Asset Accounting (new FI-AA)
• SAP Cash Management powered by SAP HANA

After the configuration steps are completed for these items, the execution of the data conversion can proceed from the old data structures to the new ones.

SAP S/4HANA Logistics Data Conversion

Similar to what is required in the SAP S/4HANA Finance application-specific conversion activities, SAP S/4HANA’s logistics functionality requires some additional steps as well, although these steps aren’t as manually demanding.

During the SAP S/4HANA logistics preparation, you must complete the activities that are included as part of the prechecks. For example, a conversion to the new data structure for the material number is required as the material number changes from 18 to 40 characters when moving to SAP S/4HANA.

In addition to the material number extension adjustments, a fundamental change in SAP S/4HANA logistics functionality is the introduction of the mandatory business partner approach. This requires additional Customizing settings to be completed and checks to be performed to ensure customer and supplier integration is complete, as all customers and vendors are set up as business partners in SAP S/4HANA Enterprise Management.

The detailed step-by-step conversion requirements are available within the target conversion guides for the associated target SAP S/4HANA version. This includes the associated FPS that you’ve decided to convert. These documents are available on the SAP help forum at http://help.sap.com/s4hana.