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.

(image by Ignacio Kristof)

At the moment this blog is written the yellow arrow’s one, is the path that makes more sense. A company looking just for the Finance capabilities should target S/4HANA Finance 1605 and a company looking for the complete Business Suite should target S/4HANA Enterprise Management 1610.

Versions 1503 and 1511 at this point should only be considered only if a company already implemented one of them and want to move to the most updated version.

(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 do everything in the same project, only in a small 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 (options A and B 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.

 

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:
    • PRECHECK_UPGRADATION_REPORT
    • R_S4_TRANSITION_CHECKS
    • RASFIN_MIGR_PRECHECK
    • 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

Data migration

Data migration implicates the activities that happen after S/4HANA is installed. Now you are in a system with S/4HANA. Activities of this stage could be divided as:

  • Customizing
  • Migration of Finance Data.
    • Migration of Balances
    • Migration of Line items into Universal Journal
    • Migration of Material ledger.
    • Migration of House Banks.
  • It is important to highlight that most activities are for Finance. Other areas like Sales, Sourcing and Procurement, etc are less intensive as configuration required is minimum and data migration happens during installation.

Post-Migration activities

In this section we could include different activities:

  • Specific activities to finalize finance migration (Fill in due dates for FI documents, set migration to complete indicator, etc).
  • Follow up activities :
    • For sourcing and procurement
    • Sales
  • 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
  • Synchronization with Human Capital Management if required.
  • Enablement of Cash Management and Liquidity Planning if required.

 

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.

8 Comments

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

  1. Steve Schulze

    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?

    Regards,

    Steve

     

    (0) 
    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.

      (0) 
      1. Steve Schulze

         

        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.

        Steve

        (0) 
        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.

          (0) 
      2. Sasha Nunes

        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.

        Sasha

        (0) 
  2. Group Greenko

    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
    Regards

    Balaji

     

    (0) 
  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?

    (0) 

Leave a Reply