SAP S/4HANA Migration Approaches and Transitions
By 2025 (or 2027 for specific cases), SAP will no longer support its existing ERP business suite, requiring users to move to the HANA in-memory platform. While every SAP customer knows that migrating to SAP S/4HANA is inevitable, many are concerned by the cost, complexity and duration of the migration project. SAP S/4HANA can be deployed on two delivery platforms: on-premise for maximum control, and in the cloud for fast time-to-value.
SAP S/4HANA on-premise edition is an internal platform, located on your servers, maintained by your company. SAP upgrades are released annually but must be implemented and tested by your team. SAP S/4HANA Cloud edition is Software as a Service (SaaS) hosted on SAP's servers and is maintained by SAP. Software upgrades happen quarterly. The cloud version is available to enterprises in both private and public editions.
When it comes to SAP S/4 HANA conversion, there is no single answer, and each business is at a different state of SAP S/4 HANA preparation. Some may opt for a new beginning by introducing new ideas, often known as a Greenfield Strategy. On the other hand, some prefer a complete system transition, often known as a Brownfield Strategy, which avoids disrupting their current business processes. Landscape Conversion is an option for individuals who would like to integrate their present system environment into SAP S/4 HANA.
They all fall broadly into the following options:
Transition Paths and Deployments
S/4HANA offers a complete choice of deployment: on-premise, in the cloud, or hybrid. There are some extremely specific similarities and differences to consider when . Usually, the decision will be based on your configuration requirements and functionality. SAP S/4HANA . Usually, the decision will be based on your configuration requirements and functionality.
Regardless of what deployment option you choose, you get the same simplified data model and improved user experience for consistency at every level of your organization. SAP Activate is a four-to-six-step technique designed to help organizations transition to S/4HANA and direct them from preparing to going live. Trigger focuses at its core on three main pillars: Guided configuration, best practices, and methodology.
SAP Activate implementation methodology consists of the following six phases and eleven workstreams.
Phases: Discover, Prepare, Explore Realize, Deploy and Run.
The SAP Activate workstreams are designed to focus the project team on specific work areas of the implementation, to help the project strategically use the various skills and expertise from the project team to meet project deadlines.
Workstreams: Project Management, Customer Team Enablement, Solution Adoption, Technical Architecture and Infrastructure, Design and Configuration, Data Management, Integration, Extensibility, Analytics, Testing, Operations and Support.
The figure below depicts the high-level activities spanned across the phases.
The goal of the Application Design and Configuration workstream is to help the customer plan, prepare, and realize the planned value-add of the solution for their business needs. The purpose of the fit-to-standard workshops is to enable a solution that is as close as possible to SAP standard pre-delivered processes that will allow the customer to adopt new innovations and best practices. This leads to faster realization of business benefits and a lower total cost of ownership while keeping the solution current.
The Fit-to-Standard analysis is conducted in a series of workshops and allows for validation of predefined scenarios agreed upon and to make room for enhancements or additional configuration required (i.e., self-service configuration, expert configuration, forms, reports, business roles and other solution extensions). To prepare for this workshop, it is recommended that teams get familiar with the SAP Best Practices content, including the process flows, test scripts with sample data, and other documentation available in SAP Best Practices Explorer. Consultants should also evaluate the necessary adjustments to the sample data provided in the customer Starter System prior to running the workshops – for example, adjusting the organization names and master data to make the data applicable to the organization and users that will attend the fit-to-standard workshops.
Difference between the Fit-to-Standard and Solution Validation and Delta Design?
This is used in cloud implementations where the product has defined boundaries, for example, SAP S/4HANA Cloud and SAP SuccessFactors.
The approach emphasizes the use of standard functionality over other options, but it still allows extensibility (in-app or side-by-side) where needed to address critical business (delta) requirements that the solution needs to provide.
Solution Validation and Delta Design
This is used in New Implementation and System Conversion On-Premise approaches where the team has wider ability to extend the solution with custom code or via the extensibility framework. The focus on this approach is again on the adoption of standard functionality first, but the product allows project teams to use broader options for extending the functionality, including custom code in the application itself. For example, in SAP S/4HANA, the project team has access to a full development environment inside the application.
Note: In both approaches, the project team must strive to avoid modifications of SAP-delivered code; when this is unavoidable, the team must ensure that the changes are properly documented. A gap is a business requirement that cannot be fulfilled with the system. A delta is the approach to close the gap. It might be closed by a process outside of the system.