Converting to SAP S/4HANA: technical options

By Paul Snyman
Paul Snyman

Paul is Senior Vice President and Product Portfolio Owner responsible for Cloud and Managed Services at EPI-USE Labs. He has over 23 years of diverse enterprise technology experience. He is based in Silicon Valley where he is working to perfect the balance of technology interests, endurance activities, and family time.

Written on Jun 13, 2018 12:07:12 PM

12 minute read

What are your technical options as an existing SAP customer today running SAP ERP ECC 6.0 and looking to plan your path to S/4HANA?

SAP has sure come a long way since I first certified as a SAP Basis consultant in Waldorf in 1998, but I find that there is a lot of good – if sometimes confusing or outdated – information out there. For this article, I’m going to focus on laying out the conversion pathway to the latest on-premise version of S/4HANA version 1709 and the technical options available for you at an intermediate level of detail, and avoid the details around the different versions and the different deployment models of S/4HANA – with the caveat that this will eventually age out as well :)

Your three options to move to S/4HANA

Simplistically, SAP proposes that you have three options to consider to move to S/4HANA:

  1. A new Implementation, also called “Greenfields” if you want to reimplement from scratch
  2. A System Conversion, also called “Brownfields” and synonymous with “upgrade” or “migrate” (although SAP don’t like you using those terms since S/4HANA is a different product family altogether, so there is no formal upgrade but rather a conversion)
  3. Landscape Transformation, also called “Selective” or “Consolidation” for a more targeted migration or combination of specific datasets.

EPI-USE Labs specializes in helping customers with all the options above, either as a migration specialist or Basis managed service provider. For this article I’m going to focus on option (2), System Conversion (Brownfields), for those customers running SAP Business Suite today trying to figure out how to start moving towards S/4HANA version 1709.

I’ll touch on option (3) Landscape Transformation option in a future blog post.

System Conversion to S/4HANA (Brownfields)

SUM = Software Update Manager
Technically, SAP has a robust transition tool (named SUM) to do the system conversion to S/4HANA, migrating your old (Oracle/DB2/MSSQL) database to the SAP HANA database and upgrading your legacy ECC application to the newer S/4HANA code base. 

SUM = Software Update ManagerSource - SAP

One or Two Steps, Many Options
The SUM tool actually allows you to jump from pre-S/4HANA to S/4HANA in one jump. However, this one-jump process is idealistic since it only works if ALL of the following are true:

  1. SAP version: you are on at least SAP ERP ECC 6.0 and not something older
  2. Single/Dual stack: your ECC stack is ABAP only and not dual ABAP/JAVA stack
  3. Unicode: your database and SAP kernel are already Unicode enabled

If you are missing any of these three technical prerequisites above, then your process to get to S/4HANA will involve at least two hops, and this is where the myriad of different pathways and options come into play, since there is no correct one way to get there. It depends on many factors. SAP has published this flow-chart illustrating most of the different technical migration pathways (you’ll notice they assume your ECC is an ABAP-only stack):

Technical Migration PathwaysSource - SAP

Summary of Technical Steps
So, let’s break down all the technical steps to convert to S/4HANA, including the prerequisites, so you can understand if it makes sense to perform any of these in advance to prepare, or if you want to include them in a tight 2-3 hop process. To guide you I’ve prepared the following diagram:

Infographic2 to use-1

Prerequisites for System Conversion to S/4HANA
Split dual stack ABAP+Java into ABAP only
As mentioned, if your existing ECC 6.0 system is on a dual ABAP & Java stack you will need to split it out into two separate stacks so that you can convert the resulting ABAP-only stack to S/4HANA. This process is well documented; I would recommend starting with the article Dual-Stack Split, by Borris Zarske.

Upgrade to ERP ECC 6.0
In order to make one jump to S/4HANA your source system needs to be at least on ECC 6.0, since the lower SAP R/3 4.7 and SAP ECC 5.0 releases do not include the Customer-Vendor-integration (CVI) that is required for SAP S/4HANA. It doesn’t matter what ECC 6.0 Enhancement Package version you are on. If your system is also not yet on Unicode, you might be able to combine the upgrade with a Unicode conversion – see next point.

Convert to Unicode
SAP S/4HANA is only shipped with UNICODE, and the SUM process does not include a non-Unicode-to-Unicode conversion (for a 7.5x target). If you also need to upgrade your source environment to ECC 6.0 to get ready for S/4HANA, then you can combine these two steps together, using what is known as the Combined Upgrade & Unicode Conversion (CU&UC). (For more information on CU&UC refer to SAP Note 928729.) Converting an SAP ECC system to Unicode is a fairly well-documented process that is a mostly technical exercise with minimum functional impact other than regression testing areas such as interfaces, self-services, and custom ABAP code.

Preparation for System Conversion to S/4HANA
Remove or archive old data
Before you make the move to the SAP HANA database or the new S/4HANA version, you should understand that there is a business case to minimize how much excess data your environment has in it, due to the underlying HANA architecture using much more expensive hardware to store all data in memory and persisting data to more expensive storage.

Use this as an opportunity to clean up your system landscape, embrace that Production archiving project you’ve been avoiding, or simply reduce your compliance risks with the many data privacy regulations that exist today, realizing that this is not just a Production challenge; you might well be storing the most data in your non-Production systems. Further reduction is achievable through reduction of non-Production system sizes and removal of unneeded data from production.

Considering your data footprint

EPI-USE Labs offers a Pre-S/4HANA SLO engagement to reduce your data footprint before, to streamline your S/4HANA conversion project. You can also create lean, secure non-production systems with Data Sync Manager yourself at any time as well using our new GDPR Compliance Suite as part of your data privacy compliance toolkit.

Clean up custom code
If you have been running SAP ECC for years then no doubt you have your fair share of custom ABAP code sitting out there. The pathway to S/4HANA places a burden on you to ensure that all this custom code is updated to replace deprecated statements with new equivalents. Perhaps the best place to start is to even do away with custom code that isn’t used anymore – why waste time on something just sitting there?

Generically speaking, you should investigate the SAP Code Inspector (SCI) and the newer ABAP Test Cockpit (ATC). ATC has some technical NetWeaver stack requirements, and one handy solution I’ve seen used is to stand up a separate ABAP instance with the required software versions and use that to connect to and perform remote code analysis of your ECC environment from that ABAP instance without having to load anything on your ECC environment.

If you have to perform a Unicode migration or an upgrade from pre ECC 5.0 to ECC 6.0 then know that both of those processes will involve some custom ABAP code remediation.

For HANA database, in general, ABAP code runs on SAP HANA as before with the exception of any specific non-HANA database specific code; details can be found in SAP note 1912445. I would also recommend this SDN article from Thomas Fiedler.

The move to S/4HANA has its own requirements and tools for helping you to analyze and remediate custom ABAP code. You can still use the ATC to perform some S/4HANA semantic checks for your custom ABAP code; however, the Custom Code Analyzer is part of the formal S/4HANA conversion toolset and it evaluates your code against the Simplification Lists. See SAP Note 2185390 for more information, or you can refer to the SAP Help link on this topic.

Migrate your database to HANA
There are sometimes significant platform architecture changes considered when moving from a non-HANA to HANA database, and I’m going to skip over that in this blog post. The focus here will be the logical software steps required.

If you are wondering why I had the HANA database upgrade box in a different color in my diagram above and split across two silos, this is my attempt to convey that you can choose to migrate your non-HANA database to HANA before upgrading to S/4HANA, at which point your system will run on what is referred to as BSOH or Business Suite On HANA (meaning you are simply running ERP ECC 6.0 with a HANA database).

Or, your database migration to SAP HANA can be done as part of the SUM (with DMO) process when converting to S/4HANA. There is far less business process/functional impact to migrate your ECC 6.0 database from non-HANA to HANA, than it is to convert your ECC 6.0 landscape to S/4HANA – it is much more of a technology process and it enables your Basis teams to become familiar with administering HANA and getting to grips with its newer architecture and hardware requirements. Alternatively, we’ve also seen customers not having the time or the interest to pursue this from a technology perspective and only wanting to test once and go all-in with a move to S/4HANA; it really depends on what your motivations are.

Another side note to mention is that the move to NetWeaver Stack 7.5 has certain database source version requirements, meaning that your pre-NetWeaver stack needs to have it's database upgraded to a minimum level before you embark upgrading to 7.5 - for the HANA database this minimum level is SPS09, revision 97. For more information please consult SAP note 2158828.

The main part of this phase are SAP tools (S/4HANA Readiness Check) that analyze your existing SAP ECC system and identify the business processes (Simplification List) and custom ABAP code impacted by your move to S/4HANA (Custom Code Migration Worklist). Technically, I’m not going to go into detail here other than to mention that when considering the move to S/4HANA you’ll need to really get your Solution Manager deployment in order so that you can use the newer Maintenance Planner tool in this phase that SAP prescribes for identifying and downloading the relevant software. The SAP S/4HANA Readiness Check also works via Solution Manager.

EPI-USE Labs also offers a free HANA Readiness Assessment that doesn’t require Solution Manager, and is a super easy way to get some additional third-party perspective in the effort required to move to HANA and S/4HANA. All you have to do is to import a small transport into your ECC system and run a report that produces a meta-data extract in clear text, that gets returned to us via a secure portal and your report is made available to view online. No actual customer data is included, only things like version tables, row counts, specific configuration values, etc. that we’ve determined to give you a quantitative view of your system.

System Conversion to S/4HANA 
And finally, here you are at the final technical set of tasks that perform the actual conversion from old to new which are executed by SUM. I’m not going to go into all the technical steps, I’ll share some useful links at the end if you’re interested in all the details.

After SUM has completed its conversion process you’ll be running a new NW7.5 Unicode stack on a HANA database with the S/4HANA Core ABAP components. Great, but you still have some key tasks to finish up:

  1. Custom Code adaptation – think of this as your typical SPAU/SPDD process in an upgrade
  2. S/4HANA Migration Cockpit – think of this as importing any extraneous legacy data into your new S/4HANA system.
  3. Setup Fiori front-end servers – I would like to call out the new Fiori user interface which you need to understand and plan for in advance. You need to architect a Fiori Front End Server (FES) landscape design that enables your organization’s users to access the new Fiori user interfaces delivered in S/4HANA. The options available are an embedded deployment (FES embedded in S/4HANA), or a hub deployment (FES as a hub). This topic might sound innocuous but can get complicated pretty quickly since you have to consider network security designs, reverse proxies, authentication, etc.

In summary…

This is certainly not the first or the last article you’ll be reading on converting to S/4HANA, so I hope it helped you understand the technical steps and your options when considering moving from your current ERP 6.0 to on-premise S/4HANA 1709 via system conversion. Please contact us if you would like more detailed assistance with your company’s move to S/4HANA.

EPI-USE Labs has been helping customers convert to S/4HANA in addition to moving from physical to virtual, on-premise to cloud, in-house to fully managed. As an SAP partner, we have been in the SAP data management space for over 30 years offering SAP-certified software, landscape transformation and migration services, and managed Basis services.

To learn more about SAP S/4HANA and strategies for migrating that can boost your SAP systems into the future, including where to start and what your options are, you can watch the replay of our S/4HANA webinar below. Some questions that were addressed during the webinar:

●   Where do we start with S/4?
●   Conversion, upgrade or migration?
●   What does Landscape Transformation mean in the S/4 context?
●   Greenfield S/4 – how can this work for me?
●   Flotsam & Jetsam – what do I do with my existing systems?
●   Do I have to host an S/4 system in the Cloud? What are my options?


You may find these links handy...

  1. “Choosing your path to SAP S/4 HANA”, SAP E-Book
  2. ““Elements for Designing a Transition Roadmap to SAP S/4HANA”, SAP Services
  3. “SAP® S/4HANA Release 1511:
    What You Need to Know and Why Should You Care”, ASUG, Kevin F. Reilly
  4. “SAP S4HANA Cookbook”, SAP Community
  5. SAP Roadmap Viewer
  6. “SAP S/4HANA System Conversion – At a glance” SAP Community, Roland Hamm
  7. “The System Conversion to SAP S/4HANA, on-premise edition 1511 - Technical procedure and semantic adaption tasks” SAP Community, Frank Wagner
  9. “The road to SAP S/4HANA: the different transition paths” SAP Community, Frank Wagner
  10. “#SAPSysArchs – Preparing Your SAP Landscape For S/4HANA – call deck”, SAP Community, Andy Silvey

Topics: SLO s/4HANA Cloud Migration landscape transformation SAP Cloud Deployment S/4HANA version 1709 System conversion

Add a comment