S/4HANA System Conversion

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

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.

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

Consist 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 determining by doing a
migration practice 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:
i. fills some fields of BSEG with information from BKPF.
ii. fills some fields of COEP with information of COBK and
OBJNR.
iii. filling of profit center into CO line items
iv. filling of company code data into old CO line items
v. 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
conversation, this step ensures that all existing PO records
are converted into the material ledger 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 builds
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:

o Complete Migration:
1. Final reconciliation after migration: SAP
recommends some reports to do this migration.
2. Set Migration to “Completed” –> Users can post
again.
o 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 a specific set of steps (you can check
another blog I wrote on this).