Many of our customers are currently migrating from SAP R/3 or SAP ECC to the newer SAP S/4 HANA. But how does such a migration project usually work? What are the options for migrating a system? Let’s look at these questions in detail.
Creating the foundations
Regardless of the type and manufacturer of the software, a migration project should proceed as follows:
The first step is to work out which processes run in the software to be migrated and how the software implements these processes. This also requires an evaluation of the relevant data and rights. A first data record for example of a department can then be extracted.
At the same time, a test system with the new software should be set up. The test system is set up and configured as the production system. Once both steps have been completed the sample data can be loaded into the test system. Alternatively, data migration can also take place via an interface. The data migration test is part of a so-called integration and interface test that checks the interfaces to other systems in addition to the data migration.
No successful migration without testing
If all these tests are successful the first user test begins. Otherwise, the reason for the error must be found and corrected. During the user test, some pilot users start by testing the software itself. The pilot users try out the software, run through the mapped and possibly configured processes and test the various functionalities. The user tests usually take one month. On the basis of these extensive tests, which are usually conducted by only minimally trained users, the user-friendliness, susceptibility to errors and resilience of the system to be introduced are tested. This means that the system is tested to see if it works as it should.
If the integration and user tests are successful, the next step is the live or productive switching of the system. There are several strategies for the so-called “go-live” of a software:
Strategy 1: Big Bang
The first is called “Big Bang” and means that on a certain date all processes will run via the new system. There are often problems with this strategy, as the system was previously only used by a few users who produced smaller amounts of data and did not test all the functionalities of the software. The system is now unable to handle the drastically increasing number of users, data and processes. In addition, faulty configurations and functionalities can lead to errors or even system crashes.
Strategy 2: Parallel operation
The second variant is the initial parallel operation of the two systems. Here the main system is divided into smaller “subsystems” and their work is supported by the new system. For example, the division can be made in accordance with the departments. With this migration type, the data exchange between the old and new systems must be guaranteed so that cross-departmental processes can also be executed.
|Big Bang||Parallel operation|
|Migration process||All on one date||Step by step|
|Result/Success||Immediately visible||Gradually visible (e.g. department by department)|
|Error effects||New system cannot be used||Failure of a migration step|
Finally, for both migration strategies, a review of the process flows and transactions in the new system must be carried out to ensure that the processes are correctly implemented and executed.
The process flow of a migration project looks as follows:
1. Development of process flows and implementation
2. Setting up a test system
3. Performing integration tests / interface tests
4. Performing user tests (approx. 1 month)
6. Re-examination of the process sequences
A migration project is, therefore, a complex endeavor that requires a lot of resources, know-how and time. The success of such a project is difficult to estimate due to the high effort involved and is influenced by many decisions. Careful planning, regular tests, and checks can increase and ensure the success of a migration project.