S/4 migration - the path leads via decommissioned legacy systems
The time will come by 2025 at the latest. That is when maintenance for older SAP releases will come to an end. By that time, existing SAP customers should have switched to S/4 Hana.
The corresponding announcement from Walldorf came in 2015. The number of those who have already migrated is likely to remain in the single-digit percentage range in 2018. And the number of existing SAP customers who can migrate to SAP S/4 Hana using the standard conversion tools offered is likely to be correspondingly low. While these are excellent, they can only leverage their advantages as long as customers have remained in the SAP standard.
In view of an estimated 50,000 customers worldwide in the ERP sector alone - of which around 20 percent are in Germany, Austria and Switzerland - this finding poses a problem.
After all, it is common knowledge that the vast majority of SAP users have invested a great deal of time and money in the company-specific adaptation of their SAP systems in order to meet the last requirements in every single area of the company.
This reflects not least the massive increase in the penetration of SAP solutions in companies, especially if you compare the situation with that during the last major release upgrade from SAP R/2 to SAP R/3.
Consequently, it is no exaggeration to speak of a mammoth task to transfer the data contained in the SAP ERP legacy systems to the new software world.
Cost trap migration: lack of experts
In the enterprise environment, it can be assumed that data migration will require around 5,000 man-days. Even if we assume an average of 2,000 man-days per project, this would result in a capacity requirement of 20 million man-days in the DACH market by 2025, or around 3.2 million per year.
Even if all of the estimated 2,000 data migration experts in the German-speaking countries were to work 365 days a year, there would only be capacity for 730,000 man-days annually.
Including vacation and other downtime, five times as many migration experts would be needed as are actually available to complete the projects by 2025.
Since this is impossible according to Adam Riese, there are only other options: legacy systems continue to operate despite the end of maintenance and exist side by side with the new software generation, which is exclusively filled with new data.
This inevitably leads to a significant increase in both investment and operational costs for setting up the new SAP S/4 Hana landscape and continuing to operate the existing systems. Only a few companies are likely to be able and willing to make this additional effort.
The continued operation of the systems falling out of maintenance is likely to be unavoidable in this scenario even if parts of the data were transferred to the new software world by 2025.
This is because even in the case of a partial migration, the data is mapped to the new structures. Economic and tax auditors will therefore not recognize that the migrated data is the original. Who wanted to take responsibility for this?
Both scenarios are unsatisfactory - not only for those existing SAP customers who have their sights set on the end of maintenance in 2025, but also for those who want to make S/4 Hana the basis of their digitization strategy.
The latter in particular cannot and do not want to see their own schedule for switching to the new software generation jeopardized due to a lack of market resources.
To avoid the cost and compliance trap, there is only one solution: The data from the existing SAP systems must be completely removed without changing anything in its structure and stored in an audit-proof manner on a neutral platform.
Admittedly, the data, but also the unstructured information such as business documents, must be stored together with their business context, so it makes more sense to talk about historicizing legacy information rather than archiving it.
Data: Less is more
On the one hand, this approach allows the legacy systems to be shut down completely afterwards, thereby achieving massive savings in operating costs. The savings potential in this respect is typically 60 to 80 percent compared with continuing to operate the legacy systems.
In addition, however, this approach enables cost and time savings during data migration. This is because such a platform allows the targeted selection of the data that is to be transferred to the new SAP world and adapted to its structures.
Experience shows that this can avoid up to 75 percent of the migration effort and the associated costs. This is because the 80/20 rule also proves to be valid for partial data migration: on average, only one-fifth of the data stock needs to be transferred to the new system, while the remaining four-fifths remain on the neutral platform.
Anyone who has any doubts about such a large reduction need only consider how many duplicates have accumulated in the legacy systems over the years. After all, the number of SAP systems in use and the associated databases has grown continuously.
This is precisely why there has been an increase in system consolidation and centralization projects in recent years. These companies have seized the opportunity not only to reduce their data inventory by deleting duplicates, but also to clean up their master data.
Basically, the release upgrade to SAP S/4 Hana is the ideal opportunity to transfer only master data that is as perfect as possible. The less that needs to be migrated to the new software generation, the easier the cleanup.
Efficiency through decommissioned legacy systems
With a platform for the historization and migration of legacy data and documents, exactly that is possible. What's more: Access to all historized information remains unrestricted.
This has two decisive advantages: Data and documents can be integrated into ongoing business processes, even if their migration is not worthwhile. For example, service employees in plant engineering can access historicized construction plans or maintenance reports via tablet and use them for their current work.
On the other hand, the companies have full legal security. Since the migrated information is also stored on the platform in the original format and structure in an audit-proof manner, internal and external auditors can certify its authenticity.
At the same time, users have the option to continue working with the migrated data in the structure of the new software generation.
All these scenarios place special demands on the platform described here for the historization and migration of legacy data and documents.
The solution must be able to reliably and verifiably extract all data and documents from the legacy systems and store them unchanged in their structure.
At the same time, however, they are to be converted into a modern data format, which enables the migration to SAP S/4 Hana or even third-party systems that may be required or desired.
The display of historicized information should be device-independent so that business users, as well as internal audit staff or external auditors, can easily access it.
Of course, a purely browser-based solution is ideal for this, so that no new software needs to be installed, maintained or learned to operate on any endpoint.
From the customer's point of view, it is of course crucial that such a solution supports them in deciding which data should be migrated to the new software generation such as SAP S/4 Hana and which should not.
Configurable tools are available for this purpose as part of the platform, which automatically search the historicized data stock for company codes that no longer have any counterpart in reality, for example.
This can include plants and subsidiaries that have been shut down or sold. It simply does not make sense to migrate this legacy information.
In addition, the new software generations are encountering a new generation of compliance requirements. An example of this is, of course, the European General Data Protection Regulation (EU-DSGVO). This means that we are indeed entering a new era.
Whereas in the past the principle was to store everything and not to delete anything, even if only by mistake, today companies must have the ability not only to store specifically, but also to delete specifically, at the level of the individual data record.
Of course, this applies not only to productive systems, but also to legacy systems. However, some of these systems cannot be retrofitted for deletion at all.
Here, too, a platform for the historization and migration of legacy data can provide a remedy. Of course, this requires comprehensive retention management functionalities for retention periods, automatic and manual deletion, and also for suspending the deletion process for legal proceedings, for example.
In the Anglo-Saxon world, this functionality is called legal hold. In such a case, it is of course necessary to know which data, for example on a person, must be blocked.
With the help of the platform, it must therefore also be possible to determine all the information associated with a specific data record at the touch of a button in order to be absolutely certain that all the data in question is really being recorded. Of course, this also applies to the reverse case of a customer requesting that all data collected about him be deleted in accordance with EU law.
Zur Rose migrates to S/4
The question still remains: Is there even such a platform and customers who have used it to tread and shorten the path to S/4? Europe's largest mail-order pharmacy Zur Rose - probably best known in Germany for its subsidiary DocMorris - is leading the way.
The company has implemented a central S/4 solution into which only the current data is to be transferred. The company expects to reduce the total data stock by 30 percent through duplicate cleansing and to increase the quality of the master data accordingly.
In addition, Zur Rose expects the successive decommissioning of all legacy systems to result in annual savings in operating costs in the six-figure range. The JiVS platform, which has proven itself in numerous national and international customer projects, will be used for the historization and migration of legacy information.
