Decommissioning Legacy Systems: SAP and Non-SAP | Everything You Need to Know

Author: Priyasha Purkayastha, Global Content Manager, TJC Group | Co-author: Thierry Julien, Audren Butery, & Ashish Rathi (ELSA team), TJC Group

Businesses rely heavily on data, and it has increased ten folds in the past decade. While this data happens to be crucial for organisations, its storage in disparate legacy systems can grow to be a challenge in the coming years. Especially, with the ever-changing evolution of the digital landscape, upgrading your organisation’s IT systems becomes increasingly essential. Not to forget, maintaining legacy systems is expensive coupled with several data security concerns. That’s why, legacy system decommissioning is the best way forward. Read this detailed blog to learn more about non-SAP and SAP legacy system decommissioning.

What is SAP & non-SAP legacy system decommissioning?

With the advancements in the technological world, business systems must be migrated or replaced by a new one from time to time. In early times, old systems, running on mainframes, were lost when the hardware were removed. In the later, old, obsolete systems were kept in data centres or migrated into a virtual machine (VMs). However, in today’s digitalised era, these solutions are no longer adequate – as you don’t want to lose information (“data is gold” in AI age), and you can’t afford to keep it. Hence, the best solution forward for organisations is retiring the legacy systems, whether SAP or non-SAP ones; because it can help avoid any security compromises, reduce maintenance costs, and much more.

To define non-SAP and SAP legacy system decommissioning, we can say that it is a planned, carefully governed, and operationally irreversible withdrawal of an obsolete or replaced information-system asset. In fact, it includes codes, data stores, middleware, hardware, cloud, and integrations—from all execution environments as well backup, helping ensure that it is no longer operationally reachable, while simultaneously –

• disposing of hardware, licenses, and integrations in accordance with corporate policy, vendor contracts, and environmental or privacy regulations. Also, this includes secure wipe procedures
• eliminating the cost, security exposure, and technical-debt burden of operating the legacy environment; and
• preserving data, records, and audit trials, in accordance with compliance, that must remain accessible for legal, regulatory, or business purposes.

One of the most important things that you must keep in mind is that legacy system decommissioning is not, in any way, a migration project. As a matter of fact, system decommissioning is a pivotal part of the IT lifecycle management process, helping organisations stay on par with their evolving technological needs. A historically safe approach, both from audit and business users’ perspectives, is to extract data into flat files to create a tax archive. Such data can then be reassessed whenever needed, through display in a more recent application built for it. On top of this historical approach, recent decommissioning of obsolete systems, now requires compliance with data privacy laws & regulations, while optimising your overall resources.

Watch the webinar:

Differences between SAP & non-SAP decommissioning

While retiring obsolete systems, data pivotal to businesses should remain accessible for legal and compliance reasons. However, with several systems in place, wondering about how the decommissioning process takes place is evident. As a matter of fact, there are striking differences between SAP & non-SAP decommissioning;however, with solutions like ELSA by TJC Group, both can be taken care of seamlessly. In the further sections, you will learn about ELSA; but before that, let’s give you an overview of how SAP and non-SAP system retiring are different from each other.

SAP legacy system decommissioning

SAP, as one of the largest ERP solution providers, comes with an array of tools and solutions that streamlines data management. As a matter of fact, for decommissioning too, SAP has specialised tools and process for its systems (SAP ILM). As a matter of fact, there are standardised formats and procedures for data extraction and mapping, specialised software, and so on. Certified add-ons like AEC or Cloud application like ELSA, for SAP system are used, making the system decommissioning process much smoother and efficient. Having said that, the availability of experts catering to SAP decommissioning and developing interesting extraction features for streamlining the process also comes as a boon for organisations.

Non-SAP legacy system decommissioning

In all fairness, decommissioning a legacy system outside the SAP environment can be a little challenging due to the diverse data structures and formats.  For this type of legacy system decommissioning, the non-SAP data must be extracted for alignment with the right tax archive formats. As a matter of fact, the process often requires custom mapping to ensure accuracy of representation.

Key differences

• Tool availability: SAP systems benefit from a broad pool of solutions, which are specifically designed for their architecture. Whereas, non-SAP systems lack such dedicated tools, requiring additional steps for integration. Fortunately, many extractors do exist in the market, and they can be used depending on legacy systems versions.
• Data modeler: SAP systems have standardised data models. For non-SAP systems data model need to be understood. TJC Group uses agentic AI, mixed with in-house experience to propose such model as a project approach, as custom fields & tables also need to be taken into account.
• Complexity and resources: Decommissioning non-SAP systems generally demands more resources due to the need for data mapping, custom configurations, and potential involvement of specialized consultants.

In summary, while SAP provides structured tools and processes for decommissioning its systems, non-SAP system decommissioning requires additional efforts to adapt and integrate data into the decommissioning solution, often involving specialised tools and expert guidance.

Why decommission legacy systems?

Is decommissioning necessary for S/4HANA migration?

With the move to S/4HAHA nearing, you already are aware of the various approaches like the Greenfield approach, Brownfield approach, or the Bluefield one. We’d like to mention the SAP lean selective data transition (SDT) process that SAP offer in SAP cloud ALM. These are the approaches that organisations can opt for the S/4HANA migration process. However, what customers fail to understand is what will happen to their existing ERP systems. On contrary to the popular belief that the migration is just the usual SAP upgrade, it is rather a smart move forward in your data management strategy. As a matter of fact, these ERP systems will be obsolete, and if they do not undergo SAP legacy system decommissioning, it could hamper organisations financially. So, the migration to S/4HANA is a good opportunity to rethink and revamp your IT Landscape and integrate legacy system decommissioning into your data management strategy.

It is imperative to understand that during the migration to S/4HANA systems, the following could occur:

• Some tables will no longer exist in the system
• Specific master data will also no longer exist
• A few amounts of data will be transformed
• Some data will not be selected for the move
• Codes and programs in the system will no longer remain the same

All in all, if you delete the existing ERP systems (SAP ECC) without managing the data properly (for day-to-day business usage, tax or compliance, data privacy needs, for instance), you will bring risk of exposure and potential fines. Therefore, retiring your legacy systems through decommissioning is highly recommended. At TJC Group, we offer to retire your legacy application and access its legacy data in a cloud-based solution. Want to know how? Click on the banner below: All in all, if you delete the existing ERP systems (SAP ECC) without managing the data properly (for day-to-day business usage, tax or compliance, data privacy needs, for instance), you will bring risk of exposure and potential fines. Therefore, retiring your legacy systems through decommissioning is highly recommended. At TJC Group, we offer to retire your legacy application and access its legacy data in a cloud-based solution. Want to know how? Click on the button below:

Some more valuable insights

System decommissioning topic is often initiated with the move to S/4HANA project, but some pitfalls should be avoided. Tackling both migration and decommissioning may seems a good idea at first sight.  But unfortunately, it’s not.

Migration projects target a new system that may have some historical data, transformed in a way consistent with the new usage. Migrated data may not qualify as historical data and will not be accepted in an audit. As a matter of fact, migrated data also don’t qualify for completeness, as migration is a one-time effort that has not been designed for traceability.

The fact of the matter is that thinking of sending some data to the new system, while retaining ‘remaining’ data as historical information may look glamorous; however, it will never be a valid solution. With this, unfortunately, you will just end up with redacted historical data in your new system, and incomplete data in your decommissioning solution. Instead of decommissioning SAP systems, this can end up making your migration process more complex. The best solution is to split your project: keep your migration project focused and get another project for system decommissioning.

Strategic reasons for decommissioning legacy systems

Over time, organisations will accumulate substantial amounts of data, scattered across obsolete systems. While these systems are rarely used, they do contain data significant to organisations for several purposes – from businesses to tax compliance to data privacy and AI training, and so on. Therefore, holding on to legacy data is quintessential for organisations; however, it comes with a cost, typically draining on resources. In fact, over the years, it has been reported that 70% of organisation’s IT budgets are spent on the maintenance of systems, and a significant part may be for legacy systems.

So, what’s a strategic way forward? It is SAP & non-SAP legacy systems decommissioning! Overall, retiring outdated systems provide a cost-saving benefit to organisations, allowing them to utilise the money into adapting newer technologies. Here are five strategic reasons to decommission your legacy systems –

Enhanced security

One of the aspects of legacy systems is that they are vulnerable to security threats, because obsolete systems are not updated with the latest security patches. By decommissioning them, you can breathe a sigh of relief as the process helps reduce risk of potential data breaches and other security threats significantly. At TJC Group, we give utmost importance to data security and are continuously educating our readers about it through our blogs and articles.

Read this blog to understand how legacy systems are prone to SAP vulnerabilities – https://www.tjc-group.com/blogs/is-it-safe-to-keep-legacy-data-in-an-old-sap-system/ 

Ensure cost-savings in the long run

Legacy systems decommissioning contributes greatly to your operating costs. Obsolete systems are not just difficult but also costly to maintain. Additionally, it comes with time-to-time upgrades, which can be also expensive. SAP & non-SAP systems decommissioning helps eliminate licensing costs, resources expenses, and infrastructure overheads. Additionally, what you need to keep in mind is that the costs are not just related to data storage; there are several other costs and factors as well like servers, runtime, operating systems, etc. In fact, maintaining legacy systems comes with an array of hidden costs.

Better compliance with regulations

The fact of the matter is that legal regulations and data privacy laws like the GDPR, CCPA, and so on, cannot be frequently enforced on obsolete systems, as those systems were designed far before those regulations were put in place. However, non-compliance can lead to heavy penalties as well as reputational risks for your organisation. You find, from time to time, control authorities who specifically suggest targeting archive systems. Therefore, SAP legacy system decommissioning happens to be the safest bet. It helps protect your organisations against such non-compliance risks, while performing a complete system extraction. We’ve a detailed blog on how system decommissioning helps with data privacy and cybersecurity.

Enhanced efficiency of systems

Yet again a major reason for SAP & non-SAP decommissioning is to improve the efficiency of the systems. You see, legacy systems, as the years go by, become cumbersome and inefficient. More than contributing to the business, it requires constant maintenance, leading to more technical debts. Decommissioning legacy systems will enable businesses to enhance the efficiency of their systems and operations by replacing the outdated ones with faster, more reliable, and advanced solutions. As a matter of fact, decommissioning can turn out to be highly beneficial and invaluable when it comes to mergers and acquisitions, S/4HANA migration, moving to the cloud, and so on.

“By decommissioning outdated systems, businesses can reduce costs, improve efficiency, and ensure their systems are compliant with industry standards.”

Sustainable and greener solutions

Carbon footprint emissions have become an important topic across the world, and IT is playing a significant role here. Old on-premises legacy systems consume more power, leading to higher demands for more space. That being said, organisations may not opt for a data centre with low CO2 emissions electricity. Additionally, recent solutions, including in-memory HANA systems, also requires more electricity to run. By downsizing and retiring obsolete systems, as organisations, you will be contributing not just to the environment but also support your company’s sustainability initiatives. 

Download our ebook now to learn how overall data management contributes to sustainability:

Important things to consider before legacy system decommissioning

The overall decommissioning process can quickly become time-consuming and tedious if key factors are not considered by your organisation, because there are several factors that organisations need to consider. Here are some of the key things to consider before starting with both non-SAP and SAP legacy system decommissioning –

Data extraction

One of the foremost things that you need to keep in mind is what information to extract. You want to scope in data, documents, as well as reports, to ensure 100% extraction of the content of your legacy application. From a tax point of view, documentation, including code, is to be kept, but those are the easiest part. Extraction phase includes the transferring of data from the obsolete systems to a storage repository that remains selectively accessible for future compliance. In fact, there are several solutions like TJC Group’s ELSA Extract that target 100% legacy data extraction into tax archives (please note some data is stored in a format where 100% may not be fully achieved, but we managed to work on most important parts to provide you with solutions). You also have many solutions, including several open-source solutions, allowing for data extractions from hundreds of non-SAP systems.

Access to legacy data

While SAP decommissioning is quintessential for organisations, it is equally crucial to retrieve legacy data for legal & tax compliance, and it may be even more important to provide personal data protection compliance. Also, bear in mind that new users are unlikely to be familiar with the old systems. Therefore, it becomes quite imperative that organisations undertake solutions that has simple and flexible interfaces anyone can quickly learn to navigate. Overall, this helps in ensuring that legacy data after decommissioning remains accessible only to authorised personnels.

On the other hand, legacy systems applications are not live applications, so they are not designed to copy the original legacy system display: this would end up in overcomplicated system and in intellectual property applications infringement. So, ELSA generic and flexible look and feel is a perfect fit for large scale system decommissioning.

Data security

Possibly one of the most essential aspects, data security cannot be missed at any cost. Organisations have to ensure proper protection of data and encryption of sensitive information while decommissioning legacy systems, during the process and after, so the data is never exposed. In fact, ensuring the security of the system itself is also an important point to consider, including security of all the access points and protection against any potential vulnerabilities.

To name a few, the data security checklist includes the following –

• Ensuring complete extraction
• Making sure that no transformation takes place at extract time. However, ETL and ELT are not perfect solutions here.
• Maintaining classical end-to-end encryptions
• Proper user management
• Accurate authorisation management
• Audit report, at extract time or any time after (including several years after decom took place)
• Ensuring tax extract traceability
• Making sure of the management of legal users

Step-by-step guide to SAP & non-SAP legacy system decommissioning

Standard steps for decommissioning

From afar, decommissioning might feel like just turning off a system. However, it is more than that; decommissioning involves a meticulously planned structured process, ensuring accessibility, integrity, and security of data. Given below is a step-by-step approach that organisations must follow for non-SAP and SAP legacy system decommissioning –

Detailed planning and assessment

The foremost step is to ensure a robust, simple, but detailed planning and assessment, which includes, in a classic method, inventory systems, data classification, and so on.

• Under inventory systems, organisations must identify the legacy systems that need decommissioning, including that data stored in the systems, their applications, and dependencies. Time constraints and requirements must be clearly outlined for each system to schedule the whole program accordingly.
• Under data classification, you have to categorise data into business objects. Post which, you must classify objects as per their functional importance, regulatory requirements, and sensitivity.  As a matter of fact, TJC Group helps with data classification.

However, keep in mind that classical method is efficient for document management systems, and for systems with up to 200 tables, far from current systems complexity. Therefore, TJC Group’s decom solution focuses not just on data classification but on the database model, providing it automatically for SAP systems. For non-SAP systems, our technology will build metadata for you, based on experience, and on proprietary Agentic AI.

Apart from this, the planning and assessment phase also includes stakeholder engagement, wherein you must collaborate with IT teams, compliance and business units, and clients to define goals and objectives. Bear in mind that, during the planning phase, you must identify key business objects that should remain readily accessible after both SAP & non-SAP decommissioning.

During this phase, you need to check for your assessment targets – i.e., what exactly are you looking for –

• Do you want to target operational requirements?
• Are you looking to target tax archives?
• Do you target answering audits, quality control or compliance?
• Do you plan on targeting conservation for future AI usages?
• How do you stay compliant with current and future regulations such as data privacy and so on?

Apart from these, another question that pops up often is what standard and custom report should one run and keep before decommissioning? The answer to this that some reports (mainly financial, HR, and compliance related) should be kept; however, they may not be reproduced in a legacy application. Furthermore, assessments related to tax archive means you should target a complete data extract, not just financial data. 

Having said that, keep in mind that assessments also relate to volume issues: xml storage, as an example, will generate 10 to 100 more volumes than AIS format. Both may be compressed but what about the legacy system decommissioning partner’s bill on uncompressed format?

Lastly, assessments on risks are also important; what if certain data is not accessible within the application later on? This point is important as too many project focus on the duration of the process, but not on consequences of a partial decommissioning project.

Migrating data and implementing archiving

There are a lot go misunderstanding in such area, and this is a good time to address some of these misconceptions.

The gist is that archiving means many things; they vary from person-to-person: data archiving, document archiving, tax archiving, and full (decomm) archiving.

An important example of data archiving is as given below. Click on the banner to get in-depth insights into our processes and more.

If you ran data archiving in an SAP legacy system, archived data need to be extracted too as system decommissioning involves data extraction and archived data extraction. Doing both, you need ensuring that integrity is maintained. This implies identifying duplicates (a same invoice number may be found online and in a data archive file), segregate true and false duplicates, and exclude some outdated data.

Sometimes, streamlining the migration process is key: running data archiving before or during migration project, setting up a decommissioning workspace as an archive repository (secondary archive), Sometime, streamlining the migration process includes making decommissioning project separate, or organise a-carve-out based SAP legacy system decommissioning.

Additionally, many include data cleansing as an important part of their migration project, and this is true. However, data cleansing is not part of decommissioning project because decommissioning targets the access to a legacy system, and in no way an improvement of legacy information. If you build a data pipeline in your data lake, then extracted data from application may have to be cleaned for a dedicated usage: if your data pipeline then run from a legacy application (after application decommissioning), then you will, again, run data cleaning. But legacy applications do not target cleansing. That being said, data cleansing is legally required as a right to update personal information. Not only during SAP decommissioning but at any time in the future: it must be possible to trace while keeping the tax archive status.

Data availability and compliance

With SAP & non-SAP decommissioning, accessibility to archived data is non-negotiable. Why? Well, as mentioned before, data must be retained for a specified period for compliance with legal and data protection requirements. However, you have to ensure that the data access remains limited to authorised users only. Apart from this, you also must ensure that the data is in accordance with the industry-specific and retention compliance requirements.

SAP decommissioning and system deactivation

As part of the project, TJC strongly recommends running a battery of end-to-end tests side by side between your legacy system and the solution you selected to access this data, like ELSA by TJC. Not only is this an obvious stage to go through from a technical point of view, but it also is a great opportunity for business users get familiar with the new data access solution and confirm all business requirements have been met. The legacy system can then safely be retired. This may sound as a complex and time-consuming task, bur remember we target full extract, so it’s ok if some tests are missing. Also, these are tests to access information, not to reproduced existing processes (i.e., display a sales order, not an end-to-end process from creation to payment)

Monitoring post the decommissioning process

Post decommissioning SAP & non-SAP legacy systems, it is imperative to continuously monitor the data not just for accessibility but also for security against cyberattacks and breaches. Also, maintain detailed records of the decommissioning process to ensure audit readiness of your data and organisation. At TJC, this is already covered within our cloud application ELSA, for which our customers automatically benefit from, with regular security updates for instance.

Want to know what is audit readiness of your data? Head on to this link: https://www.tjc-group.com/sap-data-extraction-for-tax-and-audit-readiness/

Steps followed by TJC Group experts for decommissioning

In our continuous efforts to thrive and ensure the best for our clients, we follow a strategic approach to legacy system decommissioning, further streamlining the process and yielding the excellent results. So, in addition to the standard steps for decommissioning (including extracted reports, attachments, documents, and documentation), here’s what our experts do for you on the data side –

Database analysis: We list all the tables, volumes, table fields, and datatypes. Optionally, we may identify potential personal and sensitive data on standard and custom tables.

Data dictionaries: Target here is to identify metadata that will define how ELSA performs on extracted data. We represent data dictionaries as a set of 8-18 tables, comprising of metadata related to the data model. Depending on the legacy system, this kind of tables may already exist (as for SAP NetWeaver based decommissioning: ECC, CRM, SEM, EWM, IS-U, etc.), or they can be recreated from scratch. As building such dictionaries may seem a complex task, we propose fixed price services for building them on non-SAP systems, based on TJC Group expertise and proprietary agentic systems.

Extractions: Post the analysis of the database and data dictionaries, we launch the extraction of all the database tables and documents. Special case where data is encoded in proprietary format may be addressed when important. For some of the largest ERP system (some of them reached close to 100 Tb, or when customer do not own the original system (M&A processes), we may need to carve out the data and include a formal approval process.

Audit of data quality: In this step, we ensure document completeness and traceability to stay on par with compliance.

Common challenges of keeping legacy systems

Often organisations overlook the benefits of legacy system decommissioning, and wonder can decommissioning really help in saving costs?’. While the project cost may seem like a tad bit on the higher side, it is just a one-time expense that comes with several advantages. However, it is common for organisations and decision-makers to question such things, and rightfully so – maybe, they are unaware of the limitations obsolete systems come with. So, let’s break down the challenges of keeping legacy systems and why SAP & non-SAP decommissioning is a smart choice –

Higher cost of maintenance

One of the biggest challenges of not performing SAP decommissioning is the cost of maintaining the legacy systems. You would be surprised to know that for every legacy system, there are 49 different cost implications; maintenance fees for software and applications being the most significant one. Second to this, comes the impact on operations with IT systems tied up in managing obsolete systems. Furthermore, organisations can incur this expenditure across multiple legacy systems, as they may be implemented across several divisions within an organisation.

In addition to this, there are also operating system’s licensing cost, cost of the database (whether HANA or others), and cost of SAP license renewals. All these combined together increases the maintenance cost of the legacy system significantly. As a matter of fact, even if the legacy systems are unused, organisations have to maintain their application, putting greater pressure on the technical teams as well.

Cost of maintenance are high, but the sad truth is legacy systems, at some points, just may not be maintained, regardless of the cost you’re ready to pay for. This is even more obvious for more recent SaaS and cloud applications.

Technical debt

Another significant challenge faced by organisations opting out of SAP legacy system decommissioning is managing technical debt. Simply put, technical debt is the cost of revising a solution that arises from opting for a quicker, simpler approach instead of a more effective but time-consuming one. Similar to financial debt, technical debt accumulates interest when left unresolved, making future changes more difficult and costly. Over time, this can increase software entropy and further elevate rework expenses. Moreover, it hampers a company’s ability to innovate and adapt to new developments.

Several factors contribute to the accumulation of technical debt, including poor documentation, the absence of test suites, tightly integrated components, and failure to update components that may no longer be supported. Legacy system decommissioning is a solution that can help reduce your technical debt since it will retire old application in which it was accumulated and replace it with state-of-the-art debt-free cloud technologies in the case of ELSA by TJC Group.

System failure

One of the most concerning things associated with legacy systems is the risk of system failure. This is particularly extremely challenging in sectors like industrial production and healthcare, where disruptions can lead to substantial revenue losses. Such substantial revenue losses are also incurred with legacy system: just one example, if your product is an airplane part, and one plane crash after 25 years of service, you’ll need the quality control information (data and documents) that may resides in a legacy system. Beyond that, the loss of a legacy system may result in financial penalties, especially during tax audits. Therefore, ensuring minimal disruption while phasing out legacy systems is essential. Organisations should prioritise a smooth and seamless transition to mitigate risks effectively.

Vulnerable to cyberattacks and breaches

It is often misconstrued that obsolete systems are not affected by new vulnerabilities as they have reached their last update level and cannot be exploited. However, it is far from reality! Any new vulnerability discovered in a library will affect all the current as well as, possibly, past versions of that library. In fact, there are several examples of the same with the recent vulnerabilities CVE-2023-38545 and CVE-2023-38546 affecting the URL library. Therefore, organisations must have a backport of corrections to the source code of the earlier versions to ensure quick restoration, business continuity, and overall security. However, the process can be tedious and time-consuming, leading to several incompatibilities. Hence, maintaining legacy systems, even the one with updated patches is a risky affair and can lead to serious breaches.

All these challenges can create disruptions in your business and operation strategies. Therefore, non-SAP and SAP legacy system decommissioning while transferring their data to a more robust, modern, updated, and secured systems is always a good option.

Tools for SAP legacy system decommissioning

As strategic and beneficial legacy system decommissioning is, the process can be a tedious and complex one. Therefore, not just the best strategies, but you also require meticulous tools and techniques to ensure that your system decommissioning process goes smoothly. There are several solutions that organisations can opt for to decommission their systems – both SAP and non-SAP systems. However, accessing extracted data smoothly seems to be a challenge with several of the SAP legacy decommissioning tools. So, is there any solution or application that can solve this challenge? As a matter of fact, there is!

Introducing the smart Enterprise Legacy System Application (ELSA) by TJC Group

As experts in data management, we understand the importance of having simplified and streamlined solutions – because, let’s face it, we generate vast amounts of data on a daily basis, and extracting them for decommissioning is a time-consuming task. Hence, we have come up with a solution – the Enterprise Legacy System Application or ELSA, built and certified with SAP Business Technology Platform (SAP BTP). You don’t need to be an SAP customer for using it, but you will benefit from SAP open technology (SAP BTP run on open-source cloud foundry architecture). It is a cloud-based application that works with major hyperscaler and could be adapted to work with any smaller actors such as OVHCloud. ELSA also runs with on-premises storage, ensuring that the extracted legacy data is stored securely. Needless to say, it may be purchased as a full SaaS solution, if customer prefer. One of the (many) unique features of ELSA by TJC Group is that extracted data can be easily re-accessed both before and after migrating to the new ERP or S/4HANA systems. The cloud-based application, therefore, helps remove the expense of retaining the SAP legacy system, thereby decommissioning it.

A little in-depth about ELSA for legacy system decommissioning

ELSA directly addresses the key challenges of retiring obsolete systems. The solution’s architecture strikes a balance between advanced capabilities and practical, real-world application. As a matter of fact, organisations can deploy ELSA with data and/or databases hosted either on-premises or in the cloud, depending on their infrastructure needs. Moreover, Enterprise Legacy System Application (ELSA) by TJC Group supports both SAP & non-SAP decommissioning of legacy systems, eliminating the usual complications of managing data across multiple sources.

ELSA’s design: ELSA provides generic display (customizing without coding) and works with non-SAP and customs systems. However, at the core of ELSA’s design lies seamless SAP integration. This is good as SAP systems are usually the more complex systems in large organizations.  Comprehensive audit trails ensure all actions are fully traceable (lineage), while strong privacy controls guarantee compliance with data privacy laws, like GDPR, Loi25, DPDP in India, CCPA in the US, and so on, without compromising data utility.

In fact, ELSA design ability to be simultaneously a tax archive and to allow data privacy (including surgical destruction), is a core design, relying on a TJC Group patent pending solution. There is no equivalent on the market, to our knowledge.

Migration integration: The ELSA platform allows legacy system decommissioning to be separated from migration project. This is a major feature as interlinking a migration and a decomm project usually leads to poor results on both sides. That being said, once the decommissioning strategy is clear, ELSA may also align with project transformation maps to keep migrations running smoothly. As an example, ELSA may serve as a practical solution for some Mergers and Acquisitions (M&A) scenarios.

Functionality: When data is transferred into ELSA, nothing is overlooked. The platform captures and preserves the entire spectrum of business information — from database records to supporting documentation. Automated checks validate data quality at every stage, and audit logging provides a complete record of the journey from source to destination. This truly makes ELSA one of the robust and strategic SAP legacy system decommissioning applicationplatform.

Security: One of the most sought-after factors about our cloud-based application is that security is embedded throughout ELSA’s architecture. TJC Group is ISO27001 certified and ELSA’s development cycle is included in certification scope. TJC Group follows the latest security best practices, guidelines and protocols, and undergoes daily vulnerabilities checks and end to end test. TJC Group also go through regular VAPT (Vulnerability Assessment Penetration Testing) conducted by a third party.

As a matter of fact, we also have data masking features that operates with precision at the field, table, or transaction level to safeguard sensitive information. Moreover, after SAP & non-SAP decommissioning process, users are granted access to data strictly according to their role — no more, no less, through precise authorisation management at application level. Every system interaction is logged and stored securely, meeting enterprise-grade standards.

ELSA’s interface: ELSA’s FIORI-style interface (UI5 technology) delivers both familiarity and efficiency. Business teams can explore their data and attachments via pre-configured transactions, static reports, text to SQL queries with gen AI, and dynamic reporting, while technical users benefit from advanced reporting features, including custom queries, SQL queries, API’s, etc. This dual-layered approach ensures all users remain productive within their areas of expertise.

All in all, ELSA redefines how organisations perceive their legacy data. Historical records become a valuable resource for fresh insights, rather than a burden. The cloud-based application preserves vital links between data points, unlocking new possibilities for AI projects and business intelligence strategies that fuel meaningful growth. In addition, your analytic processes, such as your data lake, may remain available: ELSA just replaces the legacy application as a data source.

What makes ELSA stand out from the crowd?

In general, most times data migration to S/4HANA from old ERP systems doesn’t guarantee and often doesn’t prove that the existing data remains unchanged or complete; but ELSA does, and that’s what makes it stand out from the crowd. This cloud-based application protects and future-proofs legacy data and makes them easily accessible from either S/4HANA, a UI5 web application, or any current technology-based application. Also, note that ELSA by TJC Group is designed in a way that it stays on par with compliance pertaining to all the future business needs and international data privacy laws. Moreover, ELSA readily converts legacy data into AIS formats i.e., flat files, enabling data to remain unchanged during migration, but also for the rest of its lifecycle.

For clarity, AIS is the SAP audit format, filled with metadata and remains accessible. It is not a volume consuming format (it’s about 10 to 100 times smaller than an XML format for SAP data). We still compress it, and several encryption processes apply (either end to end encryption or line-based privacy encryption), but this is one of the perfect formats for decommissioning. Our ELSA for legacy system decommissioning is fully compatible with other industry-specific SAP solutions as well as non-SAP systems.

ELSA seamlessly helps in system decommissioning from SAP systems, remarkably revolutionising how businesses access their historical information. Furthermore, the cloud-based application is developed with the robust SAP UI5 framework, deployed on SAP BTP Cloud Foundry, solving SAP & non-SAP decommissioning challenges.

The agile advantages

Right from the development of this SAP system decommissioning solution, ELSA marked an unwavering commitment and dedication to agility. ELSA has adapted an agile (like DevOps) methodology that has helped delivered extraordinary results in the SAP & non-SAP decommissioning process.

Rapid iteration and continuous enhancement

The core principle of agile solutions is sprinting based organisation and rapid iteration that is precisely embodied in ELSA. The iterative approach that this cloud-based application follows ensures in enhancing the entire SAP legacy system decommissioning process. In fact, this approach allows us to respond to the ever-changing customer requirements and market dynamics.

How to decommission SAP legacy systems with ELSA?

Considering the significant financial commitment involved with S/4HANA, system decommissioning should not capture much of move to S/4HANA effort. In a perfect world, migration and decommissioning are mostly decoupled. As high level resources will focus on building the new S/4HANA system, choosing a system decommissioning partner offering applications that are managed with low overhead, being future-ready while providing easy access to legacy data becomes increasingly crucial. With TJC Group’s Enterprise Legacy System Application (ELSA), organisations can avail the advantage of easily accessing data with just a click. This is primarily because ELSA integrates data from various systems and sources – whether legacy, archived, or live, ensuring its accessibility. Hosted within SAP BTP’s Cloud Foundry environment, ELSA safeguards your investment while helping reduce future ownership costs.

So, to answer how to decommission SAP legacy systems with ELSA, we follow these strategic steps:

• As a first step, we extract “100% data” from the legacy systems to be decommissioned and save them as tax archives (AIS files).  “100% data” means completeness may be claimed from tax and business point of view. We agree all applications may store information in a proprietary, non-accessible, format, and that, for the most part, this will never be a problem.
• After the data is extracted, we store these extracted AIS files in the cloud – like AWS, Azure, or GCS storage, smaller storage providers (such as OVHCloud) or on-premises file systems, as per the preference of the client. They will always remain available to the customer for any future needs and requirements.
• Once we securely store the data, the next step in the SAP decommissioning process is to import relevant or business-critical data from the AIS files into the ELSA database of your choice. We offer a range of databases that you can choose per your requirements like the SAP HANA database (on-premises or cloud), Oracle Heatwave, MySQL and PostgreSQL. We may add more database, if requested at any given point in the future; more data can be imported from the flat files if needed without having to supercharge the database.
• Lastly, authorised personnels and end-users like the tax and audit team can access important data with the help of ELSA via S/4HANA Fiori App, low-code, no-code solutions, or any of the current technologies while securely retiring and shutting down the legacy system, all thanks to the ELSA APIs provided with the solution.

SAP Information Lifecycle Management for legacy system decommissioning

SAP ILM (Information Lifecycle System) has three pillars –

Data archiving: This part is for reducing the system size and increasing system performance. On S/4HANA and HANA systems, it also helps reducing memory costs.

ILM RM: This part, RM, as Retention Management, is now used mostly for data privacy requirements. It’s an evolution of classic data archiving, introducing retention rules and data destruction, as several other features

ILM WM / LTRS: This is the part designed to decommission SAP applications. It uses some solutions that are also used for SAP Landscape transformation.

While SAP ILM cannot be touted as SAP legacy decommissioning tools per se, it is a strategic solution from SAP that helps in handling system decommissioning with ease. SAP Information Lifecycle Management or SAP ILM offers the following functionalities that makes the decommissioning process much smoother and streamlined –

Tools and techniques: SAP ILM comes with several tools and techniques that helps with archiving the data that enables to move the data from the database of legacy systems to SAP archive files. There are two major benefits that the ILM archived files offer – the first one is reduced size of the data due to compression; the second one is that the data remains in “read-only” status, fulfilling audit requirements of keeping the data unchanged.

Archiving metadata: Another feature of SAP ILM for legacy system decommissioning is that it helps archive metadata along with business data. But what does this mean for organisations? As a matter of fact, this happens to be an important technical capability, allowing SAP ILM to cater to several legacy systems with different releases.

Retention management: SAP Information Lifecycle Management’s core capabilities of applying data retention rules effectively helps in streamlining the decommissioning process even more. In fact, SAP ILM applies the retention rules to the archived files from the legacy system data, making it possible to comply with data destruction requirements as well.

Storage system interfaces: For SAP legacy system decommissioning, ILM provides interfaces that helps store the archived files in different formats of the storage systems. WORM-based system is a classic example of the interfaces provided by SAP ILM. Furthermore, SAP IQ, Hadoop, and a consulting approach supporting Microsoft Azure BLOB storage were also added to the SAP ILM interfaces. Since 2018 and GDPR (European data privacy regulation), historical WORM based storage are non-preferrable as they aren’t built with destruction abilities. In fact, Hadoop is a declining technology, and SAP IQ usage has become quite limited in practice.

DMLT approach for decommissioning with SAP ILM

Data Management and Landscape Transformation used to fall under an SAP service that ensures a holistic approach to all your data management domains, such as data integration, data compliance, data quality, and so on. They now may be provided by partners as TJC Group. Overall, ensuring these data domains are essential when opting for SAP decommissioning. Let’s understand the process and the flow of data for the same –

Legacy systems: The fact of the matter of is that legacy systems run on older releases and less powerful hardware. With the DMLT approach for SAP ILM decommissioning, organisations can make sure that minimal activities run on the legacy system. Here, the only requirement is to have an “add-on” installed, which can handle the cluster tables. The “add-on” is flexible in terms of availability and accessibility for older releases.

SLT systems: SLT systems stands for SAP Landscape Transformation Replication Server, which is a solution from SAP that comes with data replication capabilities. As far as legacy system decommissioning with ILM is concerned, the main concept here is to replicate the data from the obsolete system into the SLT system. Post which, data archiving comes into the picture. As a matter of fact, SAP data archiving serves as a good strategy to adapt before decommissioning the obsolete systems as it helps retain important data for the specified time while streamlining the system retiring process.

ILM Retention Warehouse system: Once all data, including metadata, is archived in the SLT system, the metadata of the archived files is transferred to the ILM Retention Warehouse (RW) system. The actual files (containing the data) are then moved from the SLT file system to a designated storage system. Several storage options are available, including WORM-based systems, cloud platforms such as Hadoop, Microsoft Azure (via a consulting solution), or SAP IQ.

All in all, to retrieve data and generate reports, two primary tools are available: local reporting and accelerated reporting. Local reporting provides straightforward, ad-hoc access to individual tables or views from the legacy system (plain table display, like SE16N equivalent). Accelerated reporting, on the other hand, allows for the creation of dynamic database tables within the ILM RW system and stages data from the relevant archive files into these tables. The structure of these generated tables mirrors the original format of the corresponding database tables in the legacy system. Bear in mind that, accelerating reporting means you need to code everything yourself, in a system with limited functions available, as it is a NetWeaver system, not an ECC system).

Unified approach for legacy system decommissioning for SAP and non-SAP environment

SAP NetWeaver (NW) ILM offers a unified approach for SAP & non-SAP decommissioning through the use of SAP SLT (System Landscape Transformation), the Legacy Extraction Workbench (CDE archive objects), and the SAP ILM Retention Warehouse, utilising ILM-certified storage based on Sybase IQ, SAP HANA, or any SAP-certified ILM store (TJC Group was first to propose regular storage for such feature).

The typical SAP legacy system decommissioning process includes the following steps:

• Data profiling
• SLT extraction
• Configuration
• LEW extraction
• Data transfer and storage
• Data retrieval

To elaborate on the steps:

• Conduct data profiling to determine the scope of the data and tables to be archived.
• Extract and load data from the legacy system into mapping tables within the target SLT environment using SLT.
• The mapping of non-SAP content to SAP structures can be adjusted as needed to prepare for accurate reporting and proper data presentation later in the decommissioning process.
• Configure the Legacy Extraction Workbench (LEW) to define the relevant archiving objects.
• Define audit areas, ILM policies, and retention rules; then execute a LEW run to generate archive objects in line with those rules.
• Transfer the archive files to the SAP ILM Retention Warehouse and store them in an ILM-certified storage system, such as Sybase IQ, or just in file system or blob storage.

The metadata of the legacy tables is transferred using special archiving objects, which allow the metadata to be retained within the ILM Retention Warehouse (RW) for retrieval and reporting purposes.

Retrieval and reporting

When it comes to the newer version of SAP NetWeaver ILM for SAP & non-SAP decommissioning, it delivers improved reporting that helps address several legal and audit reporting requisites. In fact, there are multiple reporting options like local reporting, accelerated reporting, and BW reporting.

Furthermore, ILM provides choices for different reporting needs as follows:

• Use pre-delivered/existing BW content or check out increasingly available HANA content
• Use available BO portfolio and existing export functions (AIS)
• Choose between basic (local) reporting or complex queries based on (easy) modelling
• Load only data that is needed for the reporting purpose

Comprehensive

• Extend the scope of reporting by SAP HANA (e.g. open items without sec. indices
• Report both live SAP and legacy data (SAP and Non-SAP data), support new scenarios (e.g. partial migration/conversion), etc.

Best practices to follow for SAP & non-SAP decommissioning

As organisations you are aware of the deadline for S/4HANA migration. For the unversed, keep in mind that SAP ECC and its older versions will be replaced by SAP S/4HANA by 2027. Therefore, migrating to a newer, more efficient landscape is an advanced future that organisations will embrace. However, what will happen to the older systems after the migration is complete? Well, after the migration to S/4HANA, there will be two systems – an old one and a new one.

The new system

This system will be in the productive status. The system remains accessible on a daily basis by business users to manage operations and activities.

The old system

This system remains in “on-read-only status”, which happens to the SAP ECC or older systems. The system remains accessible to authorised users in read-only mode, accessing only important information needed for operations and tasks. The user authorisation changes from time-to-time to ensure the continuous possibility of read-only status.

With all these factors weighing in, implementing the best practices for both non-SAP and SAP legacy system decommissioning becomes top priority. Here are some imperative practices to follow to decommission legacy systems –

Plan your decommissioning project

One of the best strategies to ensure a smooth legacy system decommissioning project is to develop a strong plan. Keep in mind that the decision to decommission obsolete systems requires communication with several departments, which is why having a strong and comprehensive vision/blueprint is a good idea. Moreover, when planning your decommissioning project, ask yourself these following questions:

• Where will the data get stored after the system is decommissioned?
• Will a new application replace the decommissioned legacy system?
• How long will the SAP & non-SAP system decommissioning project take, and so on?
• Do I ensure security and compliance for the future?

Discuss with your team in-depth about the project, review every aspect, because decommissioning will not just impact at an organisational level but also financially. Therefore, a step-by-step planning of the project is required.

Choose an architecture per your IT landscape

A mistake that organisations often make is choosing an architecture that may not completely fit the IT landscape. An SAP legacy system decommissioning project includes rearchitecting, rebuilding, as well as replacing the old IT landscape, which may lead to newer and more enhanced capabilities. Carefully analyse the architecture before implementing it into your IT landscape. That said, it is advisable to select an architecture that fits within your existing/target environment to avoid additional efforts during the project and after for maintenance. However, regardless of a new or restructured architecture, map it based on the functionality, technology, cost, and risk. Therefore, ensure to weigh all the options to identify the process requiring minimum effort but will deliver maximum positive impact and results.

It is important for to be flexible with the solutions, regardless of your architecture. Within TJC Group, we refer to ‘ELSA to ELSE’ process: being able to move from ELSA solution to something else when you want or need it. Interestingly, this can be called as an “exit path”, which will always exist at TJC Group. However, when selecting an exit path, keep in mind data from legacy systems are not quite ‘dead data’: such data is accessed, and traceability/lineage is enforced with data being deleted/redacted from time to time for privacy. The ELSE process not only provides you with original extract but also provides you with evolution while data kept as a legacy.

Extracting data from legacy system

As mentioned in Section 3.1, data extraction is an important part of SAP legacy system decommissioning. Simply put, data extraction is collecting and retrieving an array of diverse data from the legacy systems that needs decommissioning. As a matter of fact, extracting data from the obsolete systems is necessary because it helps consolidate, process, and audit data that must be stored in a centralised location. Keep in mind that the location can be on-site, cloud-based, or even a hybrid of the two.

Check the accuracy of the extracted data

Yet another best practice to follow for a seamless SAP decommissioning is to check the accuracy of the extracted data. Prepare an audit report to ensure the completeness and integrity of the extracted data. It will confirm the accuracy of the data between the source and extracted files. Not just that, the audit report also demonstrates that the planned data set for extraction was indeed extracted while remaining unchanged, qualifying as tax archives.

Needless to say, audits may be performed by internal or external auditors, and they can be expensive. Fortunately, TJC Group includes audit report feature to ease the process and allow for internal process. With all respect to auditors, to be sure we did not miss anything, TJC Group issues audit reports at the end of the project as part of our standard methodology.

Upload data into the system

After extracting the data, you have to upload them into the storage system that can be the cloud, on-premises, or hybrid. As a matter of fact, it may include storing data or applications from an on-premises setup to the cloud or transferring them between cloud environments. Notably, with the rapid growth of cloud storage and migration, most corporations are expected to operate entirely on the cloud within the next few years.

Anticipate user requirements

Business users may have new requirements once the legacy systems are retired. So, as a part of a smart strategy for SAP & non-SAP decommissioning, ensure to define the scope of data extraction to avoid missing out on any relevant data, documents, attachments, or reports, for that matter. Therefore, while deploying the project, make sure to anticipate the requirements of the users to help limit any unexpected custom requirements and save any additional costs.

At TJC Group, we favour 100% extract of accessible non-empty tables data, documents, or even attachments from the system to be decommissioned. All businesses have to do is decide on standard or custom reporting output, which they want to see once the system is retired.

Typically, full or 100% extract means data and documents will be available when we need them and so anticipating each and every question is not necessarily important. Could anyone anticipate questions that arose when the world faced Covid-19? Or could anyone anticipate tariffs will be a big topic for analysis in 2025? At TJC Group, we believe anticipated questions may be used for testing and challenging a new legacy system decommissioning solution, but these solutions should be able to handle unexpected questions, which may arise when legacy systems are already gone.

Implementing automation and specialised tools

As the world advances towards more automated solutions, implementing tools powered by process automation, artificial intelligence (AI), and machine learning (ML) is a strategic practice.

By using automation, you can streamline SAP legacy system decommissioning as it reduces manual efforts, improves accuracy, and ensures better compliance. TJC Group first software solution, named Archived Session Cockpit (for SAP data archiving), was for archiving automation (not just scheduling), and it became common for us implementing as much automation as we may.

ELSA includes many hidden automation processes that makes a difference when performing decommissioning projects. As an example: main business tables in use and customising tables are suggested by default as being imported in the database. Hundreds of generic transactions are automatically setup at system start based on SAP tables in your system (including custom tables). Hashkey and lineage are checked and stored automatically in a transparent way. Moreover, leveraging AI-powered tools help classify and categorise data based when decommissioning non-SAP systems and custom systems.

Risk management and mitigation

Risk management and mitigation are crucial practices for both SAP & non-SAP system decommissioning as it helps ensure data integrity, regulatory compliance, and business continuity. Following are the potential risks that you need to consider and how to mitigate them –

Loss of data or corruption

Risk: Data critical to businesses may be lost, corrupted, or inaccessible during the decommissioning process.

Mitigation: Ensure comprehensive data backups before starting the process. Additionally, implement data validation tools and use incremental archiving to reduce errors during data migration.

Please note that loss of data or corruption are only an issue when they are created during or after the decommissioning phase. When data has been lost or corrupted back in the legacy system and TJC Group identify it, then it is enough to document it for reference.

Compliance and legal aspects

Risk: Failure to meet legal and regulatory requirements during the process, and, more importantly for the years to come.

Mitigation: Develop data retention policies aligned with regulations like the GDPR, SOX, HIPAA, and so on. Implement SAP Information Lifecycle Management (ILM) to automate compliance management, maintain audit trails and generate automated reports, and collaborate with legal and compliance teams. As a matter of fact, TJC Group’s cloud-based decommissioning solution, ELSA, is created in a way that it implements the requirements of data privacy.

Firstly, a non-SAP or SAP legacy system decommissioning platform needs to be a native tax archive or generate two datasets: one for tax archive and one for business. TJC Group offers a single extract fulfilling all requirements. Then comes the data privacy compliance matter. Here, ELSA can be used as an intermediate/definitive archive connected to a live system.

Live ERP systems must comply regulations like the GDPR, law 25, SOX, HIPAA, and so on. SAP solution is Implementing SAP Information Lifecycle Management (ILM RM). Retention management allow for integrated and massive data destruction based on retention rules and data retention policies. Using only such a feature is not good enough as when a system is replaced, process is no longer updated, and rules may no longer apply (delivery will never record a payment in legacy system).

ELSA will support data destruction based on SAP ILM RM implementation, but we also, and more importantly support surgical destruction, because data is gold and only personal data should be removed.

Data security

Risk: Sensitive data may be exposed during the legacy system decommissioning process.

Mitigation: Ensure encryption of sensitive data during migration and storage, as well as for data access in the future. Implement role-based access controls to restrict any unauthorised access. Additionally, use data masking.

Financial aspects

Risk: Uncontrolled costs from unexpected delays, resource allocation, or regulatory fines.

Mitigation: Create an in-depth budget and timeline with contingency buffers, prioritise decommissioning legacy systems that have higher costs, and regularly update stakeholders with financial reports.

By proactively identifying and addressing these risks, organisations can ensure a smooth SAP legacy system decommissioning process while maintaining compliance, security, and operational continuity.

Implementing legacy system decommissioning for S/4HANA migration

Retaining legacy data is not cost effective in SAP migration cases, arising the question of whether to complete a greenfield, brownfield or SDT (Selective Data Transition) implementation. To give you an honest overview – A SDT approach is possibly the best option in most cases, as SAP provides a roadmap for an SAP lean SDT, free of charge, with SAP Cloud ALM solution (CALM).

However, organisations may choose to start afresh and implement the greenfield approach, with no legacy data in the new database. As a matter of fact, this has been a pattern in an increasing number of scenarios in recent times. However, there are a few disadvantages pertaining to the greenfield approach, leading to users opting for the brownfield one instead. In the brownfield approach, a subset of legacy data will be entered into the new system for the purpose of tax and audit compliance.

However, in any case, SAP & non-SAP system decommissioning while retaining the ever-so-golden data is imperative. It is, often, a classic misunderstanding that the brownfield approach requires no decommissioning of the legacy system. A technical upgrade, or migration of legacy data into the new system doesn’t guarantee the completeness, traceability or integrity of the data, meaning the S/4HANA system cannot serve as a tax archive for legacy data. Of course, there are options like keeping the legacy system alive while co-existing with SAP S/4HANA; but it comes with significantly higher licensing and maintenance costs and with RISE, you may have sold back your ECC licence to SAP.

Additionally, there is another argument that freezing a system into a Virtual Machine (VM) will do the job at much lower costs. But again, it comes with high security threats. Moreover, after some years, the VMs will be completely obsolete, unpatched, and at higher risk, from security risks, but also from not starting at all.

Some cloud providers allow reducing cost by shutting down legacy systems. For systems being used by different persons in different time zone, it quickly becomes annoying. You have to boot the system every time an access is given to the business user, which is time-consuming. Anyway, unsecure and unpatched cloud application is never a reasonable solution.

Learn more on Virtual Machines here: https://www.tjc-group.com/blogs/virtual-machines-to-maintain-legacy-systems-a-good-or-a-bad-idea/

Therefore, legacy system decommissioning is truly a smart way forward as it not just simplifies the overall IT landscape but also streamlines the S/4HANA migration process, reduces long-term administrative and maintenance costs.

Watch our video on SAP® S/4HANA Update: SAP®ECC Legacy System Decommissioning to learn about a cost-effective approach to decommissioning of your legacy system landscape.

SAP legacy system decommissioning vs legacy system sunsetting

Over time, organisations tend to maintain obsolete ERP and non-ERP systems, despite the fact that it drains IT resources. So, why is retaining access to old data necessary?

• The first reason relates to compliance with legal and regulatory requirements
• Then, there are requirements for historical data for audit and tax purposes
• At times, historical data must also be accessed for urgent (and often unpredictable) business needs, or for future AI projects for instance.

For the same, there’s a process known as legacy system sunsetting. Unfortunately, many mistake legacy system decommissioning and sunsetting to the same thing. However, they are not!

Sunsetting a system has several definitions. In the finance world, it refers to the termination or phasing out of something – brands, partnerships, agreements, etc. However, in our world of IT, sunsetting means moving a legacy system from a productive status to a non-productive status. This means that while the system remains accessible for important information, it cannot be used for daily operations.

SAP legacy system decommissioning for enhanced data security

Security ranks high among the key risk factors. Organisations operating with legacy systems that are not properly maintained can be particularly exposed to attacks from hackers and cybercriminals — but that’s not the whole story. This article presents a real-life case involving a US company whose outdated systems were at the heart of a ransomware incident.

At a time when many existing SAP ECC users are considering the best migration path to SAP S/4HANA, there may be a temptation to ‘do nothing’ with legacy ERP systems. However, beyond the clear security concerns, there are numerous compelling reasons to engage experts in legacy system decommissioning.

Legacy data can pose a significant cybersecurity risk, particularly if it is not encrypted or lacks other access controls. If not regularly updated, legacy systems are highly susceptible to cyberattacks.

Keeping up with patches and system updates remains a significant challenge for IT professionals, as highlighted in the SAPinsider Cybersecurity Report 2023. Unfortunately, this is the daily reality for IT security teams managing SAP systems, with an ever-growing list of SAP vulnerabilities that must be closely monitored. Adding to this, these outdated systems can become vulnerabilities within the company IT environment, potentially risking other critical applications.

Legacy systems: The epicentre of data security breaches

Unfortunately, the attacked servers are likely virtual machines (VMs), particularly vulnerable when left unattended. But how are these obsolete systems or VMs targeted? The reason is most around the fact that the systems are neglected or unattended.

Stolen data from virtual machines are often key data: your product bill of materials, cost structure, are mostly valid even when a couple of years old. An outdated customer list with sales volume and pricing condition at SKU level is a dream for competition, even when they are some years old. What would you think if the group who sold you a corporation through an M&A leaks your data some years later? Will you take action or rather, could you actually take any legal action? Therefore, keeping a track of these VMs where legacy data may be stored is quite imperative for organisations.

If you read this article https://www.tjc-group.com/blogs/data-privacy-and-cybersecurity-why-decommissioning-is-the-safest-bet/, you will understand how the attacked organisation had no idea that legacy data was stored on its servers.

Not to forget, VMs are often considered to be a quick and feasible option to storing legacy data, but there are several flip sides to it. The three major pitfalls of considering virtual machines as a solution for SAP legacy system decommissioning are –

• Virtual Machines (VMs) do not offer adequate means to manage data privacy obligations, thereby exposing organisations to compliance risks.
• They often have a ‘dump and forget’ approach to information management. For example, once an employee leaves a project, retires, or moves on from the company, it becomes increasingly difficult to identify data that may pose a risk.
• Moreover, VMs are more susceptible to targeted ransomware attacks specifically designed to exploit these technologies.

Thereby, as it stands, leaving a server in “stand-by” mode ultimately proved to be a serious oversight. It was this kind of negligence in managing legacy systems that landed a renowned organisation in significant trouble. Legacy systems are no longer updated, nor do they receive support or maintenance. As a result, they are highly vulnerable to security threats — which is precisely why SAP & non-SAP decommissioning of legacy systems and servers becomes increasingly essential to safeguard data.

That said, pointing fingers and calling it ‘carelessness’ is too simplistic. For example, here is a valid question: how often do we back up data and servers over the years? With the shift to the cloud and the tightening of data privacy regulations, many practices that were once considered safe now pose unacceptable risks. This is why Legacy System Applications (LSAs) are increasingly becoming the standard today.

Avoid data breaches in your organisation with legacy system decommissioning

Firstly, let us consider the security implications of allowing legacy systems to run indefinitely. As you are aware, there are several vulnerability risks associated with it. Thereby, legacy systems become significantly more susceptible to data security breaches, largely because they may no longer receive updates or patches from their vendors. Even where vendors continue to provide maintenance updates, it’s not uncommon for organisations to stop applying them — often due to a lack of in-house expertise or because attention has shifted entirely to newer systems. This oversight leaves critical data highly exposed to cyber threats and remains one of the most frequent ways in which hackers penetrate corporate firewalls.

Data breaches are currently among the fastest-growing targets for cybercriminals. According to Professor Stuart Madnick of MIT, “data breaches continue to increase year-on-year, with a 20% rise recorded between 2022 and 2023.” A study published by the Harvard Business Review highlighted that one of the most common methods hackers use to gain access is by exploiting security gaps in vendor systems — particularly legacy systems, making legacy system decommissioning a crucial necessity.

Ensuring data privacy laws and compliance

In addition to the security implications, there are also compliance considerations when legacy systems are left unchecked – and these are equally critical. Continuing to operate outdated systems rather than decommissioning them can result in non-compliance with contemporary regulatory standards such as the GDPR. This leaves an organisation vulnerable to substantial financial penalties running into the millions of euros, as well as potential legal action from regulatory bodies. We have previously written about the significant financial risks associated with GDPR fines.

“Data protection within SAP systems is a matter of utmost importance. This focus is entirely justified, given the critical nature of the data stored in these systems – data which represents the core assets of a business. This includes vital information such as partner and customer details, financial records, transaction histories, banking links, and even personally identifiable information relating to employees.”

SAPinsider 2024 Buyer’s Guide to Cybersecurity

Let us also consider the financial aspect, as no article examining the consequences of retaining legacy systems would be complete without addressing the cost-efficiency implications. We are currently facing an IT skills shortage – one that experts forecast will continue to worsen. According to IDC, this growing shortage is affecting organisations across all sectors and regions. In a recent report, nearly two-thirds of executives surveyed indicated that the lack of skilled professionals had led to missed revenue growth targets, quality issues, and a decline in customer satisfaction. IDC predicts that by 2026, over 90% of organisations globally will feel the impact of this skills crisis, potentially resulting in losses amounting to $5.5 trillion. Get more information on how SAP & non-SAP decommissioning of legacy systems help reduce cybersecurity risks: https://www.tjc-group.com/blogs/legacy-data-and-legacy-system-decommissioning-to-reduce-cybersecurity-threats/

Cost considerations | The financial eyes of legacy system decommissioning

As we mentioned in our previous sections, keeping legacy systems will incur quite a lot of financial damages, which is why SAP legacy system decommissioning is necessary. In this section, let’s talk about the costs of maintaining a legacy system and how retiring them will help in saving your budget, while generating significant return on investment (ROI).

The main costs of maintaining legacy systems

While it is expensive to maintain legacy systems, it is even more complex to quantify exactly how much budget is being used on its maintenance. According to several new research reports, nearly three-quarters (74%) of manufacturing and engineering firms still depend on legacy systems and spreadsheets to carry out their operations, even in the aftermath of the Covid-19 pandemic.

Many organisations continue to pour significant amounts of money into supporting, maintaining, and running outdated software. For example, some banks and insurance companies allocate as much as 75% of their IT budgets to sustaining legacy systems. These costs escalate quickly due to challenges in routine system management, the need for specialised technical expertise, and, in some cases, expensive licensing requirements. If you sit back and think, couldn’t those funds be more effectively invested in modern technologies if SAP & non-SAP decommissioning is considered?

The hidden costs of maintaining obsolete systems

What’s interesting about keeping obsolete systems is that you can only see the major maintenance costs. But in reality, legacy systems come with several hidden costs alongside the obvious ones. The biggest mistake here by organisations – they do not associate these costs immediately with running legacy systems. In fact, this contributes even more to a false economy of the organisation.

Overall, the hidden costs of maintaining obsolete systems include

• accumulating technical debt
• overloading IT teams with outdated technology
• incurring expenses for redundant software licenses and security measures
• dealing with the environmental and sustainability impacts of running and powering old applications.

Additionally, there are considerable business opportunity costs. As highlighted in TCS research, 60% of companies still use legacy systems for customer-facing applications—often leading to subpar customer experiences and missed opportunities for new business growth.

Deciphering the decommissioning dilemma

This may sound like a poetic twist, but most organisations, even after learning about the costs of maintaining legacy systems, prefer keeping them. Why? Because of the initial costs of legacy system decommissioning. However, that’s just a one-time cost that you have to spend as opposed to the continuous cost of keeping legacy systems, which will only increase. Let’s help you understand about it a bit more in detail –

From cost to gain: Decommissioning costs as a long-term investment

Recognise the upfront costs associated with system decommissioning, positioning them as a strategic investment rather than a simple expenditure, and laying the groundwork for long-term financial gains, by making decommissioning a part of your overall IT strategy.

Economics of data migration: Striking the right balance in transition

Examine the economic factors involved in data migration during system decommissioning, with an emphasis on achieving the right balance between efficiency and accuracy to facilitate a seamless transition. Having a decommissioning process in parallel with a migration process, a separate one, will reduce migration questions and workload. Once its clear legacy information is safe and protected post migration, and you know where this information will be stored and how it will be accessed, then many migration topics get solved and no longer prevent you from focusing on your main target: building new applications for your future.

Strategic investments in the post-decommissioning era

Reallocating budgets: Post SAP legacy system decommissioning, organisations must ensure to strategically redistribute the potential resources, which majorly includes reallocating budgets. This phase presents a unique opportunity for organisations to channel freed-up resources into high-impact initiatives that fuels innovation, accelerates digital transformation, and unlocks pathways to sustainable strategic growth.

Capitalising on the post-decommissioning dividend: This may sound fancy but if simply put, it means you must invest in future-ready technologies. Examine how you can capitalise on the financial dividends yielded by decommissioning legacy systems. By reinvesting in cutting-edge, future-oriented technologies, businesses can establish a competitive edge, align with emerging industry trends, and future-proof their operations in an increasingly digital world.

The ROI of legacy system decommissioning: Evaluating success beyond immediate cost savings

When you look at the bigger picture, the ROI of SAP & non-SAP decommissioning goes beyond the immediate cost savings for organisations. There are several other financial benefits to it, mainly –

Measuring operational gains: Interestingly, you can see that there are tangible returns on investment, especially quantifying operational efficiencies gained through decommissioning. From streamlined workflows to reduced maintenance overheads, these improvements offer measurable returns—demonstrating a clear link between decommissioning and enhanced operational performance.

Enabling strategic alliances: Furthermore, the successful execution of decommissioning projects can lay the groundwork for strategic alliances. These collaborations can foster joint innovation, drive co-created ventures, and open the door to mutually strategic opportunities within and beyond the sector. Thereby, establishing a route for financial and business gains. When a corporation move legacy systems to ELSA solution, you may then connect ELSA with your analytic data pipeline and with your future AI solutions, bringing high quality historical data at your fingertip.

Bringing in automation, GenAI, and more into legacy system decommissioning

Embracing the future of SAP legacy system decommissioning

With automation and artificial intelligence at the heart of the industries today, there lies no doubt about their influence in the process of legacy system decommissioning. Here’s what the future holds for us in the decommissioning arena –

The robust integration of AI and automation

With the implementation of automation and artificial intelligence (AI), obsolete system decommissioning is set to revolutionised. Wondering how? Well, machine learning algorithms can analyse huge amounts of data can further help identify patterns and relations between the legacy system data model, hence allowing for user-tailored data displays. Moreover, the algorithms can streamline data migration, automate compliance audits, and much more. With the help of automation, it becomes easier for organisations to accelerate the SAP & non-SAP decommissioning process while reducing manual efforts, saving costs, and leveraging efficiency gains.

Adapting cloud-based solutions

The paradigm shift towards cloud computing also influences an organisation’s approach towards its system decommissioning needs and processes. The fact of the matter is that adapting cloud-based solutions will offer a plethora of benefits such as, scalability, easy accessibility, and flexibility when retiring obsolete systems. In addition to this, cloud-based solutions help transition data and applications to the cloud in a much seamless manner. That being said, the robust security features and built-in compliance controls of the cloud solutions are not to be missed. All in all, opting for cloud applications enables organisations to mitigate risks associated with SAP legacy system decommissioning. ELSA by TJC Group is one such cloud-based solution that organisations can adapt for easy, effortless, and efficient system decommissioning.

Exploring data-centric approach

Apart from cloud-based solutions, organisations are also moving towards adapting more data-centric approaches for their legacy system decommissioning processes. Big data plays a huge role in today’s economy; therefore, with a data-centric approach, organisations not just focus on retiring legacy systems entirely but prioritises data extraction, migration, and preservation as well. Moreover, data governance frameworks and advanced analytics tools help organisations identify business-critical data, ensure regulatory compliance while unlocking insights that drives business values.

Focusing on sustainable solutions

Well, this may not be related directly to SAP decommissioning per se, but organisations are opening up to more circular economy principles. As in, rather than disposing the decommissioned hardware and software, organisations are exploring options that can help reduce the impact since resources are shared in data centres, and also that getting rid of a set of individual legacy applications for a unified solution will also reduce technical debt, since all applications will share the same resources. All in all, this minimises the impact on environment while reducing waste and extracting additional value from the retired assets.

Collaborative decommissioning ecosystems

Effective SAP legacy system decommissioning in complex environments relies heavily on collaboration. Organisations are increasingly establishing collaborative ecosystems that unite stakeholders across IT, legal, compliance, and business functions to coordinate decommissioning efforts. By encouraging cross-functional engagement and open communication, these ecosystems help address challenges more efficiently and drive improved outcomes across system decommissioning projects.

Improved security and compliance

As data privacy regulations continue to tighten, security and compliance have become central to modern decommissioning strategies. Looking ahead, we’re seeing a shift towards embedding advanced technologies—such as electronic seals, blockchain and zero-trust architectures—into the decommissioning process to protect sensitive data at every stage. By adopting comprehensive security frameworks, organisations can uphold data integrity, reduce exposure to cyber threats, and ensure alignment with regulatory requirements throughout the decommissioning lifecycle.

ELSA drives innovation for legacy system decommissioning

As customer expectations continue to evolve, digital transformation is gathering pace, prompting organisations to re-evaluate their approach towards keeping legacy systems. As a matter of fact, a strategically fine approach helps ensure seamless access to data while meeting regulatory compliance obligations. Thankfully, ELSA by TJC Group protects information critical to businesses and simultaneously, it helps unlock new value from historical records. Thereby, making it much easier and more streamlined for tax authorities, auditors, and data protection regulators to receive the necessary documentation promptly, precisely when it’s required.

Along with the gains of SAP legacy system decommissioning, organisations also benefit from immediate visibility and control over technology expenditure. The fact of the matter, ELSA helps reduce software licensing fees and infrastructure costs. Resources can then be redirected from routine maintenance towards innovation. By streamlining access to compliance-related data, ELSA enables IT teams to shift their focus to strategic initiatives. Its architecture eliminates system redundancy whilst preserving essential business information.

In the cloud, ELSA adapts to each organisation’s technical ecosystem. IT departments retain the freedom to choose their preferred infrastructure providers and database platforms. This flexibility extends to managing legacy systems, enabling centralised SAP & non-SAP decommissioning and archiving via a unified platform. As a matter of fact, the value goes far beyond cost-efficiency — ELSA redefines how organisations approach risk management.

Ongoing maintenance costs are reduced, even as security postures are strengthened. In scenarios such as mergers, acquisitions or divestitures, data transitions occur smoothly, with minimal operational disruption. Moreover, the application’s robust disaster recovery capabilities protect against both system outages and data loss. Under ELSA’s governance, IT landscapes become markedly simpler; therefore, enabling users to collaborate across previously disconnected sets of data while significantly boosting organisational productivity.

Apart from its remarkable benefits for legacy system decommissioning process, ELSA ensures that the S/4HANA implementation progresses more rapidly as legacy data concerns are resolved with greater speed and confidence. Meanwhile, users remain within modern familiar interfaces, avoiding the need to learn or maintain knowledge of multiple outdated systems.

ELSA’s benefits extend well beyond the present. It is more than just a technical solution — it is a strategic enabler. By addressing immediate operational challenges while laying the groundwork for future transformation, ELSA empowers organisations to navigate change with confidence and agility.

Working with TJC Group for legacy system decommissioning

While SAP legacy system decommissioning is an excellent way to align your organisation with data management strategies, handling system retiring alone is not an easy process. However, with experts at your disposal, saying goodbye to obsolete systems will become significantly easier and streamlined. Wondering how? Join forces with us to ensure a system decommissioning project that will not just retire your obsolete systems but also drive business value and yield outstanding gains.

In a glance about TJC Group

With 25+ years of experience, TJC Group has assisted numerous clients with SAP & non-SAP decommissioning of legacy systems. From assessing your data volume to archiving, data extraction and migration, and managing them, our expertise not just helps gain results but also overcome the obstacles smoothly. Moreover, we understand the legal and regulatory landscape, data privacy requirements, the business needs, and the technical aspects of such compliance.

Collaborating with TJC Group helps organisations in several ways –

SAP expertise: Our extensive expertise encompasses far more than just the decommissioning of obsolete systems. It also includes SAP data & document archiving, SAP ILM Retention and Warehouse Management, and a range of other tax and technology-related solutions. TJC Group’s considerable capabilities enable us to bridge the gap between stakeholders, fostering strong collaboration between technical teams and clients. In fact, this expertise allows us to help beyond the decommissioning with the overall data management strategy of the company, “because data matters”.

Cutting-edge technology: Our advanced technology is a key strength, enabling us to streamline and secure processes with greater efficiency. In fact, over 40% of our workforce is dedicated to research and development, ensuring the smooth and reliable operation of all procedures involved.

Integration with our technology: As previously mentioned, we provide a cloud-based, user-friendly application developed with SAP BTP – the Enterprise Legacy System Application (ELSA) – designed to automate the SAP legacy system decommissioning process. As the creators of this application, we are uniquely positioned to integrate our most effective technologies into the process, tailored to meet each client’s specific requirements.

Subject matter experts: TJC Group’s subject matter experts possess extensive experience across a wide range of projects. Our dedicated system decommissioning team, alongside our data archiving and ILM teams, ensures seamless project delivery. Additionally, our team helps organisations remain aligned with evolving regulatory requirements, safeguarding them against potential non-compliance penalties and reputational risks.

Case studies | An insight into our projects

Reference use case: A leading global manufacturer’s system decommissioning journey

A global manufacturing organisation with an annual revenue of $1.3 billion was grappling with growing complexity in its post-S/4HANA landscape. Two years after implementation, its legacy environment still encompassed development, quality assurance, and production systems. At the same time, annual maintenance and licensing fees were placing a significant strain on the budget. More urgently, there was a need to retain pension records and ensure compliance across 19 manufacturing sites.

The project team devised a four-phase implementation strategy grounded in a measured risk assessment. Starting with a focused proof of concept, they validated ELSA’s capabilities against key business requirements. Integration with Azure BLOB storage and configuration of the MySQL database established the technical foundation for production deployment. Running systems in parallel enabled a controlled testing environment to verify data accessibility and system performance.

Read more about it here: https://www.tjc-group.com/resource/driving-genai-innovation-in-s-4hana-transformation-with-decommissioning/

Case studies

Rio Tinto SAP legacy system decommissioning case study

Leading global mining and metals group that focuses on finding, mining, processing and marketing the Earth’s mineral resources. Headquartered in the UK, with locations in 40 countries in almost all continents worldwide, we helped them extensively with their SAP legacy system decommissioning.

To learn more about their journey, download here: https://www.tjc-group.com/resource/rio-tinto/

JC Decaux: World’s largest outdoor advertising company case study

We helped JC Decaux with precise and complete data extraction to facilitate M&A. It is a multinational firm that pioneered the bus-stop advertising system and is the world’s largest outdoor advertising company.

Download their case study here to learn more – https://www.tjc-group.com/resource/jc-decaux/

Leading manufacturer (undisclosed name)

TJC Group helped a leading manufacturer streamline its SAP landscape, ensuring compliance and significant cost savings. The company is a leading manufacturer with more than 160 years in business. It has 19 manufacturing facilities, over 3,500 employees, and has made 11 acquisitions since 2016.

Learn more about their journey here – https://www.tjc-group.com/resource/a-leading-manufacturer-and-legacy-system-decommissioning-case-study/

List of resources on SAP legacy system decommissioning

• Driving GenAI innovation in S/4HANA transformation with decommissioning
• SAPinsider Technology Insight on Data Archiving and Decommissioning
• Infographic: 5 reasons to decommission legacy systems | TJC group
• TJC Group decommissioning solution sheet
• https://www.youtube.com/embed/wWXAtkQRGWE?autoplay=1
• https://www.youtube.com/watch?v=KiHIIrmLuMc
• On-demand WEBINAR: Legacy System Decommissioning for SAP and non-SAP systems
• Demo of Enterprise Legacy System Application (ELSA)
• Ultimate Guide to Understanding SAP BTP

Conclusion

Businesses require clear and practical criteria to evaluate their data management requirements that will further enable them to adapt more efficient legacy system decommissioning solutions. Their platforms must be capable of supporting AI and advanced analytics without disrupting existing operations—demanding a thorough cost analysis rooted in day-to-day business actualities. As regulatory requirements evolve and technology progresses, effective data governance must strike a balance between safeguarding information and ensuring accessibility.

A successful SAP & non-SAP decommissioning initiative begins with a change in mindset. Rather than viewing it purely as system shutdown, organisations can realise new analytical opportunities by leveraging historical data. The fact of the matter is that success lies in combining strong technical expertise with well-established methodologies—enabling businesses to transform legacy data into a strategic asset that drives sustainable growth.

For decommissioning of obsolete systems, ELSA’s implementation is founded on built-in data integrity. The platform generates checksums during both the extraction and ingestion processes, ensuring that all information is transferred without alteration. This verification process applies to all data types — including database tables, attached documents, and business objects.

Come, explore and evaluate ELSA’s capabilities from the outset of your S/4HANA transformation to drive impact and achieve cost savings throughout the course of your SAP legacy system decommissioning project. Contact us now!

Addressing the frequently asked questions (FAQs)

Question 1: What is legacy system decommissioning?

Answer: Legacy system decommissioning refers to the process of removing and fully shutting down outdated systems that may pose security risks to an organisation’s IT infrastructure. It is, in fact, a crucial component of IT lifecycle management, enabling organisations to keep pace with their evolving technological requirements. As a matter of fact, depending on the business requirements, legacy data can be extracted and stored in flat files, such as tax archives (if verification processes have been put in place), before the obsolete system is retired. This data remains accessible for future reference through the use of legacy system applications, if required. Furthermore, SAP & non-SAP decommissioning of obsolete systems also supports compliance with data protection regulations, while contributing to more efficient use of organisational resources.

Question 2: What are the strategic reasons for decommissioning obsolete systems?

Answer: Overall, shutting down obsolete systems helps attain major cost-saving benefits to organisations, allowing them to utilise the money into adapting newer technologies. However, the top five strategic reasons for SAP legacy system decommissioning would be – enhanced security, better compliance with legal and regulatory requirements, better financial gains in the long run, improved efficiency of IT landscape, and achieving organisational sustainability targets.

Question 3: Can non-SAP systems be decommissioned using SAP tools?

Answer: TJC Group’s legacy system decommissioning solution, ELSA, is an easy solution for both SAP and non-SAP decommissioning. However, there is also an SAP solution for SAP decommissioning that helps decommission non-SAP solutions. If your organisation has non-SAP systems, the unified approach that can be adapted is SAP NetWeaver (NW) ILM. It provides an integrated solution for the decommissioning of both SAP & non-SAP systems. This is achieved using SAP SLT (System Landscape Transformation), the Legacy Extraction Workbench (CDE archive objects), and the SAP ILM Retention Warehouse, which utilises ILM-certified storage based on Sybase IQ, SAP HANA, or any SAP-certified ILM repository. This legacy system decommissioning approach is used by some SAP players around the world.

---