The intention of this blog is to explain the available SAP S/4HANA Transition options including their technical tooling, so that customers planning to migrate to SAP S/4HANA can make the best individually suited decision for their system landscape.
The Blog will be extended by more aspects during the next weeks. So if you like this blog stay tuned…
I have structured this blog as follows.
- What is different between SAP S/4HANA and SAP ERP 6.0 EHP xyz? And how does this impact my decision for the most suitable transition option?
- The 3 SAP S/4HANA transition options at a glance.
- System Conversion
- New Implementation
- Landscape Transformation
- Comparing the Paths to SAP S/4HANA
- Aspects/questions influencing the choice of the deployment options
- Actual findings from customer projects
- Recommended links to further information. in this section I will include links to other SCN blogs I recommend to read which describe aspects of the discussed transition options in more detail
At first I want to set expectations, that I want to focus here on those cases and resulting choices, where there is already an existing SAP ERP System which shall be replaced by an S/4HANA System.
As replacing any non-SAP / 3rd-party System with SAP S/4HANA means always a new implementation, we can leave this out of this discussion. In that case the only choice to make is about the deployment option, whether it shall be on premise or cloud (public or private option is possible).
1.Things are different in SAP S/4HANA !
S/4HANA it is not a successor release of the SAP Business Suite ERP system, SAP S/4HANA is a new product line. (The classical SAP Business Suite & SAP ERP is a separate product line and will still be available.)
The point is, that there are some incompatible changes between an SAP Business Suite ERP System and a SAP S/4HANA system:
A SAP S/4HANA System is
- based exclusively on SAP’s Innovative in-memory database SAP HANA
- It has a new application Architecture and a new, simplified application data model
- Besides application functionality, which is contained in the so called compatibility packs, many S/4HANA applications have been re-designed
- You can now use a new UI technology, SAP Fiori.
- You can choose between two deployment models: on-premise and cloud (both private and public cloud versions are available)
Therefore if you intend to replace your existing SAP Business Suite system / system landscape by SAP S/4HANA, you have to be aware that this is not just a release update.
However this is not necessarily a disadvantage, but a chance to consider to which extend you want to innovate and to which extend you want to keep business processes and applications which are still good enough.
2. SAP S/4HANA transition options
So, what are my options?
The picture below summarizes the three main transition scenarios, which SAP offers:
We will now have a deeper look on each of the transition scenario option:
2.1 System Conversion
Why would you choose this option?
You would choose this option if your main goal is to bring your current business processes to the new platform, and/or you want to keep your investment in custom code.
A third reason for this option could be, that you want to mitigate the risk and investment of a big bang conversion project by reducing the scope of the transition project to a pure (as much as possible) technical conversion project, and plan to adopt new innovations at your speed at a later point of time and in a phased approach.
|In-place technical conversion||
tool-based technical conversion process of a SAP Business Suite ERP system to SAP S/4 HANA using SUM;
Downtime minimizing options available
Technically seen system conversion is a complete technical in-place conversion of an existing SAP Business Suite ERP system to SAP S/4HANA, that means, that this process changes an existing system into an S/4HANA system.
- It facilitates a database migration from a classical AnyDB to SAP HANA database, in case your SAP ERP system was running on a classical AnyDB.
- It migrates the ERP data model into the S/4HANA data model with all the invented data model simplifications and data volume reductions
- It replaces the old SAP ERP application Code with SAP S/4HANA Application Code
- It does not force you to migrate your classical SAP GUI UIs to Fiori Apps! You can do this selectively in a later step.
The following picture illustrates the technical system conversion process from the planning over preparation, execution and post processing steps::
2.2 New Implementation
This scenario describes a fresh, new installation of a SAP S/4HANA system (either on-premise or cloud-based), also known as “greenfield” approach.
Why would you choose this option?
This option is perfect if reengineering and process simplification based on latest innovations are your primary focus.
This is especially a well suited approach for customers planning to migrate
- a non-SAP / 3rd-part legacy system,
- but also an good option for a SAP System, which may be
- of an older release and/or
- is highly customized/modified and/or
- does not meet the system requirements for a technical system conversion
Benefits for the customer are
- Reengineering and process simplification based on pre-configured business processes (best practise content available)
- Predefined migration objects & best practices available which does not require intensive migration logic programming
- Rapid adoption of new innovations in a standardized manner
The project duration depends on
- the number of required data migration objects (Material, Business Partner, etc.)
- the volume and complexity per data migration object
|Install SAP S/4HANA (Cloud or on premise)||Software Provisioning Manager|
|Initial data load from source system||
both with Best Practice Migration content
|Retire old landscape|
2.3 Landscape Transformation
This is a kind of value driven, selective data migration to the new S/4HANA platform. So the focus is not on migrating a whole system, but rather on pick & choose of entities which you want to carve out and move on to the SAP S/4HANA platform.
Therefore there are several sub-scenarios available:
- e.g. consolidation of a current SAP Business Suite landscape (multiple systems, or selectively clients of multiple systems) into one global SAP S/4HANA system, or
- selective data migration based on legal entities, such a clients or company codes
- Implementation of SAP Central Finance Scenario
Why would you choose this option?
Customers who want to consolidate their landscape or to selectively transform data into a SAP S/4HANA system.
- Value-based migration: selective data transformation allows a phased approach focusing the first SAP S/4HANA migration phase on parts of the business with highest ROI and lowest TCI
- Agility: stay on current business processes but move gradually to SAP S/4HANA innovations (Move to SAP S/4HANA at your own pace!)
- TCO reduction: system and landscape consolidation with harmonized/ simplified processes and unified master data lead to lower cost of operations
|SAP Landscape Transformation: Technical migration on table level using pre-configured transformation solutions|
|Consolidation||System Merge of multiple source systems into one new or existing SAP S/4HANA system (build-up multiple client system)|
|Selective Data Transformation||Migration of business units/single entities such as company code|
|Implementation of SAP Central Finance||Implementation of S/4HANA Central Finance including real-time reposting of financial transactions into Central Finance instance (synchronization of systems)|
In principle, Landscape Transformation is not really a either-or-option in comparison to the system conversion or new Implementation scenario.
As it is a data migration option it requires, that, as a pre-requisite, there is a target system available into which the data shall be migrated. This target system can be realized by a fresh system install like a greenfield approach (new implementation scenario with/without a initial data load), or, in case of a system consolidation effort, the target system can be created by executing a system conversion on a suitable SAP ERP system.
Having the target system in place, the Landscape Transformation option migrates (additional) data into that SAP S/4HANA systems independent from their origin or their purpose.
The various available Landscape transformation Scenarios
- can migrate data
- into newly implemented SAP S/4HANA target systems
- as well as into systems created via system conversion procedure,
- before or after they are handed over to operations,
- and independent if they are foreseen for productive use or not.
- can complement the other SAP S/4HANA transition options
Important to note: Other than the system conversion scenario and the new implementation scenario, the landscape transformation scenario requires currently a service or consulting engagement with SAP. There is not generally released toolset with documentation available which you can use to configure, test und execute your own, individual data migration to the SAP S/4HANA platform. The currently available tools and technology are only available via SAP Value Assurance Services or Consulting service Engagements, and only at a later time (currently planning is end of 2018), a data migration platform product will be released, which will cover selected data transformation scenarios to be executed by customers and partners without SAP Service engagement.
More information on what a landscape transformation scenario project can look like and how to engage with SAP in that context can be found on the SAP S/4HANA Value Assurance Services map as well as within the SAP Activate Transition Roadmap together with all relevant services/activities of the other transformation scenarios.
Here is the link to the: Transition to S/4HANA Roadmap Viewer
3.Comparing the Paths to SAP S/4HANA
After this scenario explanation you may still be curious about more influencing aspects, which may help you with your individual decision.
3.1. Aspects/questions influencing the choice of the deployment options
Cloud vs. on premise:
- You want to move fully to standardization with the SAP S/4HANA scope of business suite processes. You can do this by ideally choosing the new implementation approach. Hereby you can benefit from the available best practice content and guided configuration support. This is possible on both deployment models on premise and cloud.
However if the available functional scope of the public cloud product version is sufficient you can benefit
- from getting rid of system administration efforts,
- efforts for maintaining custom code and modifications during every maintenance event, and
- from faster delivery of new innovations (new release available very 3 months) without impact on your running processes.
Arguments for a New Implementation:
- System Requirements: Your Source system has restrictions that do not allow to move to SAP S/4HANA on-premise in a one-step procedure.
- Redesign: Your focus is on (fundamentally) redesign your business processes to enable the use of modern technology, such as predictive Analysis, business insight, machine learning, IoT, etc., as well as getting rid of outdated custom code, which makes every maintenace event more expensive and hinders the quick adoption of new functionality& technology.
Arguments for System Conversion:
- Enabling with investment protection: Most of your important business processes still fit to the current requirements, but you want to uplift them to the new S/4HANA platform in order to enable your system to add/change applications in smaller portions in a phased approach.
- Custom code relevancy: You have analyzed the current relevancy of your custom code, as well as the effort to migrate it and you see the feasibility and benefit in taking over existing custom code.
- Time to value: you can go live pretty fast while keeping most of your current business processes and can realize smaller innovations quick and independent from each other afterwards avoiding a longer running big bang project effort.
3.2. Actual findings from customer projects
- The average project duration summarized over all transition scenarios and over all SAP S/4HANA products & releases is around 8-11 months (statistics of all customer projects under SAP monitoring: both still running projects and projects already live), whereas the average for already finished projects is arround 8-9 months.
- The average project duration of all already finished projects for the transition to S/4HANA release 1610 are arround 7-8 months, system conversion projects are typically a little shorter than new implementation projects.–> System conversion is apparently often chosen for doing a kind of ‚technical uplift‘ to the S/4HANA platform, intensive adoption of new S/4 applications and Fiori UI Technology is therefore not necessarily in the conversion project focus and will be often addressed in follow-up projects (big bang projects are less often).
- While at the beginning of SAP S/4HANA shipment most customers chose a new implementation approach , this trend has changed meanwhile. Focussing on the first 2 Quarters 2017, system conversion is now the far most chosen scenario, with a rapidly increasing share.
- S/4 HANA Finance and S/4HANA projects have pretty much the same project duration, even if most conversion projects have a limited, initial application scope.Therefore a two step approach by moving to S/4HANA via S/4HANA Finance cannot be recommended in general (unless there are individual boundary conditions where it would make sense to focus on simplified financial in a first step).–> Apparently considering a two step approach by first adoption Simplified Finance and in a later step the whole Enterprise Management Scope does not seem to bring significant reduction in efforts for the first step, but requires a similar sized second step for transitioning all other application areas to SAP S/4HANA.
- Starting with a Central Finance Setup to start a step-by-step or process-by-process transition to S/4HANA for one or many SAP systems is not recommended.
- A central finance setup can accelerate the path towards a centralized financial reporting, taking data from various source systems into account. However, this is a scenario built for reporting on a subset of de-central financial data. A stepwise migration of de-central FI Applications into that same system is difficult and not supported by a suitable available tooling, and requires therefore a tight consulting/service engagement with SAP.
- Always consider the standard transition scenarios first if you want to transition to SAP S/4HANA and simplify the SAP landscape.
- Refer to tailored service items in the S/4HANA value assurance portfolio for details (Central finance overview, Central finance Evaluation)
- For SAP ERP on any DB customers a two step approach via SAP ERP on HANA has in general no significant benefits (individual exceptions may make sense in case of for non-Unicode systems & for SAP ERP Systems releases < SAP ERP 6.0)
- With 1709 FSP02 onward SAP plans to stop supporting System conversions from SAP ERP to S/4HANA release1511 for new projects.
–> System Conversions will always be possible to the latest two S/4HANA Releases (on so called ‚stable Stacks‘).
– more will come soon …. –
4. Recommended links to further information
I would like to recommend reading the document “Elements for Designing a Transition Roadmap to SAP S/4HANA” provided by our IT Planning Service colleagues. Here’s the SCN blog describing the purpose of the document. The document can be directly accessed based on the following link: https://dam.sap.com/mac/download/ad/OymUv.htm
More useful links in the context of the ‘transition to SAP S/4HANA’ topic are listed below:
|valid for SAP S/4HANA Release|
|web link||Transition to S/4HANA Roadmap Viewer||1511, 1610, 1709 (planned)|
|SCN Blog||SAP S/4HANA System Conversion – At a glance||1511, 1610, 1709 (planned)|
|SAP Readiness Check||1511, 1610, 1709|
|SCN Blog||Guidance for selected „Simplifications“||1511, 1610|
|Community||Join the SAP S/4HANA Community|
|web link||Discover SAP S/4HANA|
|web link||Detailed SAP S/4HANA Roadmaps||1511, 1610, 1709 (planned)|
(This section will be continuously extended…)