S/4 Transformation: Data is the biggest risk
Conversion deadline 2027/2030
What has long been suppressed is gradually making its way into the consciousness of those responsible for SAP: the question of how the sometimes massive stocks of legacy data from SAP, but also from non-SAP systems and ADK archives, can be migrated and transformed to SAP S/4 Hana quickly and in a legally secure manner.
Legacy data: Risks instead of bonanza
The transformation to SAP S/4 Hana is all about preserving existing legacy data along with its context and making it available for analysis and insights. However, standing in the way of this are the dependencies between the data, its structures, and the systems and applications in which they originated, which are virtually impenetrable like the walls of a silo.
In addition, there is the question of data quality. Many different data pools with different structures, countless redundant and incorrect master data records for one and the same customer or supplier reduce the quality of the data and thus make the foundation of digital business models and processes more than fragile.
And then there is the legislator. Various retention obligations and deadlines prevent companies from changing data and its structures. But this is precisely the case when legacy data is transferred to SAP S/4 Hana. In addition, the European General Data Protection Regulation (EU-DSGVO) in particular obliges companies to be able to delete information at the level of the individual data record. However, retrofitting this capability in legacy systems is either no longer technically possible or can only be realized at great expense. So in addition to the questions of data value and data quality, there is also the question of legal certainty.
All this means that SAP legacy customers all too often migrate far too much data, and inadequate quality at that, to SAP S/4 Hana - and lose the business context in the process. This is another reason why they continue to operate their legacy systems and archives at great expense until the retention periods for the legacy information stored in them have expired - sometimes decades later.
No wonder, then, that so many existing SAP customers remain hesitant about transforming to SAP S/4 Hana. And no wonder that most transformation projects take much longer than necessary - in the case of large and very large companies, five years or more instead of a few months.
The seven golden rules of S/4 transformation
For a long time, SAP customers and experts debated whether it was more clever to convert all legacy data and business objects into the new world during the S/4 transformation (classic brownfield approach) or to do without it completely and start anew unencumbered on the greenfield. The approach of selective data transfer and transformation soon crystallized as a compromise that could be applied in practice, in which companies transform only selected operational data in addition to master data, and which is offered on the market in various shades of color.
But even this compromise carries major risks if it takes place at table level. Because at this level, it resembles a risky open-heart surgery. Not to mention the fact that the data transfer cannot be carried out using the tools provided by SAP, such as the Migration Cockpit.
So what can existing SAP customers do? They should follow the seven golden rules of the S/4 transformation. Then they can contain and even eliminate the risks mentioned.
1. Separate instead of migrate
Most transformation projects take longer than necessary not only because of the technical hurdles, but because of the conflicts between IT and business departments. After the transformation, the business departments still want to access all legacy data along with its business context. In order to prevent this requirement from becoming an excessive and lengthy project, IT insists on transforming only a few vintages. To prevent this problem from arising in the first place, SAP legacy customers should apply the first golden rule: separate instead of migrate. This means extracting the complete legacy dataset, including data from ADK archives and its business context, from the legacy systems and storing it unchanged on a separate modern platform.
This has the decisive advantage that all data is available independently of the legacy systems and can therefore be made available to the specialist departments at any time. At the same time, IT can autonomously answer the question of which part of the legacy data should subsequently be transferred and transformed to SAP S/4 Hana. In this way, the S/4 transformation becomes a technical project, but one that also takes into account the wishes of the business departments.
2. accessing data instead of transforming it
By separating the application level from the legacy data level, companies can determine purely on the basis of business considerations which master data they still need in S/4 at all and whether they really want to transform operational legacy data that is older than three months, for example. This minimizes the migration and transformation effort enormously, usually by 50 percent or more. For example, the internationally active Bühler Group, a leading manufacturer of plant and machinery for the food industry and vehicle manufacturing, was able to reduce its data inventory by two-thirds from 6 TB to less than 2 TB when migrating to the Hana database and S/4 with the help of a separate platform.
In addition, this approach keeps the Hana database permanently lean. This is because the process of generally outsourcing obsolete transaction data to the separate platform can be repeated indefinitely. It is a realistic estimate that this will reduce the total cost of ownership of the new S/4 Hana environment by 25 percent. What's more, because it is independent of SAP systems, legacy data from non-SAP systems can also be stored on a separate platform. This not only allows heterogeneous systems to be consolidated into a harmonized system landscape, but also clears the way for other agile business scenarios. These include, in particular, the takeover and integration of inherited databases and system landscapes in the course of mergers and acquisitions. But this approach and the separate platform required for it also play their trump cards to the advantage of companies in the reverse case of the sale of a business unit or a subsidiary, so-called carve-outs.
But perhaps the all-important advantage is that such a separate platform offers the possibility of transforming and migrating the selected master and transaction data together with their business context via the application layer without loss or risk. This allows existing SAP customers to use the tools provided by SAP for this purpose, namely the SAP Migration Cockpit.
Incidentally, the platform also supports a - customized - brownfield approach. In a first step, the companies transfer all settings and individual developments of their previous SAP system to the new S/4 without converting and importing the master and transaction data. The highlight here is that this allows them to make all adjustments to the configurations and individual developments in the new system flexibly according to their wishes and requirements, independently of the data. Only in a second step do they fill this "empty" but customized shell, but only with the master and transaction data that they have previously selected on the platform.
3. take precautions instead of making improvements in data quality
Solving the problem of dependencies mentioned in the risks during the transformation has only a minimal chance of success. If, on the other hand, existing SAP customers transfer their entire legacy data together with its business context to a separate platform before the transformation, the problem of dependencies no longer arises. At the same time, IT has the opportunity to clean up the legacy data that it wants to transfer to S/4 Hana, detached from the source systems on the separate platform, before the transformation, and to eliminate duplicates and errors in the process. In addition, it can enrich these data sets with those from third-party sources. This is particularly important in analytics scenarios and, incidentally, applies not only to movement data but also to all master data, including the customer, supplier, item and material masters that are so important for digital transformation.
4. Switch off and save
Once the legacy data from SAP and non-SAP systems, including the business context, has been transferred to the separate platform, the legacy systems, whether from SAP or third-party manufacturers, and ADK archives can not only be dismantled, but completely decommissioned and disposed of - a worthwhile approach even in the greenfield scenario of an S/4 transformation: Compared to continued operation, this usually saves SAP legacy customers 80 percent or more in operating costs.
This is precisely the case with the Bühler Group mentioned above. Starting in 2003, the company migrated all country-specific ERP systems, most of them from SAP, to a single central SAP-
clients were consolidated and completely decommissioned with the help of a separate platform approach. Since then, the Bühler Group has reduced SAP operating costs by 80 percent.
5. provide (legal) security
To ensure that statutory retention obligations and deadlines do not stand in the way of system decommissioning, such a platform must transfer and retain legacy information unchanged. At the same time, the audit-proof storage of the information should be certified by auditors. In addition, however, the platform must be able to fulfill the deletion obligations of the EU GDPR down to the level of individual data records without any gaps. This ensures legal certainty even without the continued operation of legacy systems.
Incidentally, transferring data to a separate and modern platform contributes to greater IT and thus data security because, unlike some legacy systems, a modern platform can also be patched in the future.
6. automate what can be automated
In view of the enormous volumes of data that SAP's existing customers in the enterprise segment in particular have to contend with, it is crucial to achieve the highest possible degree of automation. This applies in particular to the first step, the extraction of data and its business context. It must be possible to extract even quantities of 10, 100 and more terabytes of information from legacy systems and ADK archives completely automatically at the push of a button in just a few hours and days instead of months or even years, transfer them to the platform and store them there in a legally secure manner until they are deleted.
But automation also plays an important role when it comes to displaying legacy information in the SAP S/4 Hana world via SAP GUI or SAP Fiori. This requires the "Technical Structure Mapping" process. This involves transforming legacy data "on the fly" without changing the original structure of the historical data on the platform itself. For example, data for the SAP ECC business objects "Customer" or "Supplier" can be displayed in S/4 Hana in the structure of the business object "Partner" as if it had been generated in this structure.
This level of automation from data extraction to display in the new environment is the essence of the separate platform approach to selective data transformation via the application layer, which can aptly be called One-Click Transformation.
7. use one-click transformation as a service
All transformation scenarios involve similar and recurring tasks. These include, for example, taking stock of the existing system and application landscape, including release statuses, or analyzing how great the potential for reducing the legacy data stock is (the so-called Data Potential Reduction Analysis or DPRA) and which data exactly (but no more!) must be transferred in a carve-out, and defining the filter and transformation rules.
To be able to run through these scenarios and the associated benefits, synergies and preparatory work completely risk-free, companies need a service solution that enables this to be done independently of the platform used for data extraction, analysis, optimization, transformation and retention. The service works with metadata such as details of systems, applications and databases that are relevant to the S/4 transformation or the business unit for sale.
The insights provided by this SaaS solution for transformation projects give existing SAP customers a realistic and reliable basis for making decisions about their transformation projects.
Insurance policy against transformation risks
Both the platform and the transformation service already exist. JiVS IMP, the system-independent information management platform from the Swiss provider Data Migration International, has already proven its benefits in over 2000 projects worldwide. The platform ensures a clean separation between the data and application layers, thereby radically accelerating the extraction, transformation, and migration of legacy data via the application layer and SAP's standard tools.
The platform makes this possible by supporting more than 3,000 business objects from SAP and non-SAP systems of various releases as well as a patent-pending procedure for the turbo extraction of legacy data.
With the help of JiVS IMP, for example, Hawle Armaturen AG, a leading Swiss production and trading company in the water, gas and wastewater sectors, was able to successfully complete its data transformation and migration project as part of the switch to SAP S/4 Hana within just three months.
Since last year, Data Migration International has been providing the One-Click Transformation Cockpit, provided as a SaaS solution, as a supplement to its platform, thus making the preparation of transformation projects a service. Incidentally, the platform itself is also available as a cloud service.
JiVS IMP and the One-Click Transformation Cockpit are the insurance policy against data risks. As a central element of an enterprise-wide data fabric, they support transformation projects of all kinds and pave the way to the data-driven enterprise.
