IMPORTANT NOTE: This blog was not updated since Mid 2018, so it may be out of date. Some information still may be useful, but be careful as there may be new tools or insights on S4 System Conversions. Thanks for the contributions with updates!

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”)

3^rd 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:
  • 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

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),

Transports

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.