Migration to SAP S/4 Hana: Here's what the right approach looks like

SAP existing customers must migrate to the new software generation S/4 Hana by 2025. SAP has only given a support guarantee for ERP/ECC 6.0 until then, most recently at the DSAG Annual Congress 2018. Most existing SAP customers associate the migration with the goal of an agile application landscape that will help them master the challenges of digitization.

But beware: What is entirely correct as a goal at the application level cannot be transferred one-to-one to the data level. This is because data from enterprise applications is always in a business context that, for legal reasons, must be preserved along with the data for the duration of the legally prescribed retention periods.

Furthermore, this business context contains important additional information, for example, about the history and quality of a business relationship with a customer or supplier, which can be valuable for the respective company even years later.

So at the data level, it's less about agility and more about stability. This is the reason why every migration to new software generations - both within and outside SAP - results in the accumulation of large volumes of data in corporate data centers, which are stored and maintained together with the legacy applications because of the business context - in some cases for many decades and at considerable cost.

When switching to S/4, the problem of having to continue to operate legacy systems arises again, and in an aggravated form. On the one hand, for cost reasons alone, it makes no sense to transfer all data and documents from the legacy systems to the Hana database.

Although storage media have become significantly cheaper overall, main memory and computing resources still require noticeable investments. On the other hand, the data structure is massively changed when switching to SAP Hana.

This will reduce the number of tables in large installations from over a hundred thousand to fifteen thousand to a maximum of twenty thousand. This exposes companies to enormous legal risks if they do not find a sensible solution for their legacy data and systems.

A question of architecture

The all-important question is therefore: How can the opposing goals of agility and stability be reconciled? With the help of a new approach: a different architecture for the application landscape that separates legacy data and documents from the agile apps of the future. In this way, legacy systems can be shut down, and new software generations can be kept lean and agile over the long term.

The key element of this new architecture is a dedicated system-independent environment for data, documents and their business context that are no longer required in the operational systems.

Such an environment ensures the required stability at the data level. At the same time, it increases legal and IT security. This is because, unlike many legacy systems, it can be further patched and secured.

In addition, it allows the entire lifecycle of legacy data and documents to be managed seamlessly at the level of individual data records and documents by means of retention management functionalities.

This explicitly includes the targeted deletion of data and documents - one of the essential requirements of the European Data Protection Regulation (EU GDPR).

Certification in accordance with the IDW PS 880 standard of the Institute of Public Auditors in Germany ensures that auditors and the tax authorities also have confidence in this environment with regard to the immutability of the data and documents transferred from the operational systems and their business context.

Save up to 80 percent

As a result, the legacy applications can be shut down, leading to operational savings of up to 80 percent - and sometimes even more - compared to their continued operation. But what is at least as important in the context of the upcoming migration to S/4:

If business data and documents are outsourced to this environment as soon as they are no longer needed operationally, the current applications and systems remain lean and agile in the long term. As a rule, the operational data volume can be reduced by 50 to 75 percent. Any unnecessary ballast is thus avoided.

A simple calculation shows why this is so important: Around 10,000 existing SAP customers are based in German-speaking countries. 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. According to Adam Riese, this will simply not be possible.

Save time and become agile

If data and content that is no longer required is continuously transferred from the operational applications to a legally compliant system-independent platform, corporate IT as a whole becomes significantly more agile and can support a wide range of business scenarios with very little effort.

Example: Acquisition and sale of companies and business units: Here it is necessary to decide which applications should be taken over by the purchased company because they have advantages over the company's own, and which are no longer needed.

This is directly related to the question of which data and documents should be migrated to the live systems. The continued operation of legacy systems in companies is a major reason why, as a rule, 80 percent of the entire IT budget is spent on operations alone.

In addition, there are compliance and security risks if the acquired systems can no longer be reliably maintained or secured by means of regular security patches.

And retrofitting to meet the deletion requirements of the EU GDPR, for example, is no longer technically possible for many legacy systems, or can only be implemented with a great deal of effort.

Example Consolidation of heterogeneous application landscapes to central systems such as SAP: The consolidation of the SAP system landscape is not a purely technical project.

Rather, the companies are combining business management and strategic goals with this: Centralization is intended to reduce complexity, lower the corresponding maintenance, administration and cost expenditure, and accelerate innovations.

For example, the consolidation of globally distributed SAP landscapes offers the possibility of implementing changes and further developments more quickly and making them available globally. However, these goals can only be achieved if the legacy systems are decommissioned.

Example consolidation of globally distributed data centers: Data center consolidation projects start with a comprehensive inventory and analysis of the application and system landscape.

Which of these can really be moved to the central location without major changes? Are there local regulations and laws that prohibit the move because the data belonging to certain transactions or persons, such as from financial accounting or human resources, cannot cross national borders?

All these considerations jeopardize the actual goal of consolidation, centralization, and also threaten to make the partial move very complex and thus time-consuming as well as costly. After all, many sites cannot be decommissioned unless a solution is found for legacy data and documents.

Factor data quality and future

Example of data quality: One customer, many data records, and different ones at that, so companies assume different customers instead of one. This is because they cannot determine any relationship between the data records during evaluations.

That is the current state of affairs in many companies. However, analyzing data in detail is virtually the prerequisite for optimized digital processes, new digital products and services.

If you don't have a correct overview of a customer's purchase history, you won't address them with the right offers and the right level of personalization. In short: The basis for digital business models is missing.

For the time before as well as after the S/4 Hana migration: SAP systems grow. Even after a short time, storage capacity must be expanded and computing resources increased so that requests from business users against the system are not noticeably detrimental to performance.

For existing SAP customers, there is a new challenge. This is because their existing systems are usually not yet running on the new Hana database, but on one of the common relational DBMS systems. In the future, however, they will have to purchase licenses for SAP Hana, which are also volume-dependent!

SAP legacy customers therefore have a strong interest in reducing their data footprint before migrating to the Hana database. The solution to the challenges in the aforementioned business scenarios is to decommission the IT systems that are no longer needed and transfer the data and documents they contain to a modern platform in order to be able to manage the lifecycle of the legacy information and its business context.

If certain data and documents are not allowed to leave national borders, they can be stored and maintained on local instances of the platform, but are accessible worldwide. In addition, the data can be checked for redundancy, consistency and correctness, and corrected and enriched on the basis of rules.

The Java-based platform JiVS was developed precisely for these and other agile business and application scenarios. It is characterized by its ability to continue to store data from deactivated legacy systems, as well as the associated documents, in their business context in a legally secure manner. JiVS is therefore the core element of an agile application landscape in companies: This is what the right approach looks like.