Migration Options for Moving to SAP S/4HANA

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 shouldn’t plan to migrate to SAP S/4HANA 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, which means adapting both the technical aspects and content-wise design of the business processes.

What Should You Consider Prior to Selecting SAP S/4HANA?

You should (at least) answer the following questions, which will be discussed in more detail later.

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?

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 Exist Already?

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 will 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 should be purchased, and which can be performed in-house?

Preparing for Coming Decades

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.

Technical and Process-Oriented Implementation Parts

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 below).

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 don’t depend on how the system will ultimately be used in production, so they can be technically controlled and supported with standard tools. 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 changed business process, configuring necessary measures, training users, assigning roles and authorizations, running pilot operations, and converting the production (PRD) system.

Tasks in the Individual Phases

The following tasks can be assigned to these outlined phases.

• Preparation (preparatory steps in the source system)
  • Analyzing the existing business process implementation
  • Comparing it with the SAP S/4HANA innovations
  • Identifying the necessary integration scenarios
  • Running prechecks in the source system, for example, on functions used, industry-specific enhancements, custom codes, and third-party enhancements
  • Implementing necessary preparatory conversions in the source system
• Technical implementation
  • Installing SAP S/4HANA, the SAP HANA database, and SAP S/4HANA applications
  • Adapting the technical infrastructure
  • Configuring customizing settings
• Process adaptation
  • Adapting custom programs in SAP S/4HANA
  • Developing new or enhanced business processes to leverage the innovations in SAP S/4HANA
  • Adapting integration scenarios
  • Customizing 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, doesn’t 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 trivial at first, SAP S/4HANA migration projects often fail to describe the goal of the migration in detail and rely on vague statements such as “implementation of SAP S/4HANA.”

Analyzing the Trade-Off at an Early Stage

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 user interfaces (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 PoC first? In the latter case, you should carry out a greenfield implementation with selective data transfers.

Total Cost of Ownership (TCO)

SAP S/4HANA enables you to reduce the TCO. Examples include a reduced data footprint—that is, the storage space for application data in the database is reduced. Another dimension is 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.

SAP Implementation Methodology

SAP recommends a methodology with six phases for project planning and implementation: discover, prepare, explore, realize, deploy, and run. The methodology is called SAP Activate.

We assume that you’ve already opted for SAP S/4HANA. We’ll assume the discover phase has already been successfully completed as well—during which enterprise priorities are identified, the target architecture is defined, the business case is optimized, and a readiness check is carried out. Our focus is on the technical implementation of the migration and less on process-oriented implementation. We assume that you’ve selected and defined the characteristics of the business process scope in a separate business implementation project.

Preparation with Trial Access

If you haven’t 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’s only valid for a limited time. For more information on these trial systems, see this post.

Conclusion

Migrating to SAP S/4HANA is far more than a technical upgrade. It's a strategic decision that touches every layer of your organization, from database infrastructure to user experience to long-term process design. Success depends on honest answers to the foundational questions before a single line of code changes: What is your target state? What operating model fits your needs? How much of your existing landscape should carry forward? By separating the technical migration from the process-oriented implementation, planning in parallel workstreams, and keeping the trade-off between simplicity and innovation in clear view, your organization can approach SAP S/4HANA not as a forced system change, but as a genuine opportunity to build a more capable, competitive, and future-ready digital core.

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, Martina Höft, Petra Klöß, Kim Mathäß, and Boris Rubarth. Frank Densborn has been an expert in data migration at SAP since 2004 and is the author of numerous SAP PRESS titles in German and English. Frank Finkbohner worked for SAP since 1999, including 13 years in SAP consulting, where he supported customers in numerous projects, including data migration and the development and extension of ABAP applications. Martina works in product management for SAP S/4HANA in the area of data migration and data transformation with a focus on the SAP S/4HANA migration cockpit. Dr. Klöß is a senior director in SAP Central Business Configuration, managing customer success for SAP Central Business Configuration for the Americas and greater China. Kim has worked at SAP since 2006 and is currently senior development manager in SAP S/4HANA Globalization. Dr. Rubarth worked at SAP from 1999 until the end of 2024, most recently as product manager in the Software Logistics division.