4 Preparing the Migration to SAP S/4HANA
This chapter introduces the three migration scenarios covered in this book.
Which steps should you consider when planning your migration project to SAP S/4HANA? How does SAP support you? Can the migration be compared to an upgrade within the SAP ERP product family? This chapter answers these questions. Furthermore, we’ll introduce three possible migration scenarios: a new implementation, a system conversion, and a landscape transformation. The last chapter of the book, Chapter 14, then looks back at these scenarios and summarizes their advantages and disadvantages under different conditions.
4.1 Basic Considerations
Migrating to SAP S/4HANA offers many benefits, but to ensure a smooth migration, you must be aware of your specific reasons for migrating. Consequently, you should not plan to migrate to SAP S/4HANA as an update or upgrade of an already implemented solution. The functional and business scope of SAP ERP and SAP S/4HANA are similar, but this migration will introduce a new digital core to your enterprise that ensures future competitiveness.
You should (at least) answer the following questions, which will be discussed in more detail later on in this section:
-
Which target status do you want to achieve?
What position is SAP S/4HANA supposed to take in your system landscape? Do you want to execute a proof of concept, or do you want to use SAP S/4HANA immediately in production? Can you use the migration as an opportunity to optimize how your processes are mapped in the enterprise software? -
Which operating model suits you?
Do you want to run SAP S/4HANA at your own data center or through a hosting service? Or, do you want to use SAP S/4HANA as a software-as-a-service model? -
What is the initial situation?
What is the current product version of your source system? What is the quality of the data in your source system? How strictly do you leverage the SAP Standard, and how many custom enhancements exist? Do you want to use a system as a template? -
Which users do exist?
How many users exist, and how are they distributed? Which user groups are expected to benefit from the implementation of SAP S/4HANA? -
How is the solution to be used?
Which business scenarios and transactions are to be used? How are these requirements distributed across your users? -
What is your defined time frame?
Within what period of time is the project supposed to be completed? Which milestones need to be reached and when? -
Do you need support?
What kind of support do you need? What is your budget? Which services do you expect to purchase and which services can be provided in-house?
The more aware you are of the significance of SAP’s digital core, the more added value SAP S/4HANA can usually generate: The basic concept of SAP S/4HANA is its pledge to prepare enterprises for the challenges of the coming decades. Restricting yourself to a purely technical update of existing systems and landscapes would be an inadequate simplification. You should analyze whether your processes have grown as well as whether your system landscape will be sustainable in the future or whether its structure is obsolete and should thus be adjusted.
Thus, when migrating to SAP S/4HANA, you’ll have to consider at least two parts of the implementation: the purely technical part and the process-oriented part (see Figure 4.1).
Figure 4.1 The Main Parts Migrating to SAP S/4HANA
-
Technical implementation
The technical implementation of a migration mainly includes migrating the database to SAP HANA, replacing the program code, adapting data models to the SAP S/4HANA data model, and implementing the frontend server for SAP Fiori interfaces. Your existing custom code might also have to be technically adapted.
These activities generally do not depend on the scope of subsequent use in production and can easily be implemented using the relevant tools and can therefore be technically controlled and supported. Thus, SAP provides a comprehensive portfolio of tools for planning and carrying out this technical implementation. -
Process-oriented implementation
The process-oriented implementation of a migration refers to adapting how existing business processes are mapped in the system and to introducing new applications. These modifications to business processes are only partially carried out in the system itself. In most cases, you can only enter indicators, such as changed configuration information. Regarding planning, however, you’ll have to perform far more comprehensive change management steps. These steps include, for example, designing your new changed business process, configuring necessary measures, training users, assigning roles and authorizations, pilot operation, and converting the production system.
The following tasks can be assigned to these outlined phases:
| 1 |
Preparation (preparatory steps in the source system):
|
| 2 |
Technical implementation:
|
| 3 |
Process adaptation:
|
The time and effort required for the process-oriented implementation—depending on the initial situation and target status—can account for either a small or a large part of the overall process. Thus, we recommend dividing the migration project into the three phases we just described because the process-oriented implementation, in particular the implementation of new business processes, does not have to be carried out in parallel to the technical migration.
[+] Process Migration and Technical Migration as Separate Steps
In general, you can plan the introduction or migration of your business processes independently from the technical migration.
Figure 4.2 shows one possible approach for introducing SAP S/4HANA to your enterprise: In the project, you prepare and implement new functions in batches, while the users continue to use the existing functions.
Figure 4.2 Parallel Preparation and Implementation of New Functions
A prerequisite for optimal project planning is knowing the desired target state. While this prerequisite might sound rather trivial at first, SAP S/4HANA migration projects often fail to describe the goal of the migration in detail and rely on vague statements like “implementation of SAP S/4HANA.”
Migrating to SAP S/4HANA has a general trade-off that you should be aware of, in particular if your initial state includes an SAP ERP system or SAP landscape: The more properties of the source system you decide to keep unchanged (e.g., configuration, custom code, or applications), the simpler the (technical part) of the migration project. However, the benefit that can be derived from SAP S/4HANA in this case might also be reduced because the major benefits from SAP S/4HANA are optimized business processes, simplified user interfaces, and greater flexibility for future requirements.
Therefore, you should always analyze this trade-off. Possible analysis criteria include the following:
-
Type of usage
Is the target system used for production, or do you want to execute a proof of concept first? In the latter case, you should carry out a greenfield implementation with selective data transfers. -
Total cost of ownership
SAP S/4HANA enables you to reduce the total cost of ownership (TCO). Examples include a reduced data footprint, that is, the storage space for application data in the database is reduced (see Section 4.2.2). Another dimension are reduced requirements for your internal IT department because local SAP GUI installations at employee workstations can be avoided. If your explicit goal for the migration is to lower the TCO, you should also analyze where custom enhancements can be omitted or replaced by SAP S/4HANA applications. Furthermore, you should examine the extent to which multiple existing ERP systems can be merged into one SAP S/4HANA system. In addition to the reduced TCO, users benefit from access to real-time data from the systems that were previously separated. -
Operating model
Is SAP S/4HANA to be operated in the cloud or on-premise? The two operating models have different characteristics that need to be analyzed. In simple terms, outsourcing the system administration to the cloud is attractive, especially for standard business processes. -
Target landscape
How is the entire landscape supposed to change? Are systems to be consolidated? Are systems to be separated (e.g., financial accounting and material requirements planning)? How is the existing architecture to be adjusted?
Remember that you usually also have to set up and configure the frontend servers for SAP Fiori, which are required for the new SAP S/4HANA functions.
SAP recommends a methodology with six phases for project planning and implementation: discover, prepare, explore, realize, deploy, and run. This methodology is called SAP Activate, which we’ll describe in detail in Chapter 5.
When referring to migration activities in this book, we assume that you have already opted for SAP S/4HANA. We’ll assume the discovery phase—during which enterprise priorities are identified, the target architecture is defined, the business case is optimized, and a readiness check is carried out—has already been successfully completed. Our focus is on the technical implementation of the migration and less on process-oriented implementation. We assume that you have selected and defined the characteristics of the business process scope in a separate business implementation project.
[»] Preparation with Trial Access
If you have not completed the discovery phase yet, you should test an SAP S/4HANA system. For this purpose, SAP provides trial access to a cloud instance of SAP S/4HANA that is only valid for a limited time. For more information on these trial systems, see Chapter 6.