4.2    The Three Migration Scenarios

SAP has defined several technical scenarios for the introduction of SAP S/4HANA and also provides the corresponding tools. When planning the migration, you should select the scenario that meets your individual requirements best. The following sections introduce the individual scenarios and describe the advantages and disadvantages of each approach. Part III then discusses the different scenarios in detail. Three basic scenarios for the migration to SAP S/4HANA exist (see Figure 4.3):

The landscape transformation also includes the steps of the first two scenarios and complements them to further benefit from SAP S/4HANA.

The Three Scenarios for the Migration to SAP S/4HANA

Figure 4.3    The Three Scenarios for the Migration to SAP S/4HANA

Except for the system conversion, all three scenarios allow you to choose whether you want to implement SAP S/4HANA as a software as a service (SaaS) in the cloud or as an on-premise implementation (see Chapter 3, Section 3.1).

4.2.1    New Implementation of SAP S/4HANA

From the technical perspective, this scenario is based on a completely new installation of SAP S/4HANA. In this scenario, we’ll use the Software Provisioning Manager (SWPM) to download and set up an SAP S/4HANA system from the available SAP installation media, creating a new system with a new System Identification (SID). In addition to this ABAP instance, a frontend server is also installed, which will be the central hub for operating the SAP Fiori user interface.

At first, the new system is delivered with a standard configuration. You’ll then have to adapt the configuration to meet the requirements of the business processes you want to implement.

The new system can be fed data from a source system, using the SAP S/4HANA migration cockpit, a tool that has been developed for SAP S/4HANA. Whether the data is from an SAP system or from a non-SAP system does not matter. When the data has been transferred, you can replace the source system with the SAP S/4HANA system (see Figure 4.4).

New Implementation of SAP S/4HANA

Figure 4.4    New Implementation of SAP S/4HANA

SAP provides predefined models for the data transfer, so-called migration objects. These objects regularly get updated or new objects added with new SAP S/4HANA versions. Table 4.1 lists which migration objects are supported at the time of this writing (SAP S/4HANA Cloud 1611 and SAP S/4HANA 1610, on-premise).

For more details on using migration objects, see Chapter 7, Section 7.3.1, (for cloud editions) and Chapter 11, Section 11.2 (for on-premise editions).

Supported Migration Objects When Using the Migration Cockpit
Activity Price Exchange Rate Bill of Materials (BOM)
Internal Order Inventory Balances Work Center
Profit Center Material Master Routing
Bank Master Material – Long text Equipment
Customer Purchasing Info Record Maintenance Task List
Supplier Purchase Order Functional Location
Accounts Receivable (Customer) Open Item Pricing Condition Characteristic
Accounts Payable (Vendor) Open Item Contracts (Purchasing) Class
Fixed Assets incl. Balances Source List Commercial Project Management (CPM)

Table 4.1    Supported Migration Objects for Data Migration Using the SAP S/4HANA Migration Cockpit

Default data fields, the format, and—if available—relationships or references to other business objects are defined for each of the business objects in migration objects.

Following the simplification concept, only the most important data fields of each object are already activated in this predefined content. If needed, you can optionally display additional fields, if available in the SAP Standard. Custom fields (in custom namespaces) can also be supplemented. For on-premise implementations, you would use the SAP Landscape Transformation (LT) Migration Object Modeler (LTMOM) transaction for this purpose; for cloud solutions, please contact the SAP service team.

The selected migration objects are transferred to the project view of the SAP S/4HANA migration cockpit. In the cockpit, at any time during the data transfer, you’ll be able to see what object data still has to be loaded and for which objects the migration has been completed.

The source system data is formatted manually as required. If data needs to be cleansed (for example, if duplicates need to be identified and eliminated), you should address these issues before migrating the data. The cleansed data from the source system is stored in a file in a format defined by SAP. The relevant templates are provided by default.

In the next step, this file is uploaded. Basic inconsistencies in the data that is planned to be imported to the target system or conflicts in the configuration are determined by tools and can be eliminated. Then, the data transfer from the source system is complete. Figure 4.5 illustrates these steps.

Steps for the Data Transfer to SAP S/4HANA in the Case of a New Implementation

Figure 4.5    Steps for the Data Transfer to SAP S/4HANA in the Case of a New Implementation

The result is a system that corresponds to the SAP Standard as much as possible and does not contain any obsolete data. Table 4.2 demonstrates how this procedure focuses on master data and only a small amount of transactional data is transferred.

The SAP S/4HANA migration cockpit replaces the Legacy System Migration Workbench (LSMW), which was used in SAP R/3 and SAP ERP systems. SAP S/4HANA no longer supports this tool. LSMW still exists but rarely makes sense to use it and should be used at your own risk.

For the planned new implementation project, which data you want to transfer is decisive: If data objects have requirements that are not part of the content provided, you cannot transfer them with the SAP S/4HANA migration cockpit.

For more specific data transfers, you should use SAP Data Services, a tool for extracting and loading data. SAP Data Services is included for all SAP HANA users who have an SAP HANA license. Optionally, SAP offers a license extension for SAP Data Services, which supports modifying and improving data quality and data cleansing. Consisting of a central Data Services server and a local frontend for modeling, SAP Data Services also provides migration content that is more comprehensive than in the SAP S/4HANA migration cockpit (see Table 4.2). However, using SAP Data Services requires more technical effort and key-user know-how than using the SAP S/4HANA migration cockpit.

Migration Objects When Using SAP Data Services
Activity Prices Fixed Assets Profit Centers
Activity Type Groups Functional Location Purchase Orders*
Activity Types GL Balances* Purchasing Info Records
Bank Master GL Open Items* Purchasing Requisitions*
Batch Inspection Methods Reference Operation Set
Bill of Materials (BOM) Inspection Plans Routings
Business Partner Internal Order* Sales Orders*
Characteristic Master Inventory Balance* Scheduling Agreements*
Class Master Master Inspection Characteristics SD Pricing
Configuration Profiles for Material Material External Customer Replenishment Secondary Cost Elements
Contracts* Material Master Service Master
Cost Center Group Material Master Classification Source List
Cost Centers Material QM Inspection Type Statistical Key Figures
Credit Memo* Object Dependency Supplier Invoice*
Customer Invoice Billing* Open Deliveries* Vendor Open Items (AP)*
Customer Open Items (AR)* Order Reservation* Work Breakdown Structure
Equipment Planned Independents Requirements* Work Centers
Exchange Rates Profit Center Groups
The objects marked with * are transactional data; the other objects are master data.

Table 4.2    Supported Migration Objects When Using SAP Data Services

Recall that the migration procedure we described creates a new system with a new SID that contains (selected) data from the source system. In most cases, this new system or the new multi-tier system landscape (involving development, test, and production systems) needs to be integrated into the overall landscape.

Chapter 8 and Chapter 13 provide further information on integration in SAP S/4HANA. Chapter 7 and Chapter 11 discuss the new implementation scenario and the relevant tools.

[+]  Checklist for New Implementation

Let’s summarize the individual steps for new implementations:

  1. Determining the target status: operating model and distribution of the instances. You can carry out new implementations for on-premise implementations, for SAP HANA Enterprise Cloud (SAP HEC), and in the public cloud.
  2. Identifying the desired new functions
  3. Verifying the functions currently used via the simplification list (http://help.sap.com/s4hana_op_1610). Take into account the number of users for each function.
  4. For existing SAP ERP systems: Precheck in simulation mode (see SAP Note 2182725)
  5. Analyzing custom enhancements using the custom code migration worklist (http://bit.ly/v1448043). You usually have to newly implement existing custom programs in SAP S/4HANA Cloud. For more information on new enhancements for SAP S/4HANA Cloud, see Chapter 3, Section 3.4.
  6. For on-premise editions only: Sizing (https://service.sap.com/sizing)
  7. Adjusting input planning, verifying the migration scenario
  8. If possible, data cleansing and archiving in the source system
  9. Setting up the target system
  10. Starting the SAP S/4HANA migration cockpit and transferring data
  11. Checking the result
  12. For on-premise editions only: Setting up the frontend servers for SAP Fiori
  13. Delta configuration
  14. Final tests
  15. Roll-out of new processes for users

4.2.2    System Conversion to SAP S/4HANA

In this scenario, we’ll take an existing SAP ERP system and convert this system into an SAP S/4HANA system in several steps (see Figure 4.6). The SID, the customization, and the existing data of the source system are kept in this procedure. When selecting this scenario, you should cleanse your data before you convert the system. Note that this scenario is not an upgrade because the existing system belongs to a different product family.

System Conversion to SAP S/4HANA

Figure 4.6    System Conversion to SAP S/4HANA

[»]  Data Footprint and Archiving

SAP S/4HANA features a considerably reduced data footprint, meaning that the data in the SAP HANA database occupies less storage space than in common SAP ERP systems on traditional databases. SAP HANA’s improved compression algorithms are already considered in SAP’s official sizing recommendations.

However, in the case of system conversions, these sizing rules usually do not apply to the target system because the storage requirements are temporarily higher than in newly implemented systems. More memory is needed because SAP keeps your data to avoid data loss. Consequently, data is temporarily kept redundantly in the target system: in both the new data models of SAP S/4HANA and in the obsolete tables of the SAP ERP system.

Therefore, the target system needs to be sufficiently sized initially. After the conversion, you can delete redundant data manually. First, however, you should check whether the data has been successfully converted.

To effectively size the target system (providing sufficient but not too much memory), you should analyze what data in the source system can be archived. You’ll be able to access these archives from SAP S/4HANA. Another benefit is that the runtime of actual conversion will also be reduced. However, you should not archive active data. Your planning should additionally consider that the archiving routines in the SAP S/4HANA target system still have to be adjusted to the new data models so that the target system can also archive future data.

In addition, you can use the data aging option, which is integrated into SAP HANA. This method moves data that is not actively used from the SAP HANA memory and could be considered a kind of preparatory step for archiving: Hot data is stored in the SAP HANA memory; cold and historical data is stored in the archive.

Before you convert your system, you must analyze the source system in detail. The simplification list provided by SAP contains all relevant changes that affect available SAP ERP functions: omitted functions, significantly modified applications (or application architectures), and nonstrategic functions (see Figure 4.7). The latter refers to functions that are available in SAP S/4HANA but that SAP no longer recommends. Because SAP doesn’t plan to enhance or maintain these functions in the future, you should only use these functions during the transition phase.

For simplification reasons, SAP provides numerous automatic prechecks. These prechecks answer the following questions about your system:

Functions from SAP ERP Expected Change or Depreciated

Figure 4.7    Functions from SAP ERP Expected Change or Depreciated

The results of these checks can considerably impact project scoping. We therefore recommend running these checks at the beginning of the conversion project so you can accurately estimate the overall project scope. To run a simulation, you can select the Simulation Mode in the prechecks (see Figure 4.8).

The results of the checks are categorized as follows:

Initial Screen of the Prechecks for Preparing the SAP S/4HANA Conversion

Figure 4.8    Initial Screen of the Prechecks for Preparing the SAP S/4HANA Conversion

Warnings do not prevent the technical implementation of the conversion from continuing. However, because these warnings might lead to data loss under certain conditions, you should also analyze warnings in detail. An example of the results of these prechecks is shown in Figure 4.9.

Example Results from Prechecks

Figure 4.9    Example Results from Prechecks

SAP has made these prechecks available via SAP Notes (see SAP Note 2182725). Prechecks are imported into the source system, where you’ll run the check, meaning you can carry out prechecks independently of the technical conversion project. To be safe, the conversion routine additionally requests that you run the prechecks to avoid converting systems that have not been checked.

Custom code checks deviate from the procedure described above. To check custom code, an SAP NetWeaver system is connected to the source system, and the custom code is then analyzed in this SAP NetWeaver system. In this way, unnecessary workload is diverted away from the source system. The result of these checks is a custom code migration worklist, which lists adaptations to your custom code recommended by SAP.

After the checks have been carried out, you should eliminate the abnormalities found in your source system. Otherwise, the conversion might not run smoothly. After implementing all corrections, you can verify the system readiness by checking the system again.

If the prechecks do not indicate any abnormalities, you can initiate the next conversion phase. Call the Maintenance Planner via the SAP Support Portal (https://apps.support.sap.com/sap/support/mp). Then, enter the desired target status—the selected version of SAP S/4HANA in our case—in the Maintenance Planner. You then carry out the actual technical system conversion using a version of the Software Update Manager (SUM) that has been optimized for SAP S/4HANA.

You can choose how the technical conversion should be carried out. SAP provides two procedures for this:

At present, the conversion with optimized downtime option is only available for source systems that do not run on SAP HANA. You can optimize additional requirements in individual projects. If you strive for a near-zero downtime, SAP recommends involving SAP consultants in the conversion project.

The technical conversion usually involves the following three steps:

  1. Migrating the database to SAP HANA
    Your source system database does not have to be SAP HANA. In this case, the SUM enables you to also convert the database to SAP HANA, which is referred to as the Database Migration Option     (DMO).
  2. Implementing new repository objects
    The software is updated to the new SAP S/4HANA versions.
  3. Converting the data
    The data of the source system is transferred to the target system using its new storage options.

After you have successfully implemented the technical conversion, you might have to perform some application-specific tasks.

The system is ready for use again—but only with the functional scope of the legacy system. The new SAP S/4HANA functions are available in the system but usually still have to be configured. To simplify this configuration, SAP provides predefined content in SAP Best Practices.

[»]  From a Single System to a Landscape

The conversion steps we described must be performed in all systems of the landscape, i.e., at least in the development, test, and production systems. To overcome the resulting downtime, you can generate a temporary copy of the landscape. Please note that, in this case, you probably won’t be able to transport code or configuration changes between systems on the source product version and the new SAP S/4HANA systems. This limitation also applies to SAP corrections. These limitations arise because the code (custom code and SAP code) and configuration tables differ. We recommend adjusting the landscapes manually.

Thus, you should also divide the project into two phases and focus on the technical conversion of the system first. You can then introduce new or changed processes on the converted system in a second step.

The possible target SAP S/4HANA versions depends on the source product version. Usually, you can select between multiple target releases. When begin a conversion, SAP HANA doesn't have to be already implemented in your source system. You also do not need to implement the versions of SAP S/4HANA sequentially when transitioning to a higher version. In general, a source system running on SAP ERP 6.0 or higher is sufficient, as shown in Figure 4.10. Chapter 10 provides more details on conversion paths.

Different Paths to SAP S/4HANA

Figure 4.10    Different Paths to SAP S/4HANA

[+]  Conversion Checklist

The following list summarizes the individual steps for a system conversion:

  1. Determining the target status: operating model and distribution of the instances. The system conversion can only be carried out for on-premise implementations or for SAP HANA Enterprise Cloud (SAP HEC).
  2. Identifying the desired new functions
  3. Verifying the functions currently used via the simplification list. Take into account the number of users for each function.
  4. Running prechecks in simulation mode and custom code checks (http://bit.ly/v1448041)
  5. Sizing
  6. Adjusting capacity planning for the project and confirmation of the migration scenario
  7. If possible, data cleansing and archiving in the source system
  8. Planning your system conversion in the Maintenance Planner (http://bit.ly/v1448042)
  9. Selecting the standard conversion or the conversion with optimized downtime in the SUM, adjusting sizing if required
  10. Executing the maintenance transaction
  11. Checking the result
  12. Setting up the frontend servers for SAP Fiori
  13. Delta configuration
  14. Roll-out of the new processes for the users

4.2.3    Landscape Transformation with SAP S/4HANA

Landscape transformation refers to a migration scenario in which various SAP ERP systems are integrated into a shared SAP S/4HANA system (see Figure 4.11). You might choose a landscape transformation to benefit the most from SAP S/4HANA’s real-time data processing: Only if all data is kept in one database can the system use this data with highest efficiency. Another benefit is that data no longer needs to be replicated. SAP S/4HANA’s efficient compression algorithms and its high speed can handle the volume of data that previously would have been spread out to multiple traditional systems.

Landscape Transformation

Figure 4.11    Landscape Transformation

The landscape transformation process consists of two subprojects. In the first part, the master system is prepared. As described in the previous two sections, the master system is either a new implementation of an SAP S/4HANA system or a system conversion. The latter scenario is implemented if the landscape contains an SAP ERP system that can be used as the basis for the other systems. The configuration and process specifications should be optimized and up-to-date in this system. When planning this first step, take into account the guidance for new implementations and system conversions described in the previous two sections.

After you’ve implemented an SAP S/4HANA master system, you still need to transfer the data from your other systems in the landscape to this system. First, determine the required data extraction method. Figure 4.12 illustrates common methods:

Regardless of data extraction method, the data from (several) SAP ERP versions is read and written to the SAP S/4HANA system. In this process, this data will need to be translated into the new SAP S/4HANA data model using SAP Landscape Transformation (SLT). However, you cannot use SLT for continuous data replication, just for one-time data transfers only, as in this scenario. SAP has equipped SLT with the right conversion logic for the new SAP S/4HANA data model.

Landscape transformations are also possible for non-SAP systems if you are willing to accept some constraints. In this case, however, you should consider using SAP Data Services as described in the new implementation scenario. The specific tool you use depends on your individual situation.

The individual realizations in a landscape transformation are highly specialized projects. In addition to the technical support, SAP and other service providers can offer specialized consulting and implementation services for these scenarios. Chapter 12 further describes landscape transformations in detail.