Skip to Content

Beginners Guide to Transitioning to S/4HANA 1511 On Premise edition for Existing SAP ERP 6.0x users

With S/4HANA being a new product from SAP it can be confusing for existing users/customers to understand how much of their existing solution can be converted into the new world of S/4HANA. As you will see the answer to that question is “quite a lot…if you want to”.

This blog focuses on moving from On Premise ERP to the S/4HANA On Premise Edition – my next blog will cover moving to the S/4HANA Cloud Edition (much is the same but their are some key differences).

To give us a framework to work from, I have broken the solution down into the following layers :-

  • User Interface
  • Business Logic (SAP Delivered and Customer Modifications/Extensions)
  • Database
  • Interfaces

Below is a graphic that I have created to try to show the conversion impacts (grey boxes = change), and I will discuss these below.


User Interface

The biggest difference that a user will perceive when using an S/4HANA system (or seeing a demo) is the new user interface. In line with the SAP Fiori guidelines and the New-Renew-Enable User Interface Strategy, S/4HANA is accessed using the Fiori LaunchPad and has Fiori Apps for accessing both classic and new features (many new features are only available via Fiori Apps). The access is based on the concept of Business Roles, with each role having a number of Fiori Apps associated to it. In addition to the Fiori Apps, some features of the solution are available via the SAP WebGUI transaction codes, but these are accessed via Fiori LaunchPad so users have one place to access everything.

Technically you can also access these transactions directly or via SAPGUI for Windows (which could help with your initial change management efforts). However some transactions have been superseded so you can’t assume everything will work. You can review the list of superseded transaction codes in the simplification list via this link. A good example of supersede transactions are the Credit Management transaction from SD which are now replaced with the newer Finance Credit Management solution.

Owen Recommends: Start using Fiori as soon as possible in your current landscape as it will reduce the learning curve when adopting S/4HANA – see what you can use now in the Fiori App Library.

Business Logic

As you can see from the diagram SAP is doing a lot at the business logic layer of the solution, adding new features, optimizing old ones and removing features that are duplicated or redundant. To understand the impact this will have on your installation or options that you will have as you implement, you once again have to refer to the Simplification List, this will show you where things have changed and recommend what you need to do to adapt your systems. For more details from a functional perspective read this blog by Xavier Herce.

For your Custom Code, you need to understand if it will run in the S/4HANA system. To assist in this SAP has provided a Custom Code Checker that uses the Simplification List and an extract of your custom code to highlight where changes may be required. This blog give details of how this works.

In addition to remediating your existing code SAP offer a number of alternative ways to “extend” your S/4HANA system – this blog gives a good overview. The first is a new User Interface extension tool that allows fields to be moved / hidden and for new fields / logic to be added to the system (all the way to table / interface level). More complex User Interface Extensions can be achieved using the SAP HANA Cloud Platform (HCP) to extend the solution using Web-IDE, public APIs and the Fiori App extension frameworks. The HCP platform also offers a wide range of other services that can be used to develop custom business logic / apps e.g IoT framework, HANA as a Database Service, Cloud Portal, Mobile Services etc etc. Find out more about the HANA Cloud Platform at HCP.SAP.COM.

Owen Recommends: Use the Simplification List to understand the changes and try to adopt as many as you can before the switch. Examples being New general Ledger, Material Ledger and Business Partner – which are all mandatory in S/4HANA but optional in Business Suite.

Owen Recommends: Stop worrying about your custom code and start looking into what you have and separate the wheat from the chaf. Much of your code will not be run anymore, of the code left see how much is about custom transactions (which could be done via the In-app extension framework or HCP) and how much is reporting (which could be replaced with the Multi-dimensional reporting tools). Where you find key unique features, consider if they can be built-top using HCP especially if you want to use the cloud edition. Finally learn HANA Cloud Platform and understand the SAP HANA Cloud Connector – register at HCP.SAP.COM


At the database level we have 2 big changes, the first is that S/4HANA only runs on SAP HANA, so if you are not a Suite on HANA customer yet, you will need to switch database platform. The second is the rethinking of the data model to remove aggregates and redundancies, that has the double impact of reducing the size of the database and increasing the simplicity of the model that helps with reporting. In what is an impressive feat of software engineering, SAP have replaced most of the aggregates / redundancies with “Compatibility Views” which are calculated on the fly at run-time, but means that most of the application code carries on running. I think this is a bit like changing the engines on a plane whilst it carries on flying !

Owen Recommends: Start to understand SAP HANA as soon as you can, if you understand the HANA Platform you will be able to do more with your S/4HANA system than those that don’t. I think a great way to do this is to get yourself a “small” 32Gb HANA instance on the HANA Cloud Platform.

Owen Recommends: Start to look at the quantity and quality of data in your existing system. Once you are on S/4HANA the quality of the data will become key to running in Real-time (straight through touch-less processing) and Future-time (predication) – look at tools like Information Steward Accelerator and Advanced Data Migration to help clean up your data and keep it clean. The size of the data stored will also be important in optimising the size of the HANA database – so look at archiving and start to consider how you might use data tiering (what needs to be in memory e.g 2-3 years) and what can be stored on disc.


For the on-premise version of S/4HANA the impact of the changes have been minimized with most of the integration points into and out of the system supporting compatible data structures and protocols. Some remote functions have been blacklisted and will not longer work – the Simplification List covers these. One area you will need to consider is the adoption of the 40 character Material Number as this will need to be adapted into upstream and downstream systems – if the impacts of this are large you can choose to continue to use the classic 18 character feature.

Owen Recommends: Understand the methods you are using for interfacing into and out of your system. Try to migrate these to real-time interfaces using non-blacklisted API’s. If you are not using SAP Process Orchestration for this task I recommend taking a look at the features available – this blog gives a good overview of the features available.


With the introduction of the new product S/4HANA (Business Suite for SAP HANA), SAP have leveraged 40 years of Enterprise Application expertise and taken the opportunity to simplify and optimize. The result being that you can convert much of your existing investment into the new S/4HANA product,  but I would strongly recommend that you take this once in a generation opportunity to do what SAP have done themselves and review what you do, how you do it and why you do it.

I will create a blog on what you need to do to transition to the S/4HANA Cloud Editions in the New Year.

You must be Logged on to comment or reply to a post.
  • Hi Owen,

    Thank you very much for sharing this informative post for existing SAP ERP users! Looking forward to reading your post for S/4HANA Cloud Editions! 🙂

  • Hello Owen,

    thanks for your post. I think it´s a good post-blog with major aspects of the On-Premise system conversion to SAP S/4HANA.

    In my last customer meetings I explained the conversion with the following aspects.

    1.Application Innovation and Compatibility

    With SAP S/4HANA we provide application Innovation. Just some key words:

    • Simplified Data Model
    • FIORI
    • Increased Throughput.

    We are doing things differently in SAP S/4HNA but we try to offer the application innovatiopn as compatible as possible. How we are doing this:

    • SAPGui as UI technology still supported. SAP FIORI is the Go-To architecture but SAPGui is still available (exception see S-List)
    • Comp.Views: Compatibility Views are offered to mitigate customer effort related to new Data models and related custom code.
    • Stable Interfaces: Existing integration scenarios can remain unchanged after system conversion to SAP S/4HANA (Note: This can be assumed for released remote APIs - in case unreleased remote function modules are used this need to be checked)

    2.Technical conversion versus Semantical Adaption

    The system conversion to SAP /4HANA On-Premise is based on well established lifecycle management tooling.

    • Software Update Manager (SUM) with Database Migration Option (DMO) for customers not yet on SAP HANA.

    The move to SAP S/4HANA OP is not just executing a technical procedure - we are doing things differently but we do our best to tell the customer whjere adaption effort might exist.

    • We have "built-in" tooling to make this transparent (Key words: Maintenance Planner, Conversion Pre-Checks). For custom code we offer a tooling for custom code analysis.
    • We have the Simplification List to describe the business impact of the innovation on existing customers (by the way: we are on our way to offer this S-List information aswell in a more customer-specific automated manner).

    By the way: I have a slot on the SAP d-kom in Karlsruhe where I will list these aspects aswell.

    Kind Regards,


  • Hi everyone,

    I work a lot on the data migration part in projects. Seeing a lot of new clients getting S/4 HANA, I wonder what does that mean for data migration?

    Do we still load the data into the ERP system (ECC)? Can we use the same tools (LSMW, BODS, ect)?

    If you have any material on that, I'd highly appreciate it!

    Thanks so much!


    • Hello Fernanda,

      basically the approaches to move to S/4HANA, on-premise edition are not different from SAP Business Suite (if you look from a high-level perspective).

      1. System Conversion --> technical procedure to install the new software to convert an existing system to SAP S/4HANA, on-premise edition.

      More details about the S/4HANA system conversion for example here: The System Conversion to SAP S/4HANA, on-premise edition 1511 - Technical procedure and semantic adaption tasks

      2. New Implementation / New Installation of a SAP S/4HANA, on-premise edition. This comes with a data migration from legacy system (or a SAP Business Suite system).

      In the on-premise landscape the customer defines the technology for the data transfer. The recommended architecture from SAP side is Data Migration Server (DMIS) and SAP Migration workbench (MWB). Other Migration Toolings like the Legacy Migration Workbench (LSMW) is not obsolete, but not considered as target architecture. For example the Data Migration related Best-Practise content for SAP S/4HANA is based/will be based on DMIS and MWB. Note: There is a correspondig Simplification List item (chapter - where I just realised that there is a "not" missing - will be corrected in Version 1.4. of the Simplification List)

      Kind Regards,


    • Fernanda,

      Frank is correct that for landscape transformation, new implementation and system conversion, LT is a powerful tool in the arsenal for migration to S/4HANA.  You must also consider the three major aspects of the migration business process:

      • how will I manage the project ?
      • how will I capture valuable design information for later use ?
      • how will I build the executable for LT, SAP DS and other EIM technologies ?

      SAP also offers Advanced Data Migration by BackOffice Associates in combination with LT, SLT, DS, etc. to cut imp,emendation costs, reduce go-live risk and shorten time to value for S/4HANA.  It is being rolled out as part of SAP’s standard migration suite.


  • Thanks for those explanations and tipps, Owen!

    Your grafic nicely shows that there is some Superseded Standard Code, which is no longer used, but still exists in the system.

    What's your take on this dead code: should/will we get ridd of it, and if so, how? (Will future releases delete it?)

    Another thing I noticed is that there are some transaktions (e.g. ME21) that still work just fine, despite the Simplification List saying they no longer exist. I wrote about that in my blog:

    Best regards


    • For the "dead code" I would recommend leaving this alone as it may have dependencies to other components that you are not aware of. I am sure that over time SAP will get to cleaning this stuff up, but I think the focus now is on simplification of the system (principle of one) and innovation on top of the HANA engines (Predictive, Geo, Text Search, IoT etc).

      As the transaction code ME21 is on the Simplification list you should not use it, even if it is still available. Perhaps raise a note to SAP about it being available so they can fix this error in future releases.


  • Hi Owen,

    SAP S/4HANA (Enterprise Management), Is it going to be a single software bundle or there going to be separate software for each ie,, SAP S/4 HANA Sales, SAP S/4 HANA HR etc..



  • Hi Owen,

    Thank you for sharing your knowledge. Can you please tell me what data model is used in s/4 HANA. I have basic doubt about data storage .

    S/4 HANA directly stores data into SAP HANA database or it uses application specific storage (like ABAP DATA Dictionary in SAP ECC) layer on top of the HANA database?

    Thanks in advance

    Suresh Jetti.

    • Data is stored in HANA.

      Business Logic is defined in the ABAP Application server and at run time some of this is pushed into the HANA database for execution.

      So less processing is done at run time in the ABAP server compared to Business Suite running on AnyDB.

      • If S/4 HANA  stores the data on SAP HANA directly,Then

        can we extract S/4 Application data from SAP HANA  at database level without communicating with S/4 HANA..?

        Lets take the scenario if we want to extract data from sap ecc , we have to request the data from application server  (i.e we are writing abap programs to get the data from data dictionary). We can't access the SAP ECC data  directly from the underlying database.

        • I believe you can, I am no expert but I think that is where SLT server comes in to play from what I read. It will be able to extract data from any source (regardless if it is ERP or Standalone database). Worth looking in to that if you want to explore further.

  • If S/4 HANA  stores the data on SAP HANA directly,Then

    can we extract S/4 Application data from SAP HANA  at database level without communicating with S/4 HANA..?

    Lets take the scenario if we want to extract data from sap ecc , we have to request the data from application server  (i.e we are writing abap programs to get the data from data dictionary). We can't access the SAP ECC data  directly from the underlying database

  • Thank you very much for sharing this informative post for existing SAP ERP users! Looking forward to reading your post for S/4HANA Cloud Editions!

    Well explained and useful to all. Great work.