Risks Rather Than Bonanza
When converting to SAP S/4 Hana, it is important to preserve existing legacy data along with its context in order to make it available for meaningful analyses and insights. This is the treasure trove that companies want to unearth and exploit in the course of their digital transformation. However, it is precisely this context that is lost during the transformation, because the S/4 world requires different data structures than the previous generation. Instead of hoping for a bonanza, companies are confronted with a risk of loss.
There is also the issue of data quality. Many different data pools with different structures and countless redundant or incorrect master data records for one and the same customer and supplier reduce the quality of the data, until the very foundation of digital business models and processes breaks down. You can't make money with fool's gold.
And then there are the legislators. Various retention obligations and retention periods prevent companies from changing data and its structures. In addition, the European General Data Protection Regulation (EU GDPR) in particular and, more recently, the new Swiss Data Protection Act require companies to be able to delete information at the level of the individual data record. However, retrofitting this capability into legacy systems is either no longer technically possible or can only be achieved at great expense. In addition to the risks of loss of value and quality, there is also a lack of legal certainty. Instead of increased profits and bonuses, there is a threat of fines and the personal liability of board members and management.
The seven golden rules of S/4 transformation
It's no wonder that so many SAP customers still hesitate to migrate to SAP S/4 and continue to operate their old systems and archives at great expense until the retention periods for the legacy information stored on them has expired—sometimes decades later. What can SAP customers do to avoid these risks and utilize the move to the new software generation to their advantage? The answer lies in the seven golden rules of S/4 transformation:
1. Separate instead of 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.
As the business usually takes precedence over IT, the specialist departments often assert their interests. As a result, most transformation projects take much longer than necessary. In the case of large and very large companies, this can be five years or more instead of just a few months.
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 specialist departments as needed. The risk of losing the business context is thus eliminated. 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 specialist departments.
2. Accessing instead of transforming
By separating the application level from the data level, companies can determine—purely based on business considerations—which master data they actually need in S/4, and whether they really want to transform operational data that is more than three months old, for example. This minimizes the migration and transformation effort significantly, usually by 50 percent or more.
In addition, this approach keeps the Hana database permanently lean. This is because the process of generally storing outdated transactional data on a separate platform can be repeated indefinitely. It is a realistic estimate that this can reduce the total operating costs of the new S/4 environment by 25 percent.
What's more, as it is independent of SAP systems, legacy data from non-SAP systems can also be stored on a separate platform. This not only enables the consolidation of heterogeneous systems into a harmonized IT landscape, but also paves the way for further agile business scenarios. These include, in particular, the takeover and integration of inherited databases and system landscapes in the course of mergers and acquisitions. However, in the case of the sale of a business unit or subsidiary, also known as a carve-out, this approach and the separate platform required for it are also extremely beneficial to companies.
But perhaps the decisive advantage is that a separate platform offers the possibility of transforming and migrating the selected master and transactional data via the application layer without loss or risk. This allows SAP customers to use the tools provided by SAP for this purpose, namely the SAP Migration Cockpit.
Ultimately, this platform approach turns every brownfield project into a greenfield project for starting afresh with an S/4 system that is optimally adapted to future challenges. In a first step, companies convert all settings and custom developments of their previous SAP system to the new S/4 system, but without master and transactional data. This allows them to flexibly design their business objects, as well as all adjustments to the configurations and custom developments in the new system, independently of the data, according to their requests and requirements for the future. Only during the second step do they fill this "empty" but customized shell, although only with the master and transactional data that they have pre-selected on the platform. As a result, the number of business objects can usually be halved and the amount of master data required can be reduced by 80 percent, while transactional data can be reduced by 90 percent or more.
3. Taking precautions instead of making improvements
There are major dependencies between the legacy data, its structures, and the systems and applications in which it was created, which are practically impenetrable, like the walls of a silo. Breaking through these walls during the transformation has only a minimal chance of success. If, on the other hand, SAP customers transfer their entire legacy data along 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 cleanse the legacy data that it wants to transfer to S/4 separately from the source systems on the separate platform before the transformation. It can also eliminate duplicates and errors, and enrich these data records with data from third-party sources. This is particularly important in analytics scenarios and applies not only to transactional data, but also to all master data, including the customer, supplier, article, and material master data that are so important for digital transformation.
4. Switch off and save
To make sure that the statutory retention obligations and deadlines do not stand in the way of system decommissioning, the platform must transfer the legacy information in its original state and store it in a way that allows it to later be audited. This audit-proof information storage must also be certified by auditors. In addition, however, the platform must be able to fully comply with the deletion obligations of the EU GDPR and the Swiss Data Protection Act, as well as various national data protection regulations. This ensures legal certainty even without the continued operation of the legacy systems.
5. Ensure (legal) security
To ensure that the statutory retention obligations and deadlines do not stand in the way of system decommissioning, such a platform must transfer the legacy information in its original state and store it in an audit-proof manner. At the same time, this audit-proof storage of information should be certified by auditors. In addition, however, the platform must be able to fully comply with the deletion obligations of the EU GDPR and the Swiss Data Protection Act as well as various international data protection regulations. This ensures legal certainty even without the continued operation of legacy systems.
In addition, transferring data to a separate and modern platform contributes to greater IT security and thus data security because, unlike some legacy systems, a modern platform can also be patched in the future.
6. Automate, automate, automate
In view of the enormous amounts of data that SAP customers from the enterprise segment in particular need to deal with, it is important to achieve the highest possible degree of automation. This applies especially to the first step—the extraction of data and its business context via the application layer. It must be possible to extract quantities of 10, 100, or more terabytes of information from legacy systems and ADK archives and transfer them to the platform fully automatically, in a matter of hours and days rather than months or even years—all at the push of a button.
Automation also plays an important role when it comes to displaying legacy information in the SAP S/4 world via SAP GUI or SAP Fiori. This requires the process of technical structure mapping, which 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 "Vendor" can be displayed in S/4 via the "Partner" business object as if it had been created within this structure. The automated processes, from data extraction through to displaying data in the new environment, make up the One Click Transformation which represents the core of a separate platform approach for selective data transformation via the application layer.
7. Use 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 for reducing the legacy data volume (known as the Data Potential Reduction Analysis or DPRA), and exactly which data needs to be transferred during a carve-out, as well as defining the filter and transformation rules.
In order to be able to simulate these scenarios and the associated benefits, synergies, and preparations without any risk, companies need a service solution that makes this possible independently of the platform itself. The service works with metadata such as information on systems, applications, and databases that are relevant for the S/4 transformation or for the business unit that is being sold. The insights provided by this SaaS solution for transformation projects provide SAP customers with a realistic and reliable basis to make decisions about their transformation projects.
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 levels, 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 process for turbo-extracting legacy data.
