An SAP migration can be successful if, and only if, the information around the scope, requirements, business rules, and transformation rules are detailed and accurate to the point. Based on our experience, we always say that the “devil is in the detail” especially in a project that involves migrating the data to SAP.

In our previous post about SAP migration we described a generic approach we have developed for an SAP migration with our migration factory. Here, we are going to talk about a specific project wherein we helped the customer migrate their data residing predominantly in legacy systems, to SAP. This customer is a renowned automobile parts manufacturing organization with their manufacturing plants present across the globe. What we are going to see in this post (and in the subsequent series) is how we migrated their data from QAD to SAP (S/4 HANA). This post will give a high-level overview of the approach we followed. In the subsequent posts we will explain each part of the migration in-depth.

Identification

The identification phase from a Data Migration perspective indicates that the alignment between the business users and SAP consultants has already taken place with the outcome being the list of objects that are in scope for migration.

The following are the SAP Business processes that were in scope. All the identified migration objects were attributed to one of these business processes:

  • PTP – Procurement to Pay
  • DTS – Demand to Supply
  • MTS – Maintain to Settle
  • OTC – Order to Cash
  • FTM – Finance to Manage

We as the data migration team worked closely with the SAP consultants to ensure that the business rules and mapping rules matched the configuration in SAP. Our migration toolset consisted of Talend Data Integration, along with data quality tools such as Talend Data Stewardship, encapsulated by an audit framework.

Approach

We selected 15% of all data for the initial migration (the “test run”). We ensured that the migration for this subset of the data was carried out across all the business processes starting from PTP to FTM. For example, first we identified a set of “assembled” parts (such as an engine radiator) and “ready-made” parts (such as a screw). We then migrated these parts to the Material Master in SAP. When the parts were migrated, we focused on the migration of data to the dependent functionality/processes such as bill of materials, purchase orders, routing, maintenance plan, asset depreciation, etc.

Even though we had only 15% of data, we had covered the data migration to all business processes so there would be enough to mock a Go-Live scenario with SAP, replacing the existing system for just a day.

In summary, we followed the following approach for the migration:

  1. Extract data from source
  2. Transform the data based on mapping rules
  3. Store raw and transformed data in the staging database
  4. Expose transformed data to the Data Stewardship Console
    1. The transformed data also includes the formatting of the data as supported by SAP
    2. The stewards along with their team validate the data
    3. Stewards mark which set of data needs to be migrated
  5. The validated data from the Data Stewardship Console is updated in the staging database (after approval by the business users)
  6. The BAPI call to SAP is triggered to load the data
    1. “IDoc” requests are performed for certain migration objects
  7. The response from SAP (success or failure) is stored in the staging database
  8. The failed records are validated by business users, data migration team, or SAP consultants to determine the root cause of the failure
    1. This further invokes a change or an addition to the set of transformation rules
    2. The failed records are re-triggered for migration based on the findings above
  9. There was an Audit database that holds the details of all the records that are in scope for the migration, along with the migration status to make sure all records have been processed successfully.

This is how we approached the migration scenario and we were able to successfully migrate our customer’s data to SAP. In the upcoming posts we will focus on each of the business processes mentioned above, starting with Procurement to Purchase.

SAP Talend