This post was originally published in December 2018 and updated with the latest information in October 2020.
In this blog series, we are looking at some of the challenges and risks that most commonly affect SAP S/4HANA conversion projects and how to mitigate them with the right selection of tools and approaches. In the previous blog Conversion to SAP S/4HANA On-Premise – what are the key problem areas (and what to do about them)? I tried to outline areas where customers usually experience difficulties when converting from SAP ERP to SAP S/4HANA. In the blog SAP S/4HANA- Consistency checks in Finance we went through consistency checks in the Preparation phase. In this blog, we will look into Finance data migration (sometimes referred to as Conversion of Accounting) in more detail. In general, this is the phase when transactional and some of the master data in finance applications are transformed into the new data model of the universal journal. Finance data migration is probably the hardest part of any conversion to SAP S/4HANA.
First of all, it is important to understand what is the position of Finance data migration in the overall SAP S/4HANA conversion. To answer this question, let’s quickly look at the SAP S/4HANA conversion process and see when exactly finance conversion comes into the picture.
In the picture below, you can see an overview of the entire SAP S/4HANA conversion process, with all involved phases and tools.
In the first step, you need to make sure that our source system fulfills the requirements on source OS version, source DB version, and patch level.
Then you run the SAP Maintenance Planner which is our SAP cloud-based tool for system landscape planning. The maintenance planner will check the status of business functions in your system and if add-ons installed on your system are compatible with SAP S/4HANA. If an add-on is not supported, the conversion would be stopped. If all checks are successful, the Maintenance planner generates a mandatory XML stack file for consumption by the Software Update Manager tool.
Then you run a detailed Simplification Item (SI) check which will analyze your system and give you a detailed overview of simplification items relevant to your system. In addition, it will run consistency checks (for configuration, master data, and some transactional data inconsistencies.
After that, you need to analyze your custom code to identify parts that need to be adapted to the SAP S/4HANA model. Please refer to the blog SAP S/4HANA System Conversion – Custom code adaptation process.
In parallel, you have to perform application-specific preparation activities, in Finance it means primarily various closing activities.
Once all preparations are complete, it is time to run the Software Update Manager (SUM). This is the tool that does the actual technical conversion with all the tasks such as database migration, software update, and application data migration in Logistics. Please check also the blog System Conversion to SAP S/4HANA: SUM is the tool. With the start of the SUM, you are entering the Realization phase, and it also the start of downtime.
In contrast to Logistics, the Finance data migration is not done during the SUM phase but must be executed from the Implementation Guide (IMG) configuration menu after finishing SUM. SUM tool only creates the necessary tables such as Universal Journal table ACDOCA and leaves them empty. One of the reasons why Finance data migration has not been integrated into SUM is that it requires certain preparation and customizing activities to be performed in the SAP S/4HANA system, before migration itself. Another reason might be that during Finance data migration inconsistencies need to be reported and handled. To execute Finance data migration, you need to go to IMG and trigger the activities manually. You need to run migration for each client separately.
Finance data migration has 3 stages. For each stage, all the migration activities and respective documentation are available in the IMG. You have to perform the activities, step by step, and in the right sequence.
Before you start with Finance data migration, you need to perform certain customizing for relevant application areas ( GL, AA, CO-PA, ML, House Bank accounts, CM, and Trade Finance). Some of the configurations are concerned with settings for the migration itself, some of the configurations are needed because of functional changes in SAP S/4HANA. To make the entire process easier, SAP provides programs for automatic migration of configuration.
Here, transactional data is transformed into the new data model of the universal journal. Please refer to SAP Note 2408083 – FAQ: Data Model of S/4HANA Finance data migration. In addition, some of the master data are migrated. For instance, secondary cost elements are merged into the G/L account master data, and house bank accounts are migrated to the new bank account master data.
Most of the migration activities are integrated into Start and Monitor transaction FINS_MIG_STATUS (further referred to as Migration Cockpit). This is the main transaction to carry out and monitor the results of data migration to the Universal Journal. The transaction will execute the data migration and ensures the right sequence of migration activities. It provides an overview of all performed migration runs, you can analyze errors and repeat and reset migration activities. There are still some activities that are not integrated into Migration Cockpit and need to be run separately, for example, migration of credit management and migration of financial documents.
There are also plans to deliver a migration tool for Joint Venture Accounting in S/4HANA 2020 FPS2, please refer to SAP Note 2941622 - Migration to S4HANA with Joint Venture Accounting running on ACDOCA
Once you finished and validated all data migration activities you set migration to completed. This will trigger the last checks for consistency and completeness of migration. If there are no relevant errors, the migration is completed and postings in the system are again allowed. Technically, this means the end of business downtime.
After the data migration and when you have set the data migration to complete, there are some more activities to do. For example, filling due date fields and offsetting GL account fields in relevant document tables or enrichment of balance carryforward additional dimensions from ML, Asset Accounting, etc. These activities do not necessarily have to be performed during downtime but, if possible, I would recommend conducting them before allowing users to use the system.
To improve the runtime of Finance data migration, the different jobs during the migration are performed in parallel using the so-called Mass Data Framework. It is a program designed to process the mass data in an efficient manner (technically, it is called in the Start and Monitor Data Migration cockpit, Initial depreciation calculation, Balance Enrichment, Credit management exposure migration but also for other mass transactions within Finance such as an initial load of data to Central Finance). In the first step, at the start of each migration activity, Mass Data Framework organizes the data to be processed into work packages. The size and number of packages are calculated automatically based on the various criteria which can slightly differ for each activity. In the second step, the mass data framework executes parallel processing of packages using either default or a predefined number of processes.
In the case of Finance data migration, you can set the number of jobs for each migration activity in the IMG activity “Set Number of Jobs for Activities in Mass Data Framework”. The optimum number of jobs depends on hardware resources and configuration. If you set up a number of parallel processes which is too low, the migration progress might be too slow. On the other hand, if migration is executed with too many parallel processes, it consumes too much memory which might lead to memory allocation issues and even short dumps.
At the moment, there is no direct way of how to calculate an optimum number of processes before migration. You need to determine the optimum number through testing. It is recommended to start, for example, with 10 jobs, start the respective migration activity, and monitor the performance. Based on the outcome, you can increase or decrease the number of jobs.
Some of the finance migration activities, especially for customizing and cleaning up data, can be addressed well in advance, even before starting the SAP S/4HANA conversion project. For instance, I recommend that you consider setting up separate “pre-projects” for:
During SAP S/4HANA conversion the entire system must be converted to SAP S/4HANA. SUM tool performs the conversion for all clients within the system. After that, Finance data migration must be executed for each client separately. There is no option to explicitly exclude a company code from Finance data migration. In a standard S/4HANA conversion scenario, all the company codes must be migrated.
Still, there might be valid reasons why you do not want to bring over data from certain company codes. For instance, company codes might be obsolete and no longer in use. Understandably, you do not want to spend time and effort on preparation tasks for such company codes. In addition, data may not be in decent shape and you do not want to spend time with an error message for irrelevant company codes before or during migration. Currently, there are only 2 options available for how to handle obsolete company codes:
In addition, there is a special scenario within SAP S/4HANA conversion which is called Company Code Specific Conversion to SAP S/4HANA. Its main purpose is to move company code data from the SAP ERP system into an already existing SAP S/4HANA system. However, this scenario is not generally available and requires paid service from SAP. It is done using SAP Landscape Transformation software and there is a number of additional prerequisites. For more detailed information, you may refer to SAP Note 2522155 – Company Code Specific Conversion to S/4HANA: Information.
It’s been a long time since the new G/L solution was introduced in Financial Accounting. The new G/L has brought many new functionalities such as the possibility to map parallel accounting via parallel ledgers, document splitting, real-time integration of CO into FI, and segment reporting. However, there are still many SAP customers who did not migrate to the new GL and are still using classic General Ledger. The good news is that New G/L is not a mandatory prerequisite for SAP S/4HANA conversion. In general, there is no need to run new G/L migration before the conversion of Accounting to SAP S/4HANA. However, you need to be aware that with SAP S/4HANA conversion you do not get all new G/L features automatically. What is not included is a transfer to parallel ledgers or activation of document splitting.
It means, that you might want to have a possibility to implement these functionalities after conversion. So what options do we have? The good news is that since SAP S/4HANA 1709 we have a solution for the subsequent introduction of document splitting. The tool is available at no extra charge.
In addition, since SAP S/4HANA 1610 we have a solution to add further accounting principles. In other words, to introduce additional non-leading ledger and migrate data from source ledger to newly introduced ledger. However, this tool will only help customers already using parallel ledgers functionality to introduce additional ledger/accounting principles. If you are still using the so-called account’s approach to map parallel accounting principles, it will not help you. Currently, there is no tool in SAP S/4HANA to migrate accounts approach to parallel ledgers. A solution is planned to be shipped in Q4/2021.
It is essential that Finance data migration receives proper attention during the planning of S/4HANA Conversion. Currently, finance data migration tasks are no integrated into SUM but must be performed manually from IMG. Sometimes, it creates a false impression that after technical conversion there are no major activities required. However, Conversion of Accounting to SAP S/4HANA can be more challenging in terms of effort and runtime than the SUM phase.
What are your thoughts on finance data migration? Let me know in the comments below!
Brought to you by the SAP S/4HANA RIG
In this blog series, we are looking at some of the challenges and risks that most commonly affect SAP S/4HANA conversion projects and how to mitigate them with the right selection of tools and approaches. In the previous blog Conversion to SAP S/4HANA On-Premise – what are the key problem areas (and what to do about them)? I tried to outline areas where customers usually experience difficulties when converting from SAP ERP to SAP S/4HANA. In the blog SAP S/4HANA- Consistency checks in Finance we went through consistency checks in the Preparation phase. In this blog, we will look into Finance data migration (sometimes referred to as Conversion of Accounting) in more detail. In general, this is the phase when transactional and some of the master data in finance applications are transformed into the new data model of the universal journal. Finance data migration is probably the hardest part of any conversion to SAP S/4HANA.
First of all, it is important to understand what is the position of Finance data migration in the overall SAP S/4HANA conversion. To answer this question, let’s quickly look at the SAP S/4HANA conversion process and see when exactly finance conversion comes into the picture.
When Finance data migration comes into play?
In the picture below, you can see an overview of the entire SAP S/4HANA conversion process, with all involved phases and tools.
In the first step, you need to make sure that our source system fulfills the requirements on source OS version, source DB version, and patch level.
Then you run the SAP Maintenance Planner which is our SAP cloud-based tool for system landscape planning. The maintenance planner will check the status of business functions in your system and if add-ons installed on your system are compatible with SAP S/4HANA. If an add-on is not supported, the conversion would be stopped. If all checks are successful, the Maintenance planner generates a mandatory XML stack file for consumption by the Software Update Manager tool.
Then you run a detailed Simplification Item (SI) check which will analyze your system and give you a detailed overview of simplification items relevant to your system. In addition, it will run consistency checks (for configuration, master data, and some transactional data inconsistencies.
After that, you need to analyze your custom code to identify parts that need to be adapted to the SAP S/4HANA model. Please refer to the blog SAP S/4HANA System Conversion – Custom code adaptation process.
In parallel, you have to perform application-specific preparation activities, in Finance it means primarily various closing activities.
Once all preparations are complete, it is time to run the Software Update Manager (SUM). This is the tool that does the actual technical conversion with all the tasks such as database migration, software update, and application data migration in Logistics. Please check also the blog System Conversion to SAP S/4HANA: SUM is the tool. With the start of the SUM, you are entering the Realization phase, and it also the start of downtime.
In contrast to Logistics, the Finance data migration is not done during the SUM phase but must be executed from the Implementation Guide (IMG) configuration menu after finishing SUM. SUM tool only creates the necessary tables such as Universal Journal table ACDOCA and leaves them empty. One of the reasons why Finance data migration has not been integrated into SUM is that it requires certain preparation and customizing activities to be performed in the SAP S/4HANA system, before migration itself. Another reason might be that during Finance data migration inconsistencies need to be reported and handled. To execute Finance data migration, you need to go to IMG and trigger the activities manually. You need to run migration for each client separately.
What are the main migration activities?
Finance data migration has 3 stages. For each stage, all the migration activities and respective documentation are available in the IMG. You have to perform the activities, step by step, and in the right sequence.
Preparation and Migration of Customizing
Before you start with Finance data migration, you need to perform certain customizing for relevant application areas ( GL, AA, CO-PA, ML, House Bank accounts, CM, and Trade Finance). Some of the configurations are concerned with settings for the migration itself, some of the configurations are needed because of functional changes in SAP S/4HANA. To make the entire process easier, SAP provides programs for automatic migration of configuration.
Data migration
Here, transactional data is transformed into the new data model of the universal journal. Please refer to SAP Note 2408083 – FAQ: Data Model of S/4HANA Finance data migration. In addition, some of the master data are migrated. For instance, secondary cost elements are merged into the G/L account master data, and house bank accounts are migrated to the new bank account master data.
Most of the migration activities are integrated into Start and Monitor transaction FINS_MIG_STATUS (further referred to as Migration Cockpit). This is the main transaction to carry out and monitor the results of data migration to the Universal Journal. The transaction will execute the data migration and ensures the right sequence of migration activities. It provides an overview of all performed migration runs, you can analyze errors and repeat and reset migration activities. There are still some activities that are not integrated into Migration Cockpit and need to be run separately, for example, migration of credit management and migration of financial documents.
There are also plans to deliver a migration tool for Joint Venture Accounting in S/4HANA 2020 FPS2, please refer to SAP Note 2941622 - Migration to S4HANA with Joint Venture Accounting running on ACDOCA
Once you finished and validated all data migration activities you set migration to completed. This will trigger the last checks for consistency and completeness of migration. If there are no relevant errors, the migration is completed and postings in the system are again allowed. Technically, this means the end of business downtime.
Activities after Migration
After the data migration and when you have set the data migration to complete, there are some more activities to do. For example, filling due date fields and offsetting GL account fields in relevant document tables or enrichment of balance carryforward additional dimensions from ML, Asset Accounting, etc. These activities do not necessarily have to be performed during downtime but, if possible, I would recommend conducting them before allowing users to use the system.
How long does it take to migrate?
To improve the runtime of Finance data migration, the different jobs during the migration are performed in parallel using the so-called Mass Data Framework. It is a program designed to process the mass data in an efficient manner (technically, it is called in the Start and Monitor Data Migration cockpit, Initial depreciation calculation, Balance Enrichment, Credit management exposure migration but also for other mass transactions within Finance such as an initial load of data to Central Finance). In the first step, at the start of each migration activity, Mass Data Framework organizes the data to be processed into work packages. The size and number of packages are calculated automatically based on the various criteria which can slightly differ for each activity. In the second step, the mass data framework executes parallel processing of packages using either default or a predefined number of processes.
In the case of Finance data migration, you can set the number of jobs for each migration activity in the IMG activity “Set Number of Jobs for Activities in Mass Data Framework”. The optimum number of jobs depends on hardware resources and configuration. If you set up a number of parallel processes which is too low, the migration progress might be too slow. On the other hand, if migration is executed with too many parallel processes, it consumes too much memory which might lead to memory allocation issues and even short dumps.
At the moment, there is no direct way of how to calculate an optimum number of processes before migration. You need to determine the optimum number through testing. It is recommended to start, for example, with 10 jobs, start the respective migration activity, and monitor the performance. Based on the outcome, you can increase or decrease the number of jobs.
What can be done in advance?
Some of the finance migration activities, especially for customizing and cleaning up data, can be addressed well in advance, even before starting the SAP S/4HANA conversion project. For instance, I recommend that you consider setting up separate “pre-projects” for:
- New Depreciation Engine activation (for those customers who have not activated EA-FIN extension yet)
- New Asset Accounting implementation
- Other required adaptations of customizing in Finance
- Clean-up of data inconsistencies
- Clean-up of vendor/customer master data and activation of CVI.
Exclude a company code from conversion?
During SAP S/4HANA conversion the entire system must be converted to SAP S/4HANA. SUM tool performs the conversion for all clients within the system. After that, Finance data migration must be executed for each client separately. There is no option to explicitly exclude a company code from Finance data migration. In a standard S/4HANA conversion scenario, all the company codes must be migrated.
Still, there might be valid reasons why you do not want to bring over data from certain company codes. For instance, company codes might be obsolete and no longer in use. Understandably, you do not want to spend time and effort on preparation tasks for such company codes. In addition, data may not be in decent shape and you do not want to spend time with an error message for irrelevant company codes before or during migration. Currently, there are only 2 options available for how to handle obsolete company codes:
- Archive – If you wish to completely exclude an existing company code from migration, the only option available is to fully archive the company code data before SAP S/4HANA conversion.
- Mark a company code as a template – If you want to disable some of the migration (pre) checks (in GL area), you can mark obsolete company codes as templates in transaction code FINSC_CO_CD_TEMPLATE. However, please note that this setting does not impact checks in other areas (FI-AA, etc.).
In addition, there is a special scenario within SAP S/4HANA conversion which is called Company Code Specific Conversion to SAP S/4HANA. Its main purpose is to move company code data from the SAP ERP system into an already existing SAP S/4HANA system. However, this scenario is not generally available and requires paid service from SAP. It is done using SAP Landscape Transformation software and there is a number of additional prerequisites. For more detailed information, you may refer to SAP Note 2522155 – Company Code Specific Conversion to S/4HANA: Information.
Migration and New G/L capabilities
It’s been a long time since the new G/L solution was introduced in Financial Accounting. The new G/L has brought many new functionalities such as the possibility to map parallel accounting via parallel ledgers, document splitting, real-time integration of CO into FI, and segment reporting. However, there are still many SAP customers who did not migrate to the new GL and are still using classic General Ledger. The good news is that New G/L is not a mandatory prerequisite for SAP S/4HANA conversion. In general, there is no need to run new G/L migration before the conversion of Accounting to SAP S/4HANA. However, you need to be aware that with SAP S/4HANA conversion you do not get all new G/L features automatically. What is not included is a transfer to parallel ledgers or activation of document splitting.
- Source ERP system is with classic G/L: If you are converting ERP with classic G/L, you will get only core New G/L functionality. Totals tables will be migrated into Universal Journal with leading ledger 0L activated. However, there is no transfer to parallel ledgers or activation of document splitting.
- Source ERP system with new G/L: If you are converting ERP with new G/L, in SAP S/4HANA you will get the new G/L functionality you had already activated in the source system. If you had document splitting or parallel ledgers in the source system, the functionality will be available also after conversion. If not, the conversion itself will not activate these functions.
It means, that you might want to have a possibility to implement these functionalities after conversion. So what options do we have? The good news is that since SAP S/4HANA 1709 we have a solution for the subsequent introduction of document splitting. The tool is available at no extra charge.
In addition, since SAP S/4HANA 1610 we have a solution to add further accounting principles. In other words, to introduce additional non-leading ledger and migrate data from source ledger to newly introduced ledger. However, this tool will only help customers already using parallel ledgers functionality to introduce additional ledger/accounting principles. If you are still using the so-called account’s approach to map parallel accounting principles, it will not help you. Currently, there is no tool in SAP S/4HANA to migrate accounts approach to parallel ledgers. A solution is planned to be shipped in Q4/2021.
Conclusion
It is essential that Finance data migration receives proper attention during the planning of S/4HANA Conversion. Currently, finance data migration tasks are no integrated into SUM but must be performed manually from IMG. Sometimes, it creates a false impression that after technical conversion there are no major activities required. However, Conversion of Accounting to SAP S/4HANA can be more challenging in terms of effort and runtime than the SUM phase.
What are your thoughts on finance data migration? Let me know in the comments below!
Brought to you by the SAP S/4HANA RIG
- SAP Managed Tags:
17 Comments
