7 Things to Consider Before an SAP S/4HANA Migration

An SAP S/4HANA migration offers many benefits, but to ensure a smooth migration, you must be aware of your specific reasons for migrating.

Consequently, you should not plan an SAP S/4HANA migration as an update or upgrade of an already implemented solution. With SAP S/4HANA, you want to introduce a new digital core to your enterprise that ensures future competitiveness. This will succeed optimally if you adapt both the technical aspects and content-wise design of business processes.

Questions to Answer

You should (at least) answer the following questions:

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 (PoC), 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 (SaaS) model? Learn more about the different versions of SAP S/4HANA here.

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?

How Many Users Will Be Involved?

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?

Implementing SAP S/4HANA

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 performing an SAP S/4HANA migration, you’ll have to consider at least two parts of the implementation: the purely technical part and the process-oriented part.

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.

Phase Tasks

The following tasks can be assigned to these outlined phases:

1 Preparation (preparatory steps in the source system):

Analysis of existing business process implementation
Comparison with the SAP S/4HANA innovations
Identification of the necessary integration scenarios
Pre-checks in the source system, for example, functions used, industry-specific enhancements, custom codes, third-party enhancements
Implementation of necessary preparatory conversions in the source system

2 Technical Implementation:

Installation of SAP S/4HANA, SAP HANA database, and SAP S/4HANA applications
Adaptation of the technical infrastructure
Customizing

3 Process Adaptation:

Adaptation of custom programs in SAP S/4HANA
Development of new or enhanced business processes to leverage the innovations in SAP S/4HANA
Adaptation of integration scenarios
Customization of SAP Fiori interfaces

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. In general, you can plan the introduction or migration of your business processes independently from the technical migration.

Parallel Project Phases

The figure below 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.

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.”

Trade Offs 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 you can derive from SAP S/4HANA in this case might also be reduced because the major benefits from SAP S/4HANA are optimized business processes, simplified UIs, 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. 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? Which data must be transferred from the legacy system, and which data can be left behind?

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.

Conclusion

When it comes to an SAP S/4HANA migration, 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.

The content of this blog post covered the first phase, the discovery phase. In this timeframe, enterprise priorities are identified, the target architecture is defined, the business case is optimized, and a readiness check is carried out. It is perhaps the most important phase to complete as it sets the tone for the entire SAP S/4HANA migration.

If you’re still on the fence about whether SAP S/4HANA and its various lines of business such as finance and logistics can meet your needs, or 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 SAP S/4HANA Cloud that is only valid for a limited time.

Learn more about agile project delivery for SAP in this free chapter excerpt.

Explore more SAP S/4HANA migration options and considerations in this post.

Also explore five golden rules for implementing SAP S/4HANA with SAP Activate here.

Editor’s note: This post has been adapted from a section of the book Migrating to SAP S/4HANA: Operating Models, Migration Scenarios, Tools, and Implementation by Frank Densborn, Frank Finkbohner, Jochen Freudenberg, Martina Höft, Kim Mathäß, and Boris Rubarth.