We outline how to safely migrate data to S/4, what scenario to choose and what tools to use to reduce the amount of data.

Let’s look at different migration scenarios with a focus on data migration.

Greenfield. In this approach – implementing the system from scratch – we start using new S/4 functions and technologies without access to historical data. The focus is on adapting the system to business processes. An additional data migration project (open items, opening balances) is required to be able to use backward analyses.

Brownfield. This is the opposite approach. We do not change business processes. I transfer all the history and all the data to the new system. Migration is in fact a technical upgrade of the system to a new version and a faster database.

Bluefield. This approach combines the best of both of the above ones. We move to a new version of the system, and at the same time we flexibly improve processes and can selectively migrate historical data. We can perform the migration quickly – during the weekend (we start on Friday evening, finish it on Saturday evening and hand over the finished system to the customer so that they can test it on Sunday and provide it to users on Monday). This time can be further shortened in the “near zero downtime" approach. The time needed for migration depends on the size of the system and the complexity of the project. It is worth noting that we are not dependent on the fiscal year, we can perform the migration at any time.

Slimming down the system – why and how

The reasons for selecting historical data may vary. They can be divided into two main categories.

In some circumstances it is necessary. For example, in the case of the sale of a business unit, when a system is carved out for another entity, however without master data (it is especially necessary to protect sensitive data, such as financial data, addresses, account numbers, etc.). Another reason is the size of the system. A large amount of data makes it necessary  to plan the system downtime for the time of migration. Not every company can afford this, and then there are demands to get rid of unnecessary ballast and reduce the amount of transferred data.

The second category of reasons is the desire for optimization. Reducing the amount of data improves the efficiency of the system’s operation, thus speeding it up. Historical data is often unnecessary ballast that can be disposed of without harming the business. And finally – a smaller data volume makes it easier to implement other transformation scenarios in the same project as migration to S/4 (e.g., harmonization and consolidation of a chart of accounts or business partner).

In Bluefield, an in-house developed approach, we use the CrystalBridge platform offering a wide portfolio of tools that automate migration activities, including data migration.

Data migration in a typical S/4 migration project

The distinguishing feature of the Bluefield approach in migrating to S/4 is the creation of an empty copy of the system (without data), and then its conversion to S/4. This creates a golden copy of the system, ready to receive data. The next step is a test migration. It is followed by verification, user testing, patching and specification refinement. We perform several iterations of migration, testing and patching. This is a continuous process to catch all errors. Usually it has from 2 to 5 cycles, depending on the complexity of the project. The last cycle – a final rehearsal (to improve efficiency and draw up a detailed schedule) is followed by go-live.

In the analysis phase – even before accessing the customer’s system, we use System Scan, a tool that presents in an attractive visual form what the system contains, how individual data and processes are used.

CrystalBridge Transformation Cockpit allows us to select data based on the organizational structure or based on time.

The selection based on the organizational structure (for example, in FI – a company code, SD – a sales department, MM – a plant, CO – a controlling area) occurs in almost every type of an SAP transformation project. The second option – selection based on time (usually a fiscal year or a selected date) is possible for each SAP area, in a detailed (tabular) approach or in an aggregated (BAPI) approach.

What about the historical data?

And what happens to the old data? Several approaches are possible. Depending on the type of data and the customer’s decision, historical data can be archived 1:1 (we cooperate with a subcontractor that specializes in archiving transformations), we can store it in a data warehouse (in BW we can transform data with tools available in BW standard or use solutions provided by our company). Old data can also be simply deleted.

Automated tests

Automated tests are one of the tools that, after selective data migration, allows us to check whether we have actually packed into the target system the data that is needed for the proper operation of business processes. They can also help us check the configuration. The key advantages of automated tests are:

  • They are independent of the user interface;
  • They contain predefined test scenarios;
  • They allow for flexible selection of the scope of the tested data;
  • They enable the test log to be tracked;
  • The preparation of customer-specific test objects does not require much effort;
  • They do not require additional equipment.

Another tool is Data Consistency Verification. It is used to check connections between individual tables and fields and to verify data integrity. The solution provides:

  • Technical verification of data integrity of the entire system;
  • Fully automatic control;
  • Only the evaluation of identified inconsistencies and their inclusion in the implementation must be done manually by the user;
  • Three types of verification: foreign keys, domain values and fixed domain values.

And finally, good advice. After moving to a new place, it’s a good idea to keep master data organized. SAP offers a dedicated tool to maintain data integrity – Master Data Governance. All for One also offers its customers support in this area. 

Case study #1: Automotive industry

Selective data migration

Already in the source system, the customer had a fairly clean division of the system by organizational unit. The business was clearly divided into two areas: cars and trucks. For finance, it was a division by company code, for sales – a sales department, for controlling – a controlling area, and for purchasing – a plant. Only the purchasing department was problematic. We handled it in such a way that we did not delete all the data upon agreement with the customer. The project was unusual in that the customer decided to duplicate their system (clone and delete), i.e. make a copy of the client and then delete unnecessary data from each system separately. This approach allowed the customer to work on both systems in parallel all the time, and data deletion could be done any weekend.


Case study #2: Insurance industry

Performance improvement

In the project of migration to S/4, we combined the customer’s two source systems (one for property insurance and the other for life insurance). The challenge was the size of the system and its performance. Single tables had several terabytes of data and over a billion records. The customer’s expectation was to transfer all data. Only in the FI area we had time-based selection. We only migrated the last 2 years because the FI area was not crucial for the customer. The selection allowed us to reduce the time needed for financial conversion to several minutes. The remaining time from the 48-hour time window was used to migrate data from the other functional areas of the system. The customer had to provide adequate hardware so that we could meet the deadline.


Case study 3#: Education

Data harmonization

A project for a university in Saudi Arabia. The customer was already using Business Partners functions in the source system, but data cleaning had not been performed and a significant portion of over 100,000 records was duplicated. All for One was tasked with cleaning and harmonizing the data during the migration to S/4HANA. Software for automatic data analysis, searching for duplicates and identifying the so-called golden record was used based on preset conditions. The result – an S/4HANA system with correct master data as a source for reliable reporting.