Shorter downtime in S/4 migration

We came across the challenge of excessive system downtime when migrating a large system to S/4 at a multinational company operating in the hydraulics and fluid systems and technology segment. The company has 50 subsidiaries in various countries, 14 production lines and nearly 10,000 employees. All the subsidiaries run on a single SAP ECC system with a MAXDB database of 9 TB.

The migration project is not just a conversion to a new version of the system with no changes. At the same time, without a separate subproject, the Business Partner (CVI) is implemented, two controlling areas in controlling are combined into one, and other changes forced by the new version of the system are introduced.

62 hours of downtime – instead of 342

As usual, it was not possible to pinpoint a single cause for the long system downtime during the first migration tests. The 342-hour test downtime resulted mainly from the size of the database, the type of database (MAXDB is not a speed demon, especially with more complex SQL queries), the need to transfer all data from the source system (full history, without deleting old data) and complex criteria for combining two controlling areas in SAP (on-the-fly data transformation). Since the system downtime measured during the test migration could not be accepted by the customer, we applied numerous measures to reduce it to the expected value – 62 hours.

At All-for-One Poland, we use a number of ways to reduce downtime during go-live. Some are simple, other require more effort, and there are some that can even duplicate the workload, but allow for significant downtime optimization.

Methods to reduce downtime
in a migration to S/4HANA

We usually start by verifying the system architecture, the elements that affect performance (e.g. memory size, speed of file transfer to/from SAP). Performance monitoring tools (most often CrystalBridge Monitoring) help us diagnose which parts need to be verified.

CrystalBridge Monitoring – a tool facilitating the identification of bottlenecks in a migration project

In addition to purely technical activities, we verify the data migration plan during the system downtime window, planning well the operations that can take place in parallel. In addition, we customize the standard content in the transformation tools (CrystalBridge Transformation Cockpit) according to the customer’s specific database and system. This saves more time – especially in the case of data that takes the longest to migrate.

In particularly difficult cases, we discuss with the customer the possibility of selecting data for migration to S/4HANA (e.g., no migration of data older than X years) and consider transferring some data outside the system downtime window. In the case of the described customer, we managed to reduce the downtime from initial 342 hours to 152 hours after further testing to ultimately achieve 62 hours of downtime expected by the customer in the GLS phase.

Migration tools

To migrate ECC systems to S/4HANA, All for One Group uses special migration tools (in this field, we are a partner of SNP Group and use its CrystalBridge product portfolio). This allows us not only to carry out migration projects faster and more predictably, but also to simultaneously implement the system changes required by the customer. In our projects, it is almost a standard practice to perform in SAP the implementation of a business partner’s functionality without a separate subproject, to switch in finance from reporting by accounts to reporting by parallel ledgers, adjust the chart of accounts, transform SAP organizational units (merging or splitting data), add new currencies, and to make many other minor transformations.

Migration projects, especially for larger SAP systems (>2TB of data, handling multiple countries from different parts of the world in one SAP system), are often not only an organizational challenge, but also a technical one. The length of downtime in such projects is just one factor that can determine the fate of a project.

By using transformation tools and a special approach in which the migration of an empty system to S/4HANA is separated from data migration and transformation, we have more room to maneuver. We can more easily implement system changes, including conversion to S/4, and significantly reduce system downtime during go-live. With our experience gathered from more than 100 S/4 migration projects, we can confidently claim that system downtime during the go-live phase will not be an obstacle in our migration project.

Director of the Digital Transformation Center, All for One Poland