One area where SAP S/4HANA Cloud (SAP S/4HC) implementations are different than OnPremise implementations is in the area of data migration.  Customers and partners who have previously implemented OnPremise versions of SAP software are often used to repeating the same data loads again and again.  This approach of loading the same set of file(s) repeatedly is done in order to perfect the data quality and optimize the loads from a performance perspective.  Technically, this is achieved either  by restoring the SAP system to a state just before the test execution cycle or by refreshing the test client from a golden client.  However, these concepts of client and/or system refresh do not exist in SAP S/4HC and different strategies are used to successfully test data migrations before production loads.

As a quick refresher, SAP enables data migration to SAP S/4HC through the use of the data migration cockpit tool.  SAP Note 2538700 is the master FAQ note for migrating data using the SAP S/4HANA Migration Cockpit for SAP S/4HANA Cloud.  The note is updated frequently and contains a lot of valuable information on data migration topics and templates.  I highly recommend checking for updates on this note as this is an area that is rapidly evolving and new features are continuously rolled out.

Another option that is sometimes used by customers in some scenarios where the data migration cockpit templates may not meet their requirements is to load data through allowlisted APIs from programs developed on BTP, such as an iFlow in Cloud Integration loading data from another system or flat file.

This blog will outline some of the tips/strategies that customers have used to successfully test data migrations in lieu of being able to refresh clients and/or restore systems.

There are two types of data for migrations-master data and transactional data.  Typically, the challenges are faced with master data because you cannot keep loading the same datasets over and over due to primary key constraints (i.e. product number, business partner number, etc).  Transactional data generates a new number on documentation creation (i.e. sales order number) and can usually be loaded multiple times although there are some considerations here as well (for example, legacy document number no longer being unique in SAP S/4HC).

The first key point before outlining some options is that prior to loading any data into S/4HC, both the IT and Business teams should review the data in the migration templates to make sure it is complete and spot check it for accuracy. This will help to identify some issues that can be corrected prior to system loading and is an often overlooked step.  This will save you the unfortunately circumstance of loading in data that is not correct and now needs to be corrected in the system but cannot be loaded again.

Here are some approaches for data migration in SAP S/4HC that customers have used to date:

1. Incremental loading of data by starting small and growing the datasets with each subsequent load.  In this approach, the data is migrated in small increments until confidence levels grow for a large volume test.  For example, load 1 BP, then another 5, then 15, 25, 50, etc. until you load in a large set of several thousand.  After each incremental data load is completed, you should review the data and process a few transactions through the system to make sure nothing was missed and the data is accurate.  Then, make any corrections required and load the next incremental data set.
2. Use DEV system to test data loads before the TEST system.  If you have a 3 system landscape for SAP S/4HANA Cloud, you can tune your data loads in the DEV system before testing in the TEST system.  This will give you an opportunity to work out any data quality issues in advance of the final tests in the TEST system.
3. Use a prefix on the master data.  In this approach, for each load a prefix is added to the data with 1-2 characters that don’t already exist for master data so you can exclude it if required when using apps in the system.  If there is a lot of linked data, this approach would require a little bit of extra work to Find and Replace in each template that has linked data like Customers to Sales Pricing and Sales Orders. The advantage to this approach is that it gives you capability to load in the same datasets. However, one drawback to this approach is that you end up with a lot of junk data in your TEST system.

Once you are live on SAP S/4HC, the SAP S/4HANA Cloud Test Data Refresh (TDR) service can be an option to refresh your TEST tenant with master and transactional data from production.  This can support future waves or project phases including data migration testing.  Please refer to SAP Note 3070606 TDR restrictions and the latest information.

In conjunction with TDR, another feature that is currently on the S/4HC roadmap is the concept of parallel project lines.  This is another configuration path (an additional client for those familiar with SAP OnPremise systems).  This mechanism will support branching from the main project line to implement and test (including data migration testing) the next wave of a rollout without impacting the production support path.  The parallel project functionality will allow project changes to be merged back into the main project at some future point in time.

Although the S/4HC data migration approach is slightly different than what traditional OnPremise SAP customers & partners are used to from a data migration testing perspective, many customers have successfully gone live using the data migration approaches outlined in this blog.

Feel free to post your S/4HC data migration experiences in the comments to share with others.

Marty