Skip to Content

DISCLAIMER: This blog is based on due diligence performed at the time of writing. As options and paths can change over time, readers are advised to check the latest official information before making business decisions. The author accepts no responsibility for the current validity, accuracy, completeness or quality of information provided.”

The objective of this blog is to provide an overview of the steps involved in the scenario System Conversion.

You have 3 main scenarios in the adoption of S/4HANA

  • New system: Implicates the implementation of a total new system. For companies not using SAP or companies that have very customized, problematic, etc SAP system and want to start from zero.
  • System Conversion: You have a running SAP ECC system and you want to convert it to an S/4HANA system.
  • Landscape transformation: You have various SAP systems and want to merge them in a new S/4HANA system.

This adoption scenario is for organizations that already are using classic SAP Business Suite and want to implement S/4HANA. This is for systems on-premise as conversion cannot happen to the cloud.

Define the proper adoption path

There are several adoption paths, depending on what SAP version are you on. The chart below shows the possible path adoptions.

(the chart below shows the possibility of migrating only to S/4HANA Finance, just the finance functionality or complete S4 suite).

(image by Ignacio Kristof)

(image by Ignacio Kristof)

As said in the in the chart above, if your system is not yet in HANA DB, I would first migrate the system to HANA DB with the correct support package and then, in a subsequent process would do the migration to S/4HANA. I would only do  a One Step approach (HANA migration + S4 conversion)  in a small and simple system landscape.


“Must-know”  for the conversion process

See below some tools and aspects that you should consider for migration:

SAP Maintenance Planner It must be used to plan the installation; checks the system pre-requisites and creates the XML file that SUM uses to install S/4HANA. Checks basically if add-ons are compatible for the conversion and if Business Functions active in system are accepted for conversion.

Software Upgrade Manager (SUM) is used to update the software. If the system is not yet migrated to HANA (first two cases in chart of point 1), SUM with DMO option needs to be used (Data Migration Option).

Pre-checks  – SUM will perform pre-checks before installing, but in order to have flexibility on when performing the checks, you can implement report R_S4_TRANSITION_CHECKS with Note 2182725 in order to check how your system is.

(image from SAP-Press book “SAP S/4HANA an introduction”)

3rd party vendor applications – It is critical that you have vendor keys and the apps are certified by S/4HANA. This could bring issues/stoppers during installation.

Simplification List Simplification List is the document from SAP that provides a detail of the changes suffered by classic ERP functionalities (obsolete t-codes and processes, changes to data model, etc). Having a clear understanding of this document will help you detect impacts to your system.

Data Model simplification As probably is well known by anyone who has already started researching about S/4HANA, there is a deep change in the table structure for finance and logistics. Aggregates table disappear, most of index tables disappear so during migration, SAP will take data from legacy tables in order to load new tables.

Tables that disappear, still will be available as CDS Views. This mean that SAP takes the info and fields of new tables, and build a view of the old table on the fly.

Business Partner Approach S/4HANA Enterprise Management manages a new approach for managing vendor and customer master data, that requires that all customers and vendors are created a Business Partners. This is not required for S/4HANA Finance version. See this blog for more details: Business Partner Approach

Custom code You need to analyze your custom code to understand what breaks basically with the implementation of the new S/4HANA Code. If your code has modification to the standard SAP core code, an important part of it will stop working probably.

We said that many tables disappear in S/4HANA. The reports that only reads to removed tables will continue working as SAP will automatically point them to the CDS Views of this tables. Programs that write to the tables that disappear, will need to be remediated-

SAP provides tools like Code Inspector, ABAP Test Cockpit, etc in order to analyze the existing code.

Also, after installing SPDD and SPAU analysis will be required.

Code Optimization Not mandatory for conversion process, but definitely a MUST during the project is to analyze the custom code that can be improved to take advantage of HANA platform. For sure, part of your custom ABAP program have part of the code that can be pushed to HANA DB in order to increase the performance of the program.

New tools  delivered by SAP on 2017

SAP Transformation Navigator Is a tool to guide customers to select the best S/4HANA products. I recommend to do the Open SAP course if you are interested in this tool.

SAP Readiness Check for SAP S/4HANA  it is a tool that has a better display, FIORI style, of the information for system readiness. It is implemented through SAP Note 2290622 – SAP Readiness Check for SAP S/4HANA and accessed through solution manager.



Overview of Migration (or System Conversion) process

  • Pre-Conversion tasks
  • Preparing the Conversion
  • S/4HANA Installation
  • Data Migration
  • Post Migration

Pre-conversion tasks

This section implicates technical preparations required before starting installation/migration process.

  • Review System Conversion guide form SAP. Key document for system conversion.
  • Download of OSS Notes needed for the S/4HANA Preparation.
  • Perform cleansing and archiving activities. Archive all you can and cleanse data not relevant like spool and job logs.
  • If you do not have Customer Vendor Integration with Business Partner (Business Partner Approach) , you must do this before installation.
  • Review versions of SUM, Maintenance Planner.
  • Download DVD for installation.

All this will ensure a more efficient and less problematic migration process.


Preparing the Conversion

Activities to be performed when you consider your system is ready to start with conversion process.

  • Implement OSS Notes
  • Run pre-check programs provided by OSS Notes to ensure your system is in good shape to migrate to S/4HANA:
    • Run consistency checks
  • Perform corrections based on the results of the checks in point above.
  • Ensure that all held documents are posted (or deleted).
  • Take baselines of existing information in order to compare with the information post-migration to ensure consistency. SAP provide some reports in Conversion Guide but you will probably want to add more checks.  
  • Implicates the execution of technical installation using SUM.


S/4HANA Installation

Consits of 2 phases, executed by SUM tool. It refers to the actual installation of the software, but not the migration of transports and some data migration activities. This is performed by Basis.

  • Uptime: during uptime, the system still is accessible. SAP performs some activities like checkings, installation of some components, some structures creations. The timing depends on the size of the system.
  • Downtime: during this phase the system is not accessible. Software is installed and some tables are completed (not ACDOCA, which is completed during Data Migration),



During this phase, transports with customizing required for S/4HANA and code adjustments are migrated.


Data migration

Data migration implicates the activities that happen after S/4HANA is installed. Now you are in a system with S/4HANA and different steps need to happen in order to migrate Finance Data. Following SPRO path, we can identify the following:


  • Partitioning of Universal Journal Entry Line Items Table: This is not an “executable” program or step for the migration. This is a recommendation of doing partion of ACDOCA when it is expected to have more than 500 millon records. And it is a MUST, when ACDOCA is expected to have more than 2 billon records. This size can be determine by doing a migration practise with production size.


  • Regenerate CDS Views and Field Mapping: Required to re-generate the compatibility views and data migration views to adapt them to the configuration performed.


  • Analyze Transactional Data: This steps performs a check on FI documents before starting data migration. This allows to find inconsistent documents on tables BKPF, BSEG, BSIS, BSID, BSIK, BSAS, BSAD, BSAK. It does some checks like “clearing information missing”, “zero balance”, “line items are consistent”, etc.                                                                     After executing, there is an step “Display Statos of Analyze Transactional data”, that will show the errors detected, which have to be corrected before starting migration.


  • Start and Monitor Data Migration : This is the  actual migration to table ACDOCA It is a monitor or cockpit that executes several migration programs, showing the status of completion and errors. In previous versions like 1503 or 1511 FPS0, the programs were separated steps in different points in SPRO. Then SAP implemented this monitor, which was really an improvement, making the process easier. Several programs or activities are performed under this step. See below:



  1. GCC Check Consistency of G/L Accounts and Cost Elements: Checks that GL accounts and cost elements are consistent before Migration.
  2. GCM G/L Account and Cost Element Merge: Merges the cost elements into GL account master data.
  3. DAA Default Assignment of Cost Elements: Default assignments in the former cost element master (CSKB) are transferred to the default account assignments
  4. R20 Reconciliation of Transactional Data: Checks that FI documents are consistent and ready to be migrated.
  5. ENR Enrich Transactional Data: This data enrichment is required due to the merge of FI and CO documents. The program performs several activities:
    1. fills some fields of BSEG with information from BKPF.
    2. fills some fields of COEP with information of COBK and OBJNR.
    3. filling of profit center into CO line items
    4. filling of company code data into old CO  line items
    5. Some adjustments to fix asset depreciation.
  6. R22 Check enrichment of transactional data: If any error is displayed, it can has to be corrected.
  7. MUJ Data Migration into Unified Journal: The actual migration of line items into ACDOCA happens in this step. Items from BSEG or FAGFLEXA, COSP, COSS, ANEX and ANEP are migrated.
  8. R23 Check Migration of Journal Entry: shows the results, and if there are errors, they need to be corrected and migration restarted.
  9. M10 Migrate Material Ledger Master Data: Ensures that the material ledger is activated for all valuation areas.
  10. M20 Check Material Ledger master data: Checks results from previous step.
  11. M11 Migrate Material Ledger Order History: If material ledger was not active in any valuation area before S4 converstion, this step ensures that all existing PO records are converted into the material lesger currencies.
  12. M21 Migrate Check ML Production Order and Purchase Order History: Checks results of previous step.
  13. DLT Data Migration into Unified Journal: Aggregate Deltas : This step also called Migration of Balances, ensures that the ACDOCA table shows the same total balances as before migration. Before S/4HANA , financial statements were based on totals records (like table GLT0), now the total is built from aggregating on the fly ACDOCA. So this step ensures consistency of those total balances, due to differences that could come from Balance Carry Forward, Archiving, Customer specific programs, etc.
  14. R24 Check Migration of Balances: Checks  the results from previous step and display errors.
  15. AFA Initial Depreciation Calculation: This activity build the initial depreciation values for Asset Accounting.
  16. R25 Check Initial Depreciation Calculation: Checks results from previous step.
  • Migrate General Ledger allocations: all G/L allocation cycles that refer to the FlexGL sum table FAGLFLEXT are changed to refer to the new view ACDOCT


  •  Migration of House Banks:  Migrates existing Housebanks to the bank account master data in the new application Bank Account Management.

Post-Migration activities

In this section we could include different activities, required to complete the migration to S/4HANA.

  • Specific activities that are in SPRO path:
    • Complete  Migration:
      1. Final reconciliation after migration: SAP recommends some reports to do this migration.
      2. Set Migration to “Completed” –>  Users can post again.
    • Activities after migration:
      1. Transfer Application Indexes
      2. Fill due dates in FI documents
      3. Fill offsetting accounts in FI documents


  • Other activities that are not in the SPRO path for Data Migration, but are part of the S4 implementation, like the enablement of FIORI.

The points above are just and overview and do not include activities related to other SAP solutions that you could be using. For example:

  • Integration with ARIBA or Success Factors: This requires specific activities for connecting ARIBA with S4.
  • Synchronization with Human Capital Management: If you are using HCM, a synchronization between HCM and S/4HANA is required so HCM master data is synchronized with employee vendors that now are Business Partners.
  • Enablement of Cash Management and Liquidity Planning if required. It has an specific set of steps (you can check another blog I wrote on this).


I hope you found this blog helpful and it is useful to provide you a big picture of what a conversion from SAP ECC to S/4HANA could implicate. Comments with corrections and extra info are more than welcome.


To report this post you need to login first.


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

  1. Former Member

    Hi Ignacio,

    Thank you for the information.  I do have a few questions regarding the conversion to HANA.  I’ve been searching blogs for a few weeks and can not find the answer.

    What happens to custom secondary indexes?  Do they cause problems in the conversion?  If we still have custom code that relies on the custom indexes will they still be efficient?




    1. Ignacio Kristof Post author

      Hi Steve, I do not know the exact answer. But I will find out. And let you know after the weekend. Could you provide in what table do you have the secondary index? Or a couple of examples maybe.

      1. Former Member


        Hi Ignacio,

        We have secondary indexes on many SAP and non SAP tables.  A few examples of SAP tables include EKKO (mandt, ekorg, aedat), VBRK(mandt, sfakn) and MSEG (mandt, aufnr, bwart).

        Thanks for your help.


        1. Ignacio Kristof Post author

          Hi, I was checking with a couple of colleagues. They mentioned that custom secondary indexes did not cause a problem during migration and were not lost.

          But the point is that you should not need them, as tables could be flagged as columnar table, improving the search and eliminating the need of secondary indexes.

          I hope this helps and please feel free to post if you have more information.

      2. Former Member

        Hello Ignacio. . Trust you are well

        Excellent post, very helpful. Based in your experience, how long (in weeks or months) could take a conversion from ECC HANA EHp8 to S/4HANA 1605 Finance ?…I understand there are some variables that could impact the timeline, but we are looking a high level estimate (best and worst case scenario). Thanks for your comments and for sharing your experience.


        1. Ignacio Kristof Post author

          Hi Sasha, apologies for the delay. Really it depends of several factors:

          • From what version are you starting.
          • Skills of your IT team or support you may have.
          • System complexity (quantity of CC,

          Assuming you already are running on HANA platform:

          • A small, mostly standard landscape, I would plan it for 6 – 8 months.
          • For most of average systems (several countries and company codes, several Z solutions) I would plan it for 12-15 months.

          This process includes:

          • Understanding how to perform the conversion.
          • Practice the process.
          • Remediate custom code.
          • Have a really complete test.
          • Start understanding improvements to processes.

          And after that it would be a continues process of adapting processes in order to take the real benefit of S/4HANA.

  2. Former Member

    Hi Ignacio,

    When i am migrating from ECC6.0 EHP4(Suse10)  to S/4 HANA 1610(Suse12) using DMO,  Is there shadow system created on source system for the conversion process?

    Source MAxDB 7.7.04

    OS: SuSe 10.3

    ECC EHP4

    Kernel 701



    1. Former Member

      Hello Balaji,

      Can you please share the document for SAP ECC to S/4 Hana migration (Or steps).

      Actually I’m doing same but not getting any proper steps

      Source System : ECC ehp07,MSSQL,Windows

      Target System : S/4H 1710 ,Suse 12

      Thank you..!



      Ganesh K


  3. RajayKumar Chandrakanth

    Thanks for the detailed steps – very well described. One very basic question though. You have mentioned ” Software Upgrade Manager (SUM) is used to update the software. If the system is not yet migrated to HANA (options A and B in chart of point 1), SUM with DMO option needs to be used (Data Migration Option).”

    However I am unable to determine where in your write up is Options A and B in Chart of Point 1? Could you please point out to where exactly in the details provided by you, are these options listed.

    On a different note, what is the roadmap that SAP has suggested for any ECC on AWS public cloud to S/4 HANA on managed cloud? Will it be a system conversion or new implementation? If it is system conversion, how will the configurations move from current ECC on AWS public cloud to S/4 HANA on managed cloud. Will you be able to shed some light on this please?

  4. Ignacio Kristof Post author

    Hi RajayKumar. Really apologies for the delay.

    Regarding your first question, it was corrected the wording and now it should be clear.

    Regarding question number 2, I am not an expert to reply, but I would consider it as a new implementation, as for me system conversion is in on premise system.

    I believe that there is no a system conversion process from an ECC cloud system to S/4HANA cloud.  If you found out something, please feel free to post it here, as it is an interesting topic.

    I recommend to read the blogs below and ask your questions there. I think that those experts from SAP itself are the best to reply. Yours is a good question that many consultants may have.


    1. RajayKumar Chandrakanth

      Hello Kristof,

      I found that one of the options that can be used in the query that I had raised is to do a system image backup from ECC on AWS Cloud to S/4 HANA managed cloud. Now the key here is that S/4 HANA managed cloud should also be on AWS. Else AWS is unlikely to allow back up if a customer is moving to another cloud. It ofcourse depends on the type of contract that a customer has signed with AWS. In the worst case scenario then, it would be an entirely new implementation with only data being provided by AWS when a customer exits AWS.

      However in your above response, I feel you understood it as S/4 HANA cloud which to me is the S/4 HANA cloud edition. In such a case then it would be a new implementation as S/4 HANA cloud is an entirely different product compared to ECC (whether on Prem or AWS cloud, ECC is same). Actually my original query was wrt to ECC on AWS cloud to S/4 HANA on managed cloud (say AWS).

      Hope I have been able to provide an explanation.




  5. Former Member

    Hi Ignacio,

    Thanks a lot for this very useful document.

    Could you please help me with some document link with more detailed information about the custom code and data migration processes for S4Hana migration. And what we should keep in mind for the efforts for this two activities? Like the number of custom objects etc.

    1. Ignacio Kristof Post author

      Hi Nabarun, See some good links. 

      And for these 2 acitivities, yes, the number of custom objects, specially the ones that write to tables are the main driver. And for data migration, the size of the system (quantity of company codes, BSEG number of records, last archiving). The main recommendation I could give you, is to do an end to end practise in a production size system.







  6. Former Member

    Hi Ignacio,

    We have SAP MDG Hub (7.0) and Operational ECC (EHP7) system in landscape and planning to move both the system in SAP S/4 Hana Cloud. We have both Customer and Vendor domain implemented in MDG Hub.

    Question- We have same BP# and Vendor# and different nos for BP# and Customer#  in MDG Hub. Once ECC is moved to S/4 Hana cloud, synchronization of vendor is not an issue as with CVI we can get same BP No. created. But what about customer. Do we need to load Customer related BPs from MDG Hub to Operational S/4 Hana? What is the process for that. We want to keep same number for Business Partner# in MDG Hub for Customer and Business Partner#  corresponding to customer in Operational S/4 HANA .


    Best Regards,


    1. Ignacio Kristof Post author

      Hi Nilesh,


      I do not have experience with the scenario you mention. S/4HANA in the background uses the same old customer/vendor tables, where BP is a shell. So it should work pretty similar as it works today for SAP ECC.

      Please see the links below if someone can help there



  7. Former Member

    Hi Kristof,


    It’s really a useful bog to understand the system conversion transition scenario for Migrating to S/4HANA. Is it possible to update the adoption path and chart with the introduction of S/4HANA 1709 version. I see lot of prechecks and activities to be done here when compared with other scenarios. Which transition scenario out of 3 will be cheaper in a chronological order.

  8. Vipin Nagpal

    Hello Expert,

    We got scenario where, customer is having ZZ field in BSIK table in ECC system.

    Now in S/4 HANA system BSIK table is no longer available.

    How can we handle this field in S/4 HANA table?



    1. Ignacio Kristof Post author



      Apologies for the delay. I did not faced this scenario, but the ZZ field from BSIK should be added to ACDOCA table.

      BSIK is an index table for BSEG, that now is replaced by ACDOCA; and you are able to append custom fields into ACDOCA.

      Please refer to note 2403232 – Extending the Universal Journal with Customer fields


  9. Former Member

    Hello Ignacio,

    Congrats for the amazing post.

    Regarding the tables that were converted into CDS views. This approach facilitates the conversion of old ABAP programs to S/4 HANA and decrease the cost of these implementations. This way do you know if SAP has some plan for discontinue them and force customers to rewrite the programs? I mean, do we need to evaluate this situation in the future?

    Best regards.

  10. Binoy Vargis

    Hi Ignacio,

    Nice Blog. Just have a question.Is it a pure technical job with these steps or any functional consultant should be involved.





    1. Ignacio Kristof Post author

      Sorry, I left this blog unattended. But definitely functional involvement is required. Specially to understand errors, that could be related to functional problems.

  11. Janine Parial

    Hi Ignacio,


    nice blog! i just have a question.. are custom/extension fields (ex: append structures in std tables) also migrated to S4HANA via SUM? how about the data? do you have any sapnote or supporting document for this?

    1. Ignacio Kristof Post author

      Hi, sorry for the late reply. I am pretty sure you can, but I do not know how. I am functional consultant, so this goes beyond my skills. Thank you.


Leave a Reply