Skip to Content
Technical Articles
Author's profile photo Saumitra Deshmukh

What is the Combined Staging Table Approach for the New Fiori App Migration Cockpit in SAP S/4HANA Cloud (Cloud Edition 2008)?

Hi All,

Note: This blogpost has been written keeping SAP S/4HANA Cloud 2008 release developments in mind for the Migration Cockpit. Features/Functions might have been added/changed depending on the latest release applicable.

As you might have seen, with the Cloud Release 2008 the Migration Cockpit has changed with respect to the Interface, Handling and the Approach mechanism. Talking about the changes, we will try to cover the new interface & Handling in the upcoming blogs, but in this one, I will try to explain what the new Combined Staging Table approach with Cloud Edition 2008 is.

Having 2 scope items already applicable for Data Migration Approaches in S/4HANA Cloud – Data Migration to SAP S/4HANA from File (‏BH5‏) & Data Migration to SAP S/4HANA from Staging (‏2Q2‏) , there might be slight confusions from the consumption point of view on what the combined Staging Table Approach is.

You might also have questions like –

  • If SAP S/4HANA Cloud has a single Staging Table Approach with CE 2008 into the Migration Cockpit, is the File/XML Template Approach still applicable with the Migration Cockpit
  • As we do not see the dropdown option for File based & Staging Approach anymore in the new interface, does this mean that the Best Practices BH5 & 2Q2 are no more relevant
  • The dropdown shows Local & Remote Database Connection as options, does this mean I can configure my native HANA DB to transfer data into the Staging Tables

So just to clear out above some such confusions, I will try to address the queries in the below explanation.

First things first -> Why a combined approach Migrate Data Using Staging Tables as compared to the earlier mechanism?

Before we start explaining more about the Why part, one thing which goes needless to mention is that you should have at least once been through the Tool Documentation & Introduction Slide Deck which should provide you a fair understanding of what new changes have come for you with CE2008.

Now addressing the main motif of the Why part, let us see why SAP S/4HANA Cloud has come with a New Staging Table approach for Migration Approach.

Previously with two approaches available in the migration cockpit viz. File Based Approach & Staging Table Approach, you needed to decide whether you go for files or for staging tables – meaning 2 different projects, each of them with mapping rules.

With the recent unification of a single staging table approach, Customer/Partners do not have to wonder about two different approaches but can use the 2 possibilities within 1 project This provides a single and consistent approach of transferring data from Staging Tables into the Target S/4HANA Cloud system. Also, an added advantage is that this mechanism gives a coherent user experience in terms of monitoring and tracking the data records (instances) in a steady manner.

What this means?

This means that irrespective of the source of your data, may it be via the XML templates or may it be populating the staging tables directly either with SAP or 3rd party tools, all your incoming data will reside only in the Staging Tables before it is actually migrated into S/4HANA Cloud System.

The staging tables can be inside the SAP S/4HANA Cloud System – we call this local SAP S/4HANA Database schema. Using only XML template files, this is an easy way – you do not have to care about the database connection yourself. In this scenario you are not able to populate the staging tables directly – meaning you do not have access on database level.

If Customer/Partners opt for the second choice “Remote SAP HANA Database” this is exactly what is described in  Data Migration to SAP S/4HANA from Staging (‏2Q2‏). Basically, when Customer/Partners chooses this Scope Item, they have to establish a DBaaS on SCP and the respective communication arrangement where then in a dedicated schema Staging Tables will be created (details all described in 2Q2 document)

To elaborate it further, the Staging Table is common, and you just need to confirm on the location of the Staging Table Schema DB. With the two options you have in the Cockpit, you can select the location of the DB Schema for the Staging Tables – either Local or the Remote Database. This translates into either you using the XML templates (Data Migration to SAP S/4HANA from File (‏BH5‏)) to transfer the data into the Staging Tables in the Local DB Schema or you choose the Staging Tables on the Remote Database (Data Migration to SAP S/4HANA from Staging (‏2Q2‏)) which is nothing but your SCP account where you have a DBaaS located for connection it further to the S/4HANA Cloud system. Hence now, the Customer/Partner can choose the remote database to populate directly the staging tables AND also use XML files.

XML files is only kind of container that help to fill the staging tables. Henceforth all data is stored in the Staging Tables consistently. To show you how it looks like visually, you can check the below figures which explain the placement of the Staging Table area in the respective Databases for the option you choose

Local SAP S/4HANA Database Schema:

Here on selecting the Local SAP S/4HANA Database Schema as the Database Connection, it is understood that the Staging Tables will be created in the residing in the S/4HANA Cloud system Database schema. Users will fill these Staging tables via the pre-delivered XML templates which are specifically adjusted to easily populate the Staging Tables. The data after you Prepare >> Complete Mapping Tasks >> Simulate will be transferred into the Target DB Tables in the Migrate step via the APIs as shown above. The status is immediately updated into the staging tables for monitoring & tracking purposes.

This directly links with the existing Best Practice – Data Migration to SAP S/4HANA from File (‏BH5‏) and the Customer/Partner is not required to request activation or additional setup as this is delivered with the default licensing.

 Remote SAP HANA Database Schema (KBA 2733253)

Similarly, when Customer/Partner choose to have an out-of-box DB schema to populate Staging Tables essentially on SAP Cloud Platform, they can choose the Remote SAP HANA Database Schema. Here it is mandatory that Customer/Partners have a SCP subscription for Database as a Service (DBaaS) and have setup the communication between the Staging Area and the Target S/4HANA Cloud System so that data can be transferred from the SCP DBaaS to the S/4HANA Cloud Target system. Also, to note that, this situation is applicable if the Customer/Partner chooses extraction tools from their Legacy systems to populate the Staging Area in the SCP directly. KBA 2733253 addresses general FAQs w.r.t the Staging Approach when custom opts for a remote DB schema. This directly links with the existing Best Practice – Data Migration to SAP S/4HANA from Staging (‏2Q2‏) and Customer/Partners need to get this scope item activated in case they want to adopt the method.

Hope this helps explain the New Combined Staging Approach.

Please feel free to submit your questions in the community in case you need more clarifications on this topic.



Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.