All about legacy system decommissioning in S/4HANA migration

24-07-2024 | 9 min read | Data Management for S/4HANA Migration, Decommissioning of Legacy Systems

There are many reasons why a company might need to shut down an IT system or application, yet the first we can think of nowadays is the migration to SAP S/4HANA. Inevitably, SAP companies have an important choice ahead when it comes to managing the old SAP system (or any other ERP system in use), regardless of the migration approach chosen. In any case, there is a crucial necessity to retain access to historical data that is required for tax and audit compliance reasons or business needs. But how? What is the best course of action to deal with SAP legacy systems?

The decommissioning of legacy systems retires the old system by extracting historical information (data, documents, reports, and documentation) and storing it elsewhere to preserve it, removing the expense of keeping the system. The data can be re-accessed when needed using a legacy system application, such as ELSA. TJC Group helps SAP Customers speed up their SAP S/4HANA move by providing access to legacy data in one single platform before and after S/4 migration. Enterprise Legacy System Application, or ELSA is an application built on SAP BTP that makes it possible to access legacy data, document and reports either from the cloud application itself or from SAP S/4HANA (through a UI5 application, UI5 being the open-source version of FIORI).

The expense of retaining all the legacy data is simply unviable in most SAP migration cases and so, the question of whether to complete a greenfield, brownfield or SDT (Selective Data Transition) implementation becomes an important factor.

Let’s be honest: SDT is probably the best option in most cases, given the fact that SAP is providing a roadmap for a SAP lean SDT , free of charge, with SAP Cloud ALM solution (CALM).

In an increasing number of scenarios, organisations are choosing to start afresh and complete a ‘greenfield’ implementation, with no legacy data coming into the new database. This is cost-efficient in terms of the S/4 HANA storage costs, but the approach comes with other disadvantages. Other users will opt for a ‘brownfield’ implementation and just bring across a subset of legacy data, often for tax and audit compliance purposes.

In any case, there is an imperative need to retire the old SAP system and retain access to the golden data. It’s a classic misunderstanding that brownfield migration does not require the legacy system to be decommissioned. Why? A technical upgrade does not prove the data is complete or unchanged, so the S/4HANA system can never function as a tax archive for data created in the legacy system.

 Figure 1. Options to manage legacy systems. Source: TJC Group

Potentially, there are other options available, such as keeping the legacy system alive, coexisting with SAP S/4HANA. However, that comes with high licensing and maintenance costs.

One might argue that freezing a system into a Virtual Machine does the job at a much lower cost. However, this is not the case. First and foremost, booting up the system every time a business user requires access is time-consuming and comes with high-security threats. More importantly, after a few years, the system will be outdated, unpatched and at risk. We have written about the pros and cons of using Virtual Machines for legacy system decommissioning.

In short, retiring SAP ECC or R3 systems will simplify the overall IT landscape and reduce long-term administration and maintenance costs.

We thoroughly recommend you to watch the replay of the webinar SAP® S/4HANA Update: SAP®ECC Legacy System Decommissioning to learn about a cost-effective approach to decommissioning of your legacy system landscape.

SAP implementation partners frequently suggest an easy workaround: the user ‘freezes’ their existing system on a virtual machine. They might also advise to leave the legacy system running and to do nothing. However, both  ‘options’ aren’t compliant or viable in the long run, although they can be very appealing in the short term where costs are a major factor.

Ultimately, neither is efficient because, in each case, you will either face extensive maintenance costs to keep the old system running or, if you decide not to bother, you will be vulnerable to attacks by hackers, which could trigger a ransomware demand and result in even higher costs.

We wrote an article that explains why unchecked legacy systems are more prone to receive cyber attacks and outlines how legacy system decommissioning wipes that risk out.

Decommissioning legacy SAP systems can free up maintenance budgets, reduce hardware costs and resource requirements. It will:

  • Reduce your cost and optimize your IT investment. Keeping old systems alive can be very expensive: high maintenance costs, the SAP licensing costs, infrastructure and the staff needed to keep these systems up to date. By retiring old systems, the maintenance and resources overhead will be significantly reduced.
  • Save on HANA licensing costs. HANA memory follows a T-shirt size pricing model that is highly complex and expensive. Any company looking for a cost-efficient must carefully think what data is to be loaded into HANA and estimate the memory needs.
  • Help to manage HANA memory needs. HANA memory scalability is limited, meaning that it is not that simple to switch to next tier. We frequently deal with S/4HANA system with ACDOCA performance issues.

A decommissioning program using a SAP-certified cloud application like ELSA is a huge opportunity to reduce licensing and infrastructure, energy and maintenance costs, hence having a positive impact on the migration bill to S/4HANA.

Over time, it’s unavoidable that most organizations will amass substantial volumes of data scattered across outdated legacy systems. Managers often assume that these systems are seldom used: however, they contain significant data repositories, essential for business purposes and compliance with tax, audit regulations. As a result, the data in systems being retired often needs to be archived and maintained both for audit and compliance reasons and as a way of reducing the amount of data moved into SAP S/4HANA.

Figure 2. The tax and data privacy compliance iceberg. Source: TJC Group

Figure 2. The tax and data privacy compliance iceberg. Source: TJC Group

Last but not least, data must be kept as a tax archive, extracted and stored as flat file, in order to prove it hasn’t been modified. For example, ELSA extracts a detailed audit report of all data which includes proof of completeness and proof of non-modification. A decommissioning solution that does not provide this level of detail will not meet tax and audit requirements.

A typical example of non-compliant solution for decommissioning is all ELT (Extract Load and Transform) and ETL (Extract Transform and Load) solutions based on database-to-database transfer (Including the latest solutions released to the market). Such solutions may not provide a non-modification proof, and most of the time may not guarantee completeness.

Data privacy requirements are quite strong in EMEA, but new data privacy laws continue to come into place around the world. For example, India’s Data Protection law, the DPDP Act, came into force last year in August 2023, and the California Consumer Privacy Act (CCPA) went into effect in January 2020. In the US, typically, financial data needs to be retained for seven years, and this rises to ten years in Canada and Europe. Globally, the retention time for HR-related data is longer. HR data must be held for over thirty years in specific countries and industries!

In an SAP environment, compliance with data privacy laws might include an obligation to delete and anonymize data when requested. For example, this may involve deleting all related transactions to a customer before the customer can be deleted in order to maintain database integrity.

Ensuring SAP Legacy systems adhere to data privacy laws is tricky, as these systems were not originally designed to do so. But, organisations are still liable to such requirements.

Many SAP customers will have invested in SAP RISE with SAP as a way to accelerate their migration path to S/4 HANA. If you are planning to use RISE, apart from the maintenance cost savings achievable, SAP includes the buy-back of SAP ECC perpetual licence. Beware that in this case the legacy system won’t be accessible after a certain timeframe (usually 12 months). Therefore, the decommissioning of SAP legacy system is a must.

Memory costs simulation in a RISE with SAP scenario

The memory cost in RISE with SAP grows in a geometrical way, not in a linear way. Let’s assume that in SAP S/4HANA the database size grows 1TB the first year and the cost climbs to 150k$ per year and TB.

Memory growth is linear

Year                1           2          3         

Volume          1           2          3         

Total cost = n*(n+1)/2

Total cost      1           3          6         

Growing at 1TB a year, an organisation will pay for 6TB over a 3-year period instead of 3 TB. This is why you will end up paying more for memory. Read this article to find out why memory costs do not grow linearly in SAP systems

  • Problem statement

TJC Group was recently responsible for legacy system decommissioning at a global US manufacturing company that wished to decommission its legacy SAP ECC system in advance of moving to SAP S/4 HANA. This company also opted to migrate the data to TJC’s Enterprise Legacy System Application (ELSA). The bulk of this project was completed by TJC Group in six months, and it provided the user with many benefits including a huge $250K financial saving.

The company developed a strong business case for decommissioning that proposed a brownfield S/4 HANA implementation of financial data which excluded divested companies.  Whereas originally the company’s HR data was stored in HCM, this had previously been migrated to SAP Success Factors.

  • Solution adopted

Maintaining the legacy ECC system in addition to running S/4 HANA and Success Factors was prohibitively expensive and the only solution to contain costs and ensure regulatory compliance was to decommission the SAP ECC system and implement TJC Group’s ELSA solution for future user reporting purposes.

Timing for the project was relatively tight, because the client wished to complete the decommissioning process before the next SAP license was up for renewal to save costs. In addition, Oracle required proof of database shutdown so the system could not be frozen (the exact details and requirements can depend on the terms negotiated between Oracle and the customer.).

  • Project implementation

TJC Group began the project by extracting SAP tables which had been separated according to company code and fiscal year information where possible, to reduce the amount of data held . Data extractions were performed using TJC’s own Audit Extraction Cockpit (AEC) software. AEC is data extraction software certified by SAP and has previously been used very successfully to preserve tax and financial data. This legacy information was uploaded to Microsoft Azure Blob and subsequently to MySQL , one of ELSA available database options, chosen to minimise costs and to preserve the data in the cloud. This would ensure it was easily available in the long term through ELSA and cheap to store. Significantly, only data that was necessary for compliance purposes was kept in MySQL, to minimise the database size and costs.

  • Results achieved 

During a four-phased implementation process, TJC’s consultants worked collaboratively with the customer to simplify data retention protocols and to provide additional transaction simulations. This included using ELSA to build dynamic queries to try and simulate SAP like data retrieval. Once completed, it was possible to permanently shut down SAP ECC before the renewal date and hand over future access to legacy data to business users.

Now business end users are able to view all historical data decommissioned from within ELSA and can run both dynamic and static reports, plus see the original documentation.

Overall, the customer has calculated legacy system decommissioning with TJC Group has saved them over $250,000 a year on an ongoing basis, which would have been incurred annually to pay for maintenance and storage costs. If you want to know more about this success story, get in touch with us.

Managing a sunset SAP system that is no longer in use should not be underestimated. It can be very costly and a frozen virtual machine is a serious security risk. It is not possible patch a virtual machine for ever and at some point, it will no longer be possible to find hosting for the legacy data. When considering a migration to SAP S/4 HANA, dealing proactively with the question of legacy data decommissioning always pays dividends in the long term. In addition, it is important not to underestimate the user’s requirement to access historical data, whether this is for internal or external audits or to investigate warranty claims on products.

  • Many SAP customers are still very conservative with their move to S4HANA; the question of what to do with their legacy systems remains a major roadblock.
  • Decommissioning Legacy IT Systems is often the last thing to be considered but can make the biggest difference to the overall cost of your IT landscape.
  • TJC Group helps SAP Customers speed up their S/4HANA move by providing access to legacy data in one single platform before and after S/4 migration.
  • ELSA by TJC brings value to customers by ensuring legacy data can be re-accessed at all times before and after S/4HANA migration.