Skip to Content

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.

  1. 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?
  2. The 3 SAP S/4HANA transition options at a glance.
    1. System Conversion
    2. New Implementation
    3. Landscape Transformation
  3. Comparing the Paths to SAP S/4HANA
    1. Aspects/questions influencing the choice of the deployment options
    2. Actual findings from customer projects
  4. 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.

Technical view:

What How
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

 

Technical view:

Steps How
Install SAP S/4HANA (Cloud or on premise) Software Provisioning Manager
Initial data load from source system
  • SAP S/4HANA Migration Cockpit
  • SAP Data Services (SAP DS)

both with Best Practice Migration content

 Retire old landscape

 

 

 

2.3 Landscape Transformation

Scenario description:

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.

Benefits

  • 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

 

Technical view:

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

SCN BLOG: Start SAP S/4HANA Planning with Readiness Check

SAP Note 2290622 – SAP Readiness Check for SAP S/4HANA

Help Portal incl. User Guide

 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…)

 

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Smriti Gupta

    Hello Roland,

     

    Thanks for such a well documented blog and the weblinks. Do you have an idea if there is any upcoming webinar on this topic.

    Looking forward to the series

    Thanks

    Smriti

    (0) 
  2. Roland Hamm Post author

    Hello Smriti,

    Thanks a lot for your positive feedback!

    At the moment I do not know of any concrete webinar session, but I will check…..have you already checked for interesting sessions on the SAP S/4HANA Hub?

    best regards,
    Roland

     

    (0) 
  3. KENJI MAKITA

    Hi Roland,

    Thank you, It is a good blog to understand the S/4HANA conversion from ECC system, and have already shared it with my team.

    I am wondering if Customer uses ECC6.0 and APO and considering the covert to S/4HANA, how can we convert APO objects?

    Is it available to apply the conversion tools for APO.

    Not found the regarding issue.

    Best,

    Ken

     

     

     

     

    (0) 
  4. Rilo Naumann

    Hi,

    where can i find Information of S/4Hana 1709 on Premise?

    Are there any new Tools or Information on System conversion to 1709?

    When will 1709 be available?

     

    Thanks!

     

    (0) 
  5. Robert Nagy

    Dear Roland,

     

    Our company evaluates the possibility of merging two Business Suit landscape into one S/4HANA. I saw the “build-up multiple client system” approach. What technically this would mean? With the “old fashion” way I cannot imagine this approach. What happens with the client independent objects?  The two source systems are ECC landscapes with different switched on functionalities. Can this “merge” step conserve the different program and repository environment or this “merge” approach would also involve a BPR and repository harmonization to let the two client work properly?

    Thanks!

    (0) 

Leave a Reply