A subject that has been pushed to the back of people’s minds for quite some time is gradually making its way back into the consciousness of those responsible for SAP: the issue of how to transform and migrate what can be masses of legacy data from SAP and non-SAP systems, as well as ADK archives, to SAP S/4 Hana—quickly and in a legally secure manner.
Legacy data: risks rather than bonanza
With the transformation to SAP S/4 Hana, it is important that the existing legacy data is preserved together with its context and is made available for analyses and insights. However, this is hindered by the dependencies between the data, its structures, and the systems and applications from which they originated, which—much like the walls of a silo—are practically impenetrable.
There is also the issue of data quality. Many different data repositories with varying structures, countless redundant and erroneous master data records for the same customer or supplier reduce the quality of the data, making the foundation of digital business models and processes extremely fragile.
And then there is legislation. 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, in line with the European General Data Protection Regulation (EU GDPR) in particular, companies must be able to delete information at the individual data record level. However, retrofitting this capability in legacy systems is either technically impossible or can only be done at great expense. So, besides the issues of data value and data quality, there is also the issue of legal security.
All this leads to the fact that too often, SAP customers migrate far too much data that is of inadequate quality 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 of the legacy information stored in them have expired, which can sometimes be decades later.
It is therefore no wonder that so many existing SAP customers are still hesitant to move 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, it can take 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 discussed whether it made more sense to convert all legacy data and business objects into the new world as part of the S/4 transformation (a classic brownfield approach) or to do without it completely and start afresh and unencumbered, with a greenfield approach. It soon became clear that a selective data transfer and transformation approach was a compromise that could be applied in practice, whereby companies transform only selected operational data in addition to their master data—for which there are various possible solutions available on the market.
But even this compromise carries significant risk, with stakes almost as high as those in open-heart surgery. Not to mention the fact that the data transfer cannot take place using the tools provided by SAP, such as the Migration Cockpit.
What options are then available to SAP customers? The best option is to follow the seven golden rules of S/4 transformation to contain, and even eliminate, these risks.
Separate rather than migrate
Most transformation projects take longer than necessary, not only because of the technical hurdles but also due to the conflicts between IT and specialist departments. After the transformation, specialist departments still want to be able to access all legacy data along with its business context. To prevent this requirement from turning into an excessive and lengthy project, IT insists on transforming only a few years’ worth of data.
To avoid this problem in the first place, SAP customers should apply the first golden rule: separate rather than migrate. This involves extracting the entire legacy data, including the data stored in ADK archives, along with its business context from the legacy systems and storing it unchanged on a separate, modern platform.
The decisive advantage of this is that all data is available independently of the legacy systems and can therefore be made available to the specialist departments as needed. At the same time, IT can autonomously identify which legacy data should subsequently be transformed and transferred to SAP S/4 Hana. This way, the S/4 transformation becomes a technical project that simultaneously takes into account the requests of the specialist departments.
Access 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 and whether they truly want to transform operational legacy data that is older than three months, for example. This radically minimizes the migration and transformation effort, usually by 50 percent or more. For example, Bühler Group, an international, leading manufacturer of machinery and equipment for the food industry and vehicle manufacturing, was able to reduce its data volume by two-thirds from 6 TB to less than 2 TB when switching to the Hana database and S/4, with the help of a separate platform.
In addition, this approach keeps the Hana database permanently lean, as the process for outsourcing obsolete transaction data to the separate platform can be repeated indefinitely. Through this approach, the total cost of ownership of the new S/4 Hana environment can be realistically reduced by 25 percent.
What’s more, because it is independent of SAP systems, legacy data from non-SAP systems can also be stored on the separate platform. This not only allows the consolidation of heterogeneous systems into one harmonized system landscape, but also paves the way for other agile business scenarios. Typical scenarios include the takeover and integration of inherited databases and system landscapes in the event of mergers and acquisitions. On the other hand, when a business unit or subsidiary is sold as part of a carve-out, this approach and the separate platform that is required bring considerable benefits to the companies involved.
But perhaps the all-important advantage is that with a separate platform such as this, it is possible to transform and migrate the selected master and transaction data together with their business context via the application layer without any losses and in a risk-free way. This enables existing SAP customers to use the tools provided by SAP for this purpose, namely the SAP Migration Cockpit.
The platform also supports a customized brownfield approach. First, companies transfer all settings and customizations from their previous SAP system to the new S/4 environment, but without converting and importing the master and transaction data. What’s so special about this platform is that it allows companies to make all adjustments to the configurations and customizations in the new system, independently of the data, and can be tailored according to their specific requirements. Second, companies then fill the empty, yet customized shell only with the master and transaction data that they have previously selected on the platform.
Allow for data quality instead of having to improve it
Solving the problem of dependencies, mentioned in relation to risks, during the transformation has only a minimal chance of success. If, on the other hand, SAP customers transfer their entire legacy data together with its business context to a separate platform prior to the transformation, dependencies are no longer an issue.
At the same time, the IT department has the opportunity to clean up the legacy data it wants to transfer to S/4 Hana, detached from the source systems, on the separate platform, before the transformation. They can also eliminate duplicates and errors. In addition, IT can enrich these data sets with data from third-party sources. This is particularly important in analytics scenarios and, incidentally, applies not only to transaction data but also to all master data, including customer, supplier, item, and material masters, which are extremely important for the digital transformation.
Switch off and save
Once the legacy data and its business context have been transferred from SAP and non-SAP systems to the separate platform, not only can the legacy systems (from both SAP or third-party providers) and the ADK archives be switched off, but they can be completely decommissioned and disposed of. This is a worthwhile approach, even in the greenfield scenario for an S/4 transformation. Compared to keeping the legacy systems running, this usually saves SAP customers 80 percent or more in operating costs.
This was exactly the case with the Bühler Group. Starting in 2003, the company consolidated all its country-specific ERP systems, most of them from SAP, onto a single central SAP client and completely decommissioned them using the separate platform approach. Since then, the Bühler Group has reduced its SAP operating costs by 80 percent.
Ensure (legal) certainty
To ensure that statutory retention requirements and deadlines are not affected by decommissioning the systems, the platform must transfer and store the legacy information without any changes made to it. At the same time, the audit-compliant storage of the information should be certified by auditors. In addition, however, the platform must also be able to fulfill the erasure obligations of the EU GDPR (General Data Protection Regulation) in full, down to the level of individual data records. This ensures legal certainty, even without the continued operation of the legacy systems.
What’s more, the transfer of data to a separate and modern platform contributes to greater IT and data security because, unlike some legacy systems, a modern platform can also be patched in the future.
Automate what can be automated
Given the large volumes of data that SAP customers in the enterprise segment deal with, maximum automation is crucial. This is especially true for the first step—the extraction of data and its accompanying business context. It must be possible to extract 10, 100, and more terabytes of information from legacy systems and ADK archives in a few days instead of months or even years, at the click of a button. The process for this should be completely automated, transferring the information to the platform and storing it there in line with legal requirements until it can be deleted.
However, automation also plays an important role in displaying legacy information in SAP S/4 Hana via the SAP GUI or SAP Fiori. This requires technical structure mapping. During this process, the legacy data is transformed “on the fly” without changing the original structure of the historical data on the platform itself. For example, data for the SAP ECC customer or supplier business objects can be displayed in S/4 Hana in the structure of the partner business object as if it had been created in this structure originally.
This level of automation, from data extraction to displaying data in the new environment, is the essence of the separate platform approach to selective data transformation via the application layer, which is fittingly known as the One Click Transformation.
Using 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 the potential to reduce the volume of legacy data (a process known as the Data Potential Reduction Analysis or DPRA) and which data exactly (but no more!) must be transferred in the event of a carve-out, as well as defining the filter and transformation rules.
To be able to run through these scenarios and the associated benefits, synergies, and preliminary work completely risk-free, companies need a service solution that makes this possible independently of the platform used for data extraction, analysis, optimization, transformation, and retention. The service works with metadata such as system, application, and database details that are relevant to the S/4 transformation or the business unit that is being sold.
The insights provided by this SaaS solution for transformation projects give SAP customers a realistic and reliable basis for making decisions relating to 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 Swiss provider Data Migration International, has already proven its worth in over 2,000 projects worldwide. The platform ensures a clean separation between the data and application layers and thus radically accelerates 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 different 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, a leading Swiss manufacturing and commercial enterprise in the water, gas, and wastewater sectors, was able to successfully complete its data transformation and migration project as part of the move to SAP S/4 Hana within just three months.
Since last year, Data Migration International has been providing the One Click Transformation Cockpit as a SaaS solution that complements its platform, effectively turning the preparation of transformation projects into a service. Furthermore, the platform itself is also available as a cloud service.
JiVS IMP and the One Click Transformation Cockpit are an insurance policy against data risks. As a central element of a company-wide data fabric, they support all kinds of transformation projects and pave the way for data-driven companies. Armed with the right tools and the seven golden rules, any company can overcome the challenges looming ahead.