Legacy systems: A journey from sunsetting to decommissioning

The article discusses the importance of sunsetting and decommissioning legacy IT systems in corporate environments to improve efficiency, reduce costs, and ensure compliance, while outlining the challenges associated with legacy systems and introducing TJC Group’s Enterprise Legacy System Application (ELSA) as a solution for seamless data management during the decommissioning process.

Introduction

The evolution of IT systems is an inevitable element in a corporate environment. It means that from time to time, corporate applications must be migrated or replaced by a new one. Irrespective of whether you are SAP-backed or any other ERP system, it is essential to discard legacy systems and adapt newer ones for better and more efficient business operations. We understand that sunsetting, decommissioning, and such terms can sound intriguing which can lead to more curiosity for learning more about it, isn’t it?

Hence, we have curated a blog to help you understand the process from sunsetting to decommissioning a legacy system.

What is sunsetting a system?

The expression “sunsetting a system” has several definitions. In finance, it often refers to the termination or phasing out of something – which can be brands, partnerships, hardware and software, agreements, etc. In simple terms, sunsetting can be synonymous with expressions like phase out, discontinue, terminate, and so on. However, in IT, sunsetting a system has a different meaning altogether.

In IT terms, sunsetting a system means moving a legacy system from productive status (use status) to a non-productive, or read-only status. This means that the system is still accessible for important information, but it cannot be used for day-to-day operations.

What is system decommissioning?

Although the process of sunsetting the system is relatively old, it often creates confusion amongst users, mostly because of its different definitions across different industries. Often, readers tend to think that system sunset and decommissioning are the same – the truth is, decommissioning goes much beyond sunsetting.

System decommissioning includes the removal and complete shutdown of the legacy systems, or the IT infrastructure, which has become obsolete. Sometimes, in addition, the legacy data is extracted and saved in flat files as tax archives. Such data can be reassessed when needed with the help of Legacy System Applications (LSA).

The decommissioning of legacy systems is a crucial part of the IT lifecycle management process. It may also help organisations optimise their IT resources, reduce maintenance costs, and ensure future compliance with data privacy laws while eliminating security risks associated with outdated systems. Additionally, decommissioning also helps organisations stay aligned with their evolving technological needs.

Why do we want to retain access to old data?

Now that you know the difference between system sunsetting and system decommissioning, let us address the biggest question – why is retaining access to old data necessary?

Over time, many organisations maintain obsolete ERP and non-ERP systems, although it drains IT resources. Despite this, retaining access to old data is required for the following reasons –

• The first thing is compliance.
• Secondly, old data is needed to respond to Audit or Tax requests.
• Thirdly, in case documents or historical data needs accessing for business needs.

LSA is often required as legal and data privacy requirements might not be enforced on older systems.

The challenges of dealing with legacy systems

With every good thing comes challenges that must be addressed – and so does the legacy system. Here are some of the challenges that businesses come across with outdated ERP and non-ERP systems –

High maintenance cost

One of the biggest challenges of dealing with legacy systems is the cost of maintenance. For every legacy system, there are approximately 49 different cost implications – with the most significant expenditure being the maintenance fees for software and applications. Second to which is the impact on operations i.e., having IT resources tied up with managing outdated systems when they could be working on new technology. Moreover, organisations may incur these costs across multiple legacy systems, such as SAP ECC implemented across several divisions, and so on.

The image below represents the 49 tasks associated with the maintenance of a legacy system or application:

All these tasks must be considered when allocating IT resources, therefore the workload is considerable.

That said, the cost of the license of the operating system (OS), the database (DB), and SAP licenses will also need renewal – hence, leading to higher maintenance costs. This can be a substantial amount! Even if organisations don’t use legacy systems, maintaining their application is required, which not only increases the maintenance cost but also places greater pressure on the technical teams.

Technical debt

A major challenge for organisations is their technical debt. Simply put, technical debt is the implied cost of reworking a solution caused by choosing an easy but limited solution over a better but longer approach. It is analogous to monetary debt and if not repaid, technical debts accumulate interest, leading to challenges in implementing changes. Unaddressed technical debts increase software entropy and the cost of further rework.  Technical debt also hinders the company’s capability to innovate and adapt to latest changes.

There are several reasons for such debts to occur, such as lack of documentation, lack of test suites, tightly coupled components of non-modular functions, and so on. Therefore, if there are technical debts, sunsetting a legacy system can be challenging – which is why, ensuring minimum debts or having a proof-of-concept (POC) for moving forward with the project is necessary.

Ensuring a non-disruptive performance

The risk of system failure is a factor of concern. A lot of organisations, especially those involved in industrial production, healthcare, etc., cannot afford to have their systems to be disruptive. If a productive system fails here, it majorly leads to revenue losses. That said, losing a legacy system can also lead to financial penalties (related to tax audits). Hence, ensuring a non-disruptive (reduced) performance while sunsetting legacy systems is crucial. Organisations must be very careful to make the process as smooth and seamless as possible.

Environment impact

Apart from financial impacts, legacy systems contribute to IT related environmental impacts. Maintaining legacy systems can drain energy resources largely; therefore, data archiving and system decommissioning is the best way to go forward, as they significantly contribute towards reducing the need for replacement appliance (yes, it also occurs in cloud!).

Migrating to a newer, more efficient landscape

Coming to the SAP landscape, it is announced that SAP ECC and older versions must be replaced by SAP S/4HANA by 2027 and probably after. But, what after the migration is completed?

Once the migration is completed, there will be two systems: the old one and the new one.

• The new system (S/4HANA) – productive status:

The new system is the one where the old applications have been migrated, which in this case is S/4HANA systems. It is accessible daily by the business users to manage the company activities, where the users will connect to the system daily and work on it. Simply put, the new system refers to the productive system in which day-to-day activities are carried out.

• The old system (SAP ECC or older) – on read-only status:

The old system, or the SAP ECC or older systems, are accessible to users in read-only mode, where they can access any important information required for tasks. This is done to reduce the user access to a few people only. Most of the time, the user authorizations are changed so that read-only status is possible.

Steps for legacy system decommissioning project

Planning the decommissioning

The first and foremost step in any project is developing a strong plan. The decision to decommission legacy systems may impact several departments and hence, having a full analysis of its impact is always a good idea. Decommissioning not just has organisational impacts, but also financial impacts.  Having a robust planning strategy is quintessential.

Some common questions that can be asked are –

• Where will the information go after decommissioning the system?
• Will a new application replace the services of the decommissioned legacy system?
• How long will the system decommissioning project take, and so on?

Therefore, planning the decommissioning project step-by-step is crucial.

Choosing the architecture that best fits your IT landscape.

Next comes choosing the architecture that fits your IT landscape. In other words, a system decommissioning project includes rearchitecting, rebuilding, or replacing the old landscape. Rearchitecting is where the code is altered to shift to a new application architecture for newer capabilities. Although the process involves getting the best results, it may come at a higher cost and risks. That said, a careful analysis may also suggest adopting an entirely new architecture that will suit your IT landscape the best. Whether you choose a new architecture or restructure the ongoing one – ensure to map it based on the technology, functionality, cost, and risk. Therefore, the key is to weigh all the available options to identify the process that will require minimum effort but will have a maximum positive impact.

Data extraction from the legacy system

Once you have the plan in place, the third step is to extract data from the legacy systems. Data extraction is the collection and retrieval of a diverse range of data from the system that you plan to decommission – many of which may be organised poorly. Extraction is a necessary step as it helps consolidate, process, and audit data to be stored in a centralised location – the location can be cloud-based, on-site, or even a hybrid of the two.

Uploading data into the legacy system application

After the data extraction step comes the uploading of data into the storage system. As mentioned above, the storage location can be on-site, cloud-based, or a hybrid of the two. It can involve the storage of data or applications from an on-premises location to the cloud as well as from one cloud environment to another. That said, it is anticipated that the majority of corporations will be operating entirely on the cloud in a couple of years as the increase in cloud storage as well as cloud migration is impressive.

How can TJC Group help you with system decommissioning?

Enterprise Legacy System Application by TJC Group

To help simplify and streamline system decommissioning, TJC Group has come up with an Enterprise Legacy System Application – ELSA. It is an application, built and certified on the SAP Business Technology Platform (BTP), also working on premise or with any hyperscaler. With this application, it can be ensured that all the legacy data is stored securely and can be easily re-accessed both before and after migrating to the new ERP or S/4HANA systems. It not only provides access to all the extracted data but also removes the expense of retaining the legacy system.

How does ELSA stand apart from the crowd?

Data migration from old ERP systems to S/4HANA doesn’t guarantee that the existing data will remain complete or unchanged – but ELSA does! TJC Group’s ELSA protects and future-proofs all the legacy data while making it readily accessible from either S/4HANA, a UI5 web application or any current technology application. It is important to note that ELSA is designed to comply with all future business requirements and most international data privacy laws.

ELSA by TJC Group converts legacy data into flat files (AIS format), which remain unchanged. It is fully compatible with other industry-specific SAP solutions – used in healthcare, finance, manufacturing, and the public sector.

Steps followed by TJC Group’s ELSA for system decommissioning

1. The first step is to extract 100% of the data from the legacy system as  tax archives .
2. Once the data is extracted, we then store the extracted AIS files in the AWS / Azure / GCS cloud storage or on-premises file system based on your preference.
3. After the storage, relevant data is imported from the AIS files into the ELSA database of your choice. You can choose the following databases as per your requirements – MySQL / HANA / HANA Cloud / PostgreSQL / Oracle Heatwave.
4. Lastly, end users such as the tax & audit team can access all data via ELSA or S/4 HANA FIORI App, low code – no code solutions or most current technology while safely shutting down the legacy system.

Given the level of financial investment needed for S/4 HANA, it’s imperative to select partner applications that are future-proof and offer open access. ELSA brings together data from different systems and sources – legacy, archived or live data – and keeps it accessible, at the click of a button. Within SAP BTP, ELSA is deployed in the open source, Cloud Foundry environment, protecting your investment and minimising the future cost of ownership.

Final word

System decommissioning is the process of retiring a legacy system that was in a sunset or read-only status some time ago. Legacy systems have several challenges that come along, namely –

• Running legacy systems is costly.
• They increase the “technical debt.”
• They have a significant impact on the environment.

Hence, decommissioning project is the only plausible option. That said, it also ensures compliance requirements are met in the future. And with ELSA by TJC Group, you can simplify the entire decommissioning process even more as we have proven methodology. To decommission your legacy system, or to learn more about ELSA, contact us today!