Skip to Content

With the end of mainstream maintenance for SAP ERP 6.0 in 2025, existing SAP customers should start preparing their SAP S/4HANA adoption strategy. There is a lot of written about new functionalities coming with S4HANA and benefits it brings to business. However, many customers are still uncertain about the effort required to convert their existing SAP ERP system to SAP S/4HANA. They often ask questions such as: What does it mean to move to S4HANA? How long S4HANA conversion project will really take? How much business and IT resource are we going to need? How much it will cost? .

One of the prerequisites for producing a reasonable estimate is to understand the riskiest areas of the project. Therefore, in this blog I tried to list topics where the majority of customers experience difficulties during conversion.

You´ve probably already heard that conversion to SAP S/4HANA is not just a technical upgrade and that moving to S4HANA involves changes in functionality and business processes which might be significant. In general, we can say that the overall complexity of tasks in functional areas is much higher than in case of upgrades. Until now, the most of the functional changes have been made in the Finance area. If we look at other widely used functional components such as Sales and Distribution and MM, they are usually not so much work when compared to Finance components. Changes here are mainly related to data model simplification. Therefore, this blog post focuses on topics in Finance area.

So, without further ado, here are the most challenging functional areas when converting from SAP ERP to SAP S/4HANA:

Business Partner approach

This is the change which will have an impact on all SAP customers going through the conversion. In SAP S/4HANA, business partner master is a single point of entry and maintenance of customers and vendors. The business partner concept is not new and has been around for a relatively long time. It has been used before the arrival of S4HANA in SAP Business Suite applications such as FSCM Credit and Collection management, CRM SRM or industry solutions. As the business partner object offers several advantages over customer and vendor master records, it was decided to go for the business partner as a leading master data object. Some of the advantages include the possibility of a business partner to act in multiple roles (for instance as a customer and a vendor at the same time), the possibility to maintain multiple addresses and relationships. Although the decision was made to go forward with the business partner approach as a strategic functionality, it was not possible to get rid of customer and vendor master data model entirely. There are too many ERP applications working with traditional customers and vendor tables and it was not possible to redevelop them to work with business partner. Therefore, CVI framework is used to synchronize data from business partner data into customer and vendor master data tables. What does the switch to business partner mean for S4HANA conversion project?

  • Necessity to redesign some of the processes related to life cycle of customers and vendors.
  • Effort to configure new business partner object and CVI framework for synchronization between business partner and customers/vendors
  • Effort to migrate data. Existing customers and vendors should be replicated into new business partner master data. Before doing that, you need to cleanse customer and vendor master data (i.e. make sure that you have tax numbers in the right format, etc. Normally, you should also involve business into that. All these steps must be done before installation S4HANA itself.

If you have already implemented one of SAP Business Suite applications using business partner concept, good news: You will save yourself time and effort. In this situation, most of your customers, vendors or both were already replicated into business partners and you have your business partner and CVI configuration in place. Furthermore, your IT and business users are familiar with the concept as well.

 

Data inconsistencies

A critical part of any conversion to SAP S/4HANA is financial data migration. During this phase, transactional data is transformed into the new data model of the universal journal. To successfully migrate the existing transaction data, they must be clean and consistent. Unfortunately, no matter how well you manage the integrity of your data, chances are that you are going to have some errors in it. One of the most common errors includes differences between general ledger and subledgers (AA, MM, AR, AP..), between general ledger and document tables and inconsistencies in Asset accounting.

How does a company end up with inconsistent transactional data? Well, there are many reasons for that

  • Inconsistent updates made by custom developed programs and interfaces
  • Improper customizing or master data changes, for example, switching on/off open item management or line items display for GL accounts without following proper procedure, changing customizing without paying attention to warnings etc.
  • Direct updates to standard tables, for example via famous function code &sap_edit in transaction SE16N

In general, you are more likely to run into problems with inconsistent transactional data if your company has a large volume of data, a lot of custom code and do not reconcile data during the year-end close process

Given that data cleaning is an expensive process, it is very important to identify any data quality problem well in advance before your SAP S/4HANA conversion project starts. Otherwise, you might end up in the situation where a tremendous amount of time is needed to be spent on identification and cleansing of data inconsistencies during SAP S/4HANA conversion.

Financial data migration

So, you carried out the checks in your ECC and took your time to correct all identified inconsistencies. Now you install SAP S/4HANA, ran Software Update Manager and start executing financial data migration steps from IMG (Implementation Guide). Before actual migration of tables, there are mandatory transactional data consistency checks to be run. In addition, there is a consistency check after each data migration step. There is a good chance that you end up with error messages that were not detected during initial checks in the source SAP ERP system. All the sudden, you may find yourself in a situation when instead of one week, you originally planned, you spent 1 month trying to figure out what all these errors mean and how to correct them. Due to performance reasons, consistency checks available in SAP ERP system are different from mandatory consistency checks accessible after installation of SAP S/4HANA. These SAP S/4HANA checks are more advanced and able to detect data errors which slip through the standard set of checks in SAP ERP. Unfortunately, it means that some data inconsistencies might be uncovered only late in a project.

During financial data migration, you must have clean data, you have to perform customizing, run the migration of transactional and master data and verify the correctness of migrated data. All these activities need to be done during system downtime. Therefore, financial data migration is the most challenging phases of conversion to SAP S/4HANA.

Major changes of functionalities

With S4HANA there are some significant changes to the functional scope of SAP S/4HANA when compared to SAP ERP. In certain cases, things go so far as to replace the whole application components with new solutions. For instance, SAP Classic Cash and Liquidity Management has been made unavailable in SAP S/4HANA and replaced with newly developed solution SAP S/4HANA Cash Management. This is a completely new application which has to be deployed and configured. SD (FI/AR) Credit Management has been replaced with SAP Credit Management (technically, it is the same product as the solution known under name FSCM Credit Management). Again, if you want to use the solution you have to deploy it and configure it. Furthermore, you need to migrate old credit management master data and credit exposures. There is no possibility to use the legacy solution for credit management in SAPS/4HANA and you are forced to move to the new solution. For CO-OM and financial planning, customers are recommended to use SAP BPC (Business and Consolidation Planning) product. Here, you may continue using the old planning functionalities but then forget about any new FIORI analytical apps and other innovations. In all these cases, you should to get familiar with new components, implement them, you might need to migrate the existing data, train people and adapt business processes.

Also, for components which have not been replaced with new applications in SAP S/4HANA you can expect some extensive functionality changes. In Asset Accounting, it is the introduction of new asset accounting which impacts how you perform accounting for parallel valuations. Activation of new asset accounting is mandatory step to be performed before or as a part of conversion of Accounting to SAP S/4HANA. Apart from an impact on business processes and users, there are also some technical preconditions to make, which can potentially lead to high effort and additional costs. You might be even obliged to engage SAP SLO (System Landscape Optimization) service to introduce additional ledger to meet prerequisites for activation of new asset accounting (in the scenario when you have fiscal year variants with different start and end date assigned to ledgers used in Asset Accounting).

SAP FIORI as the new UI

SAP FIORI UX is the user interface of choice for SAP S/4HANA. The new web-based FIORI UI itself is a radical change. It looks completely different from the outdated SAP GUI interface and the whole concept has changed to role based. This, as with any major UI overhaul, can lead to resistance to change where some users might complain about new FIORI based interface hampering their productivity. In addition, technical configuration of FIORI UI can be a long and arduous process, especially if a company wishes switch to FIORI completely. Therefore, many companies opt for a phased approach where there is only limited FIORI adoption with conversion to SAP S/4HANA and with more apps planned for deployment after conversion.

Conclusion

As you can see, conversion to SAP S/4HANA requires careful planning and preparation. I hope I provided more clarity on the effort involved in SAP S/4HANA conversion projects and on what are the most common problem areas. Stay tuned for a more in-depth look at some of these topics.

In the meantime, I would like to hear from you. What other SAP S/4HANA conversion challenges can you add to this list that I may have not mentioned? Please share your thoughts and experiences in the comment area below.

Brought to you by the SAP S/4HANA RIG

To report this post you need to login first.

8 Comments

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

  1. Sarhan Polatates

    Hi Martin,

    Very open and detailed sum’up, thank you very much. I would like to add pricing condition table change to your list. KONV is replaced by the new table PRCD_ELEMENTS. All entries of KONV is needed to be transferred to new table as well. KONV still available for data declaration purposes. Also all custom codes should be handled and all KONV used codes should be replaced by PRCD_ELEMENTS or new API.

    My personal approach is to use green field option instead of brown field ( I mean system conversion).

    Cheers,

    Sarhan

    (1) 
  2. Sean D'Silva

     

    Hi Martin,

    A very nice blog highlighting the key challenge areas from Finance perspective during and after system conversion to S/4HANA. Will there be something similar also covering other areas (logistics, tools, cross components)?

    Best regards,

    Sean

    (0) 
  3. Michelle Crapo

    I love this blog. It highlights some of the changes coming. It will also help with where to focus my reading. Agree with Sean – more areas? I know we just keep asking for more!

    Michelle

    (0) 
  4. Darrel Zaulda

    Hi Martin,

    Thanks for your insights in this blog. I’d like to check whether you have encountered the challenge below.

    In SAP Note 2332030 – Conversion of accounting to SAP S/4HANA, there is a pdf attachment ‘Converting Your Accounting Components to SAP S/4HANA”. In page 15 under 5.2 Period-End Closing Activites, it states some important notes below. If a customer would like to go live on Jan 2020 for a system conversion from ECC, I infer that Jan-Dec 2019 financial statements have to be certified prior to the go live date. What if the financial statements would only be certified by April 2020? Can we still post audit adjustments to prior year special periods (FY 2019, periods 13-16) after go live?

    How about the implementation of subsequent document splitting, have you had any challenges?

    Thanks a lot!

     

    (0) 
    1. Martin Schmidt Post author

      Hi Darrel,

      You can post GL adjustments into previous years even after migration. However, as mentioned in the documentation, this is not possible for Asset Accounting.

      Martin

      (0) 
      1. Darrel Zaulda

        Hi Martin,

         

        Thanks for your response. It might be a challenge to get a certified FS where multiple countries are involved. In ECC, we have a t-code ABF1 to post adjustments but this doesn’t seem to be in line with S/4HANA design. Is this considered obsolete t-code or still available? Since there’s a limitation on reopening of fiscal year, is there a workaround for this or does SAP plan to have a program solely for post-migration adjustments?

         

        Regards,

        Darrel

         

         

        (0) 
        1. Martin Schmidt Post author

          Hi Darrel,

          T-code ABF1 is obsolete in S/4HANA. Primary purpose of this transaction has always been to adjust the GL balances to the totals in AA tables. These kind of differences between AA and GL should never occur in S4HANA. Any differences in ECC should be corrected before data migration.

          I am not aware of any plans for development of specific post migration adjustment program. The only option I see is to make the adjustments in the current year for any differences originating in prior fiscal years

          Kind regards,

          Martin

          (0) 

Leave a Reply