Skip to Content
Author's profile photo Former Member

SAP S/4HANA – System Conversion: Frequently asked questions


i would like to inform that  I will not incorporate updates of links in this blog. I shifted my focus from S/4HANA System Conversion to SAP S/4HANA Public Cloud Business Configuration. Accordingly I will not be able to keep this blog up-to-date.
Thanks for your contribution, questions and friendly feedback.

Kind Regards,




we recently updated the external FAQs of SAP S/4HANA regarding the System Conversion topic:
Find below an extract out of these external FAQ just for the System Conversion related questions.
Note: that the original is always the external FAQ. In this sense this blog is just for your convenience
My apologize for the ugly look-and feel of the table in S4 SCN.

Kind Regards,

Question/ Issue  Answer
What are the Pre-requisites and the supported start releases for a system conversion to SAP S/4HANA You can find the pre-requisites and the supported conversion paths in the following official documents:
1. Conversion Guide for SAP S/4HANA: –> On-Premise –> Product Documentation: Conversion Guide2. SAP S/4HANA Release Information note (RIN): – The release-dependent RIN note can be found in the appropriate Conversion Guide – Release Information note SAP S/4HANA 1511: See SAP Note 2189824 – Release Information note SAP S/4HANA 1610: See SAP Note 23464313. Additionally information can be found in the following SAp S/4HANA SCN Blogs: – –
What are the different approaches in Software Update Managere (SUM) and how can we optimize the required business dowtime of a SAP S/4HANA System Conversion Basically three approaches within the Software Update Manager (SUM) are supported:
1. Standard Approach The Standard Approach of the SAP S/4HANA system conversion is a System Switch Upgrade procedure. This procedure installs in the pre-processing phase of the system conversion a copy of the system, the shadow system, in parallel with the original system. The shadow system is used to update the affected software components and to install the additional components, while the original system is still in production operation. The shadow system is then used to perform the modification adjustment of the ABAP Dictionary objects and the activation of new ABAP Dictionary objects that are part of the SAP S/4HANA system Conversion.   In execution phase of the SAP S/4HANA system conversion the appropriate steps are running and the system is in downtime. Those steps are: switch to the new system; tables prepared in the shadow system are copied to the target system: switch of the SAP kernel; change of the environment for the new release, convertion of the application data from old data structure in new SAP S/4HANA data structure. After the finalizing the execution steps the system is technical converted to SAP S/4HANA. The standard approach of SUM is available for all conversion paths to SAP S/4HANA and SAP S/4HANA Finance.
2. Downtime Optimized Approach Within the Downtime Optimized Approach of SUM downtime is reduced by moving data conversion partly to uptime (in the standard approach executed in downtime) The Downtime Optimized Approach of SUM is currently available within a pilot approach (customer can request   to use the Downtime Optimized Approach – details of the request process need to be provided) for the system conversion to SAP S/4HANA Finance 1605, SAP S/4HANA 1511 and SAP S/4HANA 1610
3. Customer Specific Approach With the Customer Specific Approach of SUM further reduction of downtime is based on a service project (Near Zero Downtime Approach)More Information: – SAP Help:
– Software Update Manager (SUM) –> –> System Maintenance – SCN
– the following S/4 SCN Blog: < tbd. – Boris Rubarth will write a blog > – SAP TechEd Session: ITM201 – Holistic View of System Conversion to SAP S/4HANA: Link (to be made external)
What does it mean that there are technical and semantical tasks as part of the SAP S/4HANA System Conversion? Due to the fact that SAP S/4HANA is a different product and not the successor of SAP ERP, things are different here. Accordingly there are System Conversion related tasks which are of a more technical nature (Migrationg your Database to SAP HANA, Installing the SAP S/4HANA Software, Converting application Data from old data structure into new SAP S/4HANA Datastructure – Steps supported by the Software Update Mananger [SUM]) and adaption tasks which do have a more functional related nature. Beside the technical steps a SAP S/4HANA conversion consists of 3 logically distinct adaption categories
1. Functional Impact – Functional impact of application simplification and following the principle of one (can be found within the Simplification List fro SAP S/4HANA) – Many simplification list items can be done on start release as preparation for SAP S/4HANA conversion
2. Custom Code Impact – Upgrade-like tasks with SPAU, SPDD and SAP S/4HANA specific custom code efforts (Remark: Experience shows that SPAU and SPDD efforts often exceed S/4 specific custom code efforts) – SAP S/4HANA specific custom code efforts are mainly resulting from data model changes Recommendation: perform housekeeping (get rid of unused code, delete unused data, …)
3. Optional Consumption of Innovation – Traditional capabilities are generally available thus it is possible to convert to SAP S/4HANA rather technically – The degree of process change is largely a business decision when planning the conversion project More Information related to this question: SAP Help: – SAP S/4HANA Conversion Guide – Simplification List for SAP S/4HANA
What are the differences with regards of execution steps for the supported conversion paths: 1. SAP ERP to SAP S/4HANA 2. SAP ERP to SAP S/4HANA Finance 3. SAP S/4HANA Fianance to SAP S/4HANA Basically the supported system conversion paths are described here;
1. Conversion Guide for SAP S/4HANA: –> On-Premise –> Product Documentation: Conversion Guide
2. SAP S/4HANA Release Information note (RIN):All three conversion paths are technically executed based on the Software Update Manager (SUM). With the move to SAP S/4HANA Finance a customer introduces the application innovation in Finance area. The logistics par tof SAP S/4HANA Fiance is still based on the traditional capabilities known from SAP ERP. Accordingly the adaption tasks are related to the new innovations in Finance area. The functionalities in logistics are continued to be use in an unchanged manner. With SAP S/4HANA (release 1511 or 1610) innovations in Finance and Logistics are delivered. The tasks to adapt to the new innovative functionalities are here in Finance and in Logistics area. For a customer converting from SAP S/4HANA Fianace to SAP S/4HANA just the logistics related adaption tasks need to be addressed (the adaption to the new Finance innovations are basically already done with the first step, the move to SAP S/4HANA Fianance).
What are the supported Add-Ons for SAP S/4HANA. How can I de-install a no longer needed Add-On There are basically three types of Add-Ons relevant within the system conversion to SAP S/4HANA 1. SAP Add-Ons (e.g. SAP Portfolio and Project Management ) You can find more information about the supported SAP Add-Ons: – within SAP note 2214409 (SAP S/4HANA: Compatible Add-ons) – In the Feature Scope Description (see SAP Help – – For Add-Ons delivered by SAP Custom Development for SAP S/4HANA see 2. Certified Partner add-Ons You can find more information about supported Certified Partner add-Ons: – 2244450 – SAP S/4HANA, on-premise edition 1511: Compatible partner products – 2392527 – SAP S/4HANA, on-premise edition 1610: Compatible partner products – in the Application Developers Directory: 3. Any 3rd Party Add-ons Please execute the SAp S74HANA system conversion planning step within Maintenance Planner. In case not supported Add-Ons of this category are installed on customers system are brought up in the corresponding Stack XML file SAP Note 2011192 provides additional information about add-ons which can be un-installed
I get the following error message within the Maintenance Planner: – The technical system <system name> contains the following add-ons that are not supported in SAP S/4HANA – The technical system <system name> contains the following business functions that are not supported in SAP S/4HANA What does that mean and what is the impact Within the conversion planning step in Maintenance Planner ( there are Add-Ons (SAP Add-Ons or Partner Add-Ons) and Business Functions detected which are not yet supported by the selected SAP S/4HANA target release. See the SAP S/4HANA roadmap as outlook for the already planned and future enhancements (SAP S/4HANA Roadmap: With not supported Add-Ons and Business Functions a system conversion is not possible. If you want to to un-install an Add-On on start release see SAP Note 2011192 for details. In case just a conversion of a TEST system is the target you can get in contact with SAP to apply a workaround (note: this workaround is not possible in the productive environment)
What is the difference between SAP S/4HANA System Conversion and an SAP S/4HAN Upgrade? We use the term “System Conversion” for the move from SAP ERP and SAP S/4HANA Finance (1503 or 1605) to SAP S/4HANA (1511 or 1610). For the move from SAP S/4HANA 1511 to higher SAP S74HANA releases (currently it the follow-on release is SAP S/4HANA 1610)   we are using the term “Upgrade”. – Within the system conversion the customer moves to SAP HANA database (in case customer is not yet on SAP HANA DB), installs the SAP S/4HANA software and executes a data conversion from old data structre to the new SAP S/4HANA data structure. – An upgrade to the next SAP S/4HANA release applies the newest version of the SAP S/4HANA software.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Devraj Bardhan
      Devraj Bardhan

      Frank, don't worry about the look and feel of this blog. We are interested in reading your content and don't really care about the environment.

      Author's profile photo Joachim Rees
      Joachim Rees

      Well, actually my 1st thought when scanning the blog was "oh, that table looks strange".

      But of course I can agree with you on that: Better have the info in an not-so-nice looking way, than not having it at all!

      So thanks for sharing, Frank!


      Author's profile photo Sanjeev Joshi
      Sanjeev Joshi

      Well Q & A are very informative.

      We had some queries regarding S/4 HANA conversion with methods:-

      1.First Qu:-If we go for new implementation of new S/4 HANA -How to Code migration from old system to new S/4 HANA system in new implementation method.

      2.Second Qu:-In new Implementation , How to do data exchange if table structure is different

      3.Third Qu:-If we go for system conversion method using system copy(side by side conversion with minimal down time) How to migrate data basically about Deltas Accumulated data transformation.




      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Sanjeev,

      I´m no longer in the System Conversion topic, so just my two cents here:

      1. First you should use the chance to transfer custom code to standard or use lifecycle compatible methods to build own logic.
        Basically you can set up transport routes from your SAP ERP system to S/4HANA OP and tranport the coding. So you have here same opportunities like you would have in SAP ERP to transport Custom Code from System A to System B
      2. In a New Implementation the data (for example Business Partner, Materials ...) are migrated using Data Migration tools from start system (for example a SAP ERP) to S/4HANA. Here you (or to be more precise the Data Migration Tools) are calling inbound interfaces (e.g. Create_Business Partner Interface). Using officially released interfaces then you are creating the migrated data in the right S/4HANA data structure.
      3. Don`t know what you mean with a "side by side conversion"


      Kind Regards,




      Author's profile photo Sanjeev Joshi
      Sanjeev Joshi

      Dear Frank,

      Thank you for your quick response and your answer more valuable to us.

      Query from your side about side by side conversion:-

      Side by side conversion means:-

      We will do system copy of system which we want to convert for s/4 HANA ex:-Production system.
      The primary system will be running for users we will convert copy system into S/4 HANA this is called as Side by side conversion

      In that We had one query like after system copy and activities there will be some data till user will start using s/4 hana system,so there will be some delta data accumulated.

      Our question is:-How to migrate data basically about Deltas Accumulated data that will be remaining data


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hello Sanjeev,

      like mentioned in the beginning of some of my SCN blogs. i moved into another area and I´m no longer working in the S/4HANA System Conversion area.

      I don`t have an answer to your question, but for data which have been created in R/3 Prod system between copying  and finishing the S4 System Conversion of you copied system I would assume you can use the data migration tooling.

      In any case I will ask the colleagues within the S4 System Conversion to have a look in your question (can not promising anything).


      Kind Regards,



      Author's profile photo Roland Hamm
      Roland Hamm


      Hi Sanjeev,

      That what you intent to do naming it a ‘side by side conversion’ is basically available as a Consulting Service by SAP, called Near-Zero Downtime for SAP S/4HANA Conversion ( see more information how to order/engage via SAP Note 693168 – Minimized Downtime Service (MDS) ).

      The basic challenge is to identify and record the changes which are happening on the ERP production system in the time the conversion happens on the clone system, and the consistent replay of the changes (including data model mapping!) to the clone system

      In principle the technical process of a near-Zero Downtime technical Conversion to S/4HANA is as follows:

      • A data change detection and recording is implemented via SLT-like database triggers for the most important business processes. Other data changes can be prohibited by freeze triggers, so that other business processes of minor importance are ‘switched ‘ to read-only.
      • once the change data recording is in place, a copy of the podcution system is created.
      • on the production copy the technical conversion including post-processing and technical validation takes place.
      • after that the meanwhile recorded changes on the running production system are transferred. This is pretty tricky as the data has been recorded on the old data model and now has to be mapped to the S/4HANA data model by syntactical and semantical transformations. Therefore usually SAP is restricting the scope of the transferred data to only a few important business processes, while the other data is set to read-only.
      • with that data transfer from a still live ERP production system both systems come pretty close in regards to the state of data.
      • now the ERP production system is shut down and the final delta replay takes place so that all the relevant remaining data can be consistently transferred.
      • After successful data transfer and validation users are switched to the new (converted) clone system which will be the new production system on S/4HANA.

      As you can see, this is a complex process where one would need to discuss with the customer about the boundary conditions which data shall be replicated as this greatly influences the scope/complexity of the NZDT project and the data transfer volume.

      best regards,




      Author's profile photo Former Member
      Former Member

      Thanks Roland the above is an excellent overview.

      We investigated NZDT for a Client (12 months ago so NZDT may have moved on) as they only had approximately 8-12 hours to do a conversion to 1503 (over 2 billion records) Finance and another 8-12 hours for BW on HANA etc on the cutover weekend.

      In the end due to cost the Customer went for archiving and optimising the conversion process (BASIS adjustments and SAP notes created specifically for the customer). They still had over 2 billion records to convert.

      Just sharing.

      Author's profile photo Former Member
      Former Member

      Hi Roland,


      Just want to understand that once the system conversion is successful and business go-live on the system has happened. There is business requirement to make restatement/adjustment postings in previous periods of current financial year (when ECC was in use). Are these adjustment postings allowed by opening past period or any specific restrictions on the same.

      Thanks for your support.

      Author's profile photo Former Member
      Former Member


      Very Nice Frank. I have gone through all your is very simple with good explanation.