Skip to Content
Product Information
Author's profile photo Martin Schmidt

Conversion to SAP S/4HANA On-Premise – what are the key problem areas (and what to do about them)?

This post was originally published in March 2018 and updated with the latest information in November 2020.

With the end of mainstream maintenance for SAP ERP 6.0 in 2027, existing SAP customers should start preparing their SAP S/4HANA adoption strategy. In this blog, I will try to highlight the particular risks and challenges that most commonly affect the system conversion projects and outline what you can do about them. We will discuss how to meet them with the right selection of tools, services, and approaches.

Transition paths

There are three options of how to make a transition to SAP S/4HANA possible: System conversion, New Implementation, or System Landscape Transformation. The choice between these three transition paths depends on several criteria.

System Conversion scenario (brownfield approach) – you take your existing SAP ERP system and convert it to S/4HANA using tools such as Software Update Manager, data migration programs in Finance, etc. There are several advantages of using system conversion over a greenfield approach. In general, the system conversion tends to be faster and a less disruptive way of moving to SAP S/4HANA for existing SAP customers.

New Implementation scenario (greenfield approach) – you create and configure a new system from scratch and import data from the old SAP ERP data using data migration tools such as SAP S/4HANA migration cockpit, SAP BO Data Services, etc.

System Landscape transformation – it is a combination of approaches above and used for consolidation of multiple systems or selective migration (for example, only selected company codes).

If you are interested to know more about transition scenarios and what factors you should consider when making the choice, please refer to the blog How to find my path to SAP S/4HANA – Understand the available transition options.


System conversion challenges

There is a lot of writing about new functionalities coming with SAP S/4HANA and the benefits it brings to the 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 SAP S/4HANA? How long does an SAP S/4HANA conversion project take? How many business and IT resources are we going to need? How much will it 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 SAP S/4HANA 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 the case of upgrades. Until now, 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 that will have an impact on all SAP customers going through the conversion. In SAP S/4HANA, a 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 S/4HANA 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 the 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 partners. Therefore, the 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 a S/4HANA conversion project?

  • The necessity to redesign some of the processes related to the life cycle of customers and vendors.
  • An effort to configure new business partner object and CVI framework for synchronization between the business partner and customers/vendors
  • An 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 in that. All these steps must be done before the installation of S4HANA itself.

If you have already implemented one of the SAP Business Suite applications using the 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.

To make the whole process of moving to business partners easier, colleagues prepared a comprehensive  SAP S/4HANA Cookbook for Customer/Vendor Integration.


Data inconsistencies

A critical part of any conversion to SAP S/4HANA is the 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 the general ledger and sub-ledgers (AA, MM, AR, AP..), between the 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, a history of data conversion projects (such as new GL migration, local currency conversion), 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 a situation where a tremendous amount of time is needed to be spent on the identification and cleansing of data inconsistencies during SAP S/4HANA conversion.

In my next blog, I will write more about available tools and checks. You may also refer to the blog SAP S/4HANA Simplification Item Check – How to do it right.

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 the IMG (Implementation Guide). Before the 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. In the past, there was a good chance that you end up with error messages that were not detected during initial checks in the source SAP ERP system.  Due to performance reasons, consistency checks available in the SAP ERP system used  to be different from mandatory consistency checks accessible after the installation of SAP S/4HANA. The situation has significantly improved with new check programs introduced in SAP ERP in area of General Ledger and Asset Accounting.

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 phase of conversion to SAP S/4HANA.

Interested to learn more about finance data migration? Please see my blogs:

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 the newly developed solution SAP S/4HANA Cash Management. This is a completely new application that 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 the 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 the SAP Analytics Cloud solution. 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 get familiar with new components, implement them, you might need to migrate the existing data, train people, and adapt business processes.

Also, for components that 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 a mandatory step to be performed before or as a part of the 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 dates assigned to ledgers used in Asset Accounting).

For a description of incompatible or disruptive changes of functionality, please go to the latest Simplification Item List (PDF) or Simplification Item Catalog (web-based).

For more information about these tools, please read the blog Simplification Item Catalog, Simplification Item Check and SAP Readiness Check for SAP S/4HANA.


SAP FIORI is 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 the new FIORI-based interface hampering their productivity. In addition, the technical configuration of FIORI UI can be a long and arduous process, especially if a company wishes to 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.

For detailed information on how to start with FIORI and how to operate it in a S/4HANA environment, please refer to SAP FIORI for S/4HANA wiki.


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

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sarhan Polatates
      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).



      Author's profile photo Sean D'Silva
      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,


      Author's profile photo Michelle Crapo
      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!


      Author's profile photo Darrel Zaulda
      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!


      Author's profile photo Martin Schmidt
      Martin Schmidt
      Blog 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.


      Author's profile photo Darrel Zaulda
      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?






      Author's profile photo Martin Schmidt
      Martin Schmidt
      Blog 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,


      Author's profile photo Darrel Zaulda
      Darrel Zaulda

      Hi Martin,


      Thanks a lot for your valuable inputs, I appreciate them.



      Author's profile photo vishwanath vedula
      vishwanath vedula


      Author's profile photo Svelatna Yancheva
      Svelatna Yancheva

      Hi Martin,

      Thanks for sharing this useful information!

      A question , I assume there is downtime for the business activities while Conversion to SAP S/4HANA is running: new customizing , migration of master data, new functionalities, etc...

      Can you advise how many days is the downtime, which would be critical for the business?

      Thanks and regards,


      Author's profile photo Martin Schmidt
      Martin Schmidt
      Blog Post Author

      Hi Svetlana,

      Sorry I noticed your question only now.

      Downtime depends largely on data volume and hardware configuration. It comprises 2 main phases - running technical conversion via SUM (software update manager). This includes migration of DB to HANA, installation of software components and migration of application data in Logistics domain. Here, overall db size and especially data volume in logistics tables could provide some hints regarding downtime. The second main activity is financial data migration. For financial data migration, number of records in tables such as BSEG, COEP,  FAGLFLEXA  can give you a good indication of runtime. Based on my experience, my rough estimate would be that 1 billion of records in BSEG/COEP would translate into 22-28 hours of financial migration runtime.

      For DB size larger than several terabytes I would recommend to look at  Down Time Optimized conversion approach (SAP Note 2293733) and near zero downtime (SAP Note 2309893).

      Kind regards,


      Author's profile photo Svelatna Yancheva
      Svelatna Yancheva

      Thank you!


      Author's profile photo GIANLUCA TACCONE

      Hi Martin,

      Nice and instructive Blog, thanks a lot for sharing.

      Since you asked,

      • Public Sector Customers that have still implemented the Former Budget, they need to migrate or to the BCS (Budget Control System) before of starting a conversion to S/4 Hana (OSS 2226048)
      • According to simplification list Real Estate Customers using classical real estate need to migrate to flexible real estate before of starting a conversion to S/4 Hana



      Author's profile photo Silvia Recanatesi
      Silvia Recanatesi

      Dear all,

      I'm facing an S4hana upgrade from release 1709/ SP01 to 1909/ SP03.

      In order to test new transaction FAA_CMP, I'm trying to re-open the last period already closed in the previous release, but I'm not able to.

      Also after an upgrade is it not possible to re-open a period already closed, as after an ECC to S4HANA migration?

      I thank you all for any hint or confirmation you can provide.