A guide to system decommissioning

Effectively managing and retiring outdated systems is key to maintaining operational efficiency and reducing unnecessary costs. A system decommissioning project is more than just a technical necessity, it’s a strategic decision that can significantly affect an organisation’s bottom line. This system decommissioning guide looks at the reasons behind system decommissioning and how businesses can approach and execute these projects successfully.

What is system decommissioning

For many organisations we engage with, system decommissioning isn’t always fully understood, so let’s start with a bit of background. System decommissioning is a strategic approach to phasing out legacy applications. However, it’s important to note that these applications are often still in use within the organisation and contain data that can be crucial to the business. This data might be necessary to retain for legal reasons or simply because it’s significant to your operations.

In this context, when we discuss legacy applications, we are referring specifically to those for which a replacement has already been implemented. Despite the new solutions in place, the older, or ‘legacy’, applications are maintained primarily because of the valuable data they hold.

Decommissioning, therefore, might seem like a misleading term. It’s more than just turning off old systems; it’s about strategically managing the transition without losing access to important data. The priority is to ensure that, even after these systems are decomissioned, the business retains access to its critical data, potentially for many years to come.

System decommissioning priorities

1. Ensure that data can be extracted from the legacy system. This is the first step in a successful decommissioning process.
2. The next priority is finding an appropriate place to store this data. You need a modern, secure environment where data is not only protected but also easily accessible. This ensures that users who depend on this data will continue to have uninterrupted access.
3. Looking forward, decommissioning offers a chance to reassess your infrastructure platform. Perhaps your legacy application was running on-premise, but now you might be considering a move to the cloud, or maybe keeping some data on-premise and moving other elements to the cloud. This decision involves evaluating various options and figuring out what best fits your goals.
4. Lastly, reporting is critical. You have had systems in place that allowed access to data through specific applications, and as these systems are decommissioned, it’s essential to ensure that necessary reporting capabilities are not only preserved but also enhanced. Identifying key reports and integrating them into the new system is vital, ensuring a smooth transition for all users accustomed to the old platform. This approach in reporting will support your team as they adapt to the new system post-decommissioning.

Drivers for decommissioning

If we consider why decommissioning is necessary, there are four key areas to focus on:

Reducing costs

The most commonly recognised and primary driver for decommissioning is cost reduction. Managing legacy systems can accumulate significant expenses. To help our customers understand this, we conduct an initial study focusing on the TCO for these projects. There are numerous variables to consider, but let’s break it down:

1. The infrastructure: Typically, running a legacy application involves a range of systems, possibly located in your own data center, but not exclusively. This setup includes servers, storage, and specific networking configurations. Additionally, you might have systems dedicated to backups, high availability, and disaster recovery. When we start to tally the costs, consider that for a large application, you’re not just maintaining the production environment but also test, development, and QA environments. Often, if it’s a legacy application, the technology may be aging, prompting a need to evaluate whether replacements are necessary, which incurs additional costs. So, there’s a significant amount of infrastructure cost to consider in these scenarios.
2. Software across the stack: Clearly, there are significant costs associated with software. Typically, you’re paying maintenance or support fees not only for the application itself but also for the operating system and any databases involved. Additionally, there might be costs linked to other components, such as backup software. All these elements need to be considered when assessing the overall cost case.
3. Staff: Lastly, let’s consider staff costs. You might find that the costs associated with maintaining the legacy application are minimal, perhaps involving just one person who manages it on a part-time basis. However, the scenario could be more significant depending on your specific situation. It’s a crucial component of the overall cost picture that only you can fully assess for your organisation.

Mitigating business risk

Cost is often viewed as the primary driver for decommissioning, but in some cases, the business risks associated with running legacy applications can be equally significant, or perhaps even more critical.

1. Running on older, unsupported hardware: It’s not uncommon for us to hear about customers maintaining legacy applications on systems that are only activated when necessary. Sometimes, this might involve virtualised hardware, which is generally acceptable. However, if it’s on older, unsupported hardware, the risks increase. We’ve seen instances where customers attempt to activate an older application, only to face hardware failures. In such cases, finding replacement parts becomes a significant challenge. We’ve even heard stories of customers turning to platforms like eBay to source the necessary components to get their systems back up and running. For a critical application—perhaps a legacy one that isn’t used frequently but contains vital data—the risk of not being able to access that data when needed is a considerable concern.
2. Application, OS or DB may be out of support: Whether it concerns hardware or software, a key question is whether these components are still supported. If they’re not, does the vendor still offer support, perhaps through an expensive extended support contract? Additionally, running unsupported systems can raise concerns with auditors, especially if it’s a crucial business application. They might require that such applications be supported to comply with regulatory standards. This represents a significant risk that needs careful consideration.
3. Non-compliance with new legal/audit requirements: Another significant concern we frequently encounter is that some older applications fail to meet new regulatory standards. A notable example is GDPR compliance. We have seen several instances where older applications were not GDPR compliant and could not be updated to become compliant. This poses a substantial business risk. There may be other legal or financial regulations that are critical to your operations, often making compliance a major driver for undertaking decommissioning projects.

Opportunity costs

Consider that the staff dedicated to maintaining older applications are not available to work on newer, strategically important projects for your business. This diversion of resources represents an opportunity cost, as it potentially hampers innovation and progress in areas that could be more beneficial to your company’s future.

Environmental objectives

Transitioning away from legacy hardware can also align with environmental goals. Each new generation of systems tends to be faster and more energy-efficient than its predecessors. If your legacy applications are running on outdated infrastructure and your business is committed to environmental objectives, maintaining old systems could hinder your progress towards these goals. Moving to newer technologies not only supports operational efficiency but also contributes to your company’s environmental commitments.

Scenarios for system decommissioning

So, considering these drivers for decommissioning, let’s explore some typical scenarios where they might arise. There are numerous instances where you might find yourself managing legacy applications for various reasons, but here are some of the most common examples we often encounter:

1. Mergers and acquisitions: In situations involving mergers or acquisitions, or even when a business is splitting or a division is being restructured, there is a crucial need for a comprehensive IT systems plan. We frequently observe cases where merging entities each have their key business applications, whether it’s SAP or a combination of SAP and another system. Decisions need to be made about these applications, particularly concerning the data that remains important within the systems being phased out. This typically requires a structured approach to manage and integrate or decommission IT systems effectively—a more planned and strategic scenario.
2. Implementing a new cloud business application:When you’re rolling out a new solution, often a cloud-based one, there are key decisions to be made about data migration. For instance, many of our customers opt for cloud applications like SuccessFactors for HR functions. They typically license this for all current employees and migrate active employee data to the new system. However, records for former employees, or legacy data, are usually retained in the existing legacy HR application, such as SAP HR on-premise. This scenario is common across various business areas where legacy systems coexist with new cloud solutions.
3. Implementing S/4HANA with a greenfield migration: When customers transition to S/4HANA, there are several migration strategies they might consider, but with a Greenfield approach, it’s common to start afresh. This often results in older applications, such as SAP ECC, being left behind once the new S/4HANA system is fully operational. This scenario requires careful planning to manage the legacy systems that remain active even as the new system takes precedence.

So, there are numerous scenarios that can lead to the presence of legacy applications and, similarly, various situations that might prompt you to consider how to effectively decommission them.

The business case for system decommissioning

Let’s think about the business case for decommissioning and evaluate if there’s a strong cost justification for undertaking such projects. Generally, we find there’s a compelling financial argument in favor. Based on discussions with numerous customers and our extensive experience with custom projects, we’ve observed that about 15% of an IT budget is often allocated to maintaining legacy applications. Considering the scale of these budgets, that’s a substantial annual expenditure. If you can cut this figure down, the potential savings are significant. For instance, we’ve seen decommissioning projects where savings have reached up to 80%.

Here’s a straightforward breakdown of how we model these costs and savings:

Step 1 – Work out the cost of the existing system:

• Include servers, storage, and networking.
• Factor in the operating system, database, and application costs.
• Consider backup, security, and high availability/disaster recovery etc.
• Account for data centre space, power, cooling.
• Factor in the number of instances, years to retain the data, and inflation percentage.
• Calculate the annual running cost and TCO.

Step 2 – Calculate the cost for system decommissioning:

• Include costs for decommissioning software and implementation services.
• Consider server costs and other related expenses as per the existing system.
• Again, factor in the number of instances, years to retain the data, and inflation percentage.
• Calculate the annual running cost and TCO.

Step 3 – Calculate the savings!

It’s worth mentioning the factory approach at this juncture. When facing multiple systems to decommission, we recommend starting with the most complex and learning the lessons. This initial project will usually drive significant savings. These savings can then be used to finance the decommissioning of subsequent systems. If this process is managed effectively, it can create a self-sustaining cycle where each step funds the next, developing a robust and efficient business case.

How to decommission SAP systems

Now, let’s discuss how we go about decommissioning SAP systems within an SAP landscape.

Planning for system decommissioning success

To ensure the success of a system decommissioning project, the first step is thorough planning. We need to identify what within the SAP landscape will be decommissioned and understand who is using it. This involves two perspectives:

Technical view: This includes analysing what data is in the system, how old it is, and other relevant details. We need to understand the volume and type of data, such as finance data spread over several years.

User view: This involves identifying who is still using the system, why they are using it, and what reports they are running. Once the system is decommissioned, we need to determine how much of this data users still need access to, if any data is redundant and can be destroyed, how long the remaining data needs to be kept, and what kind of reports are necessary.

This analysis, known as the blueprinting process, helps us understand exactly what we are decommissioning from the SAP system. Common modules for decommissioning in an SAP ECC system include finance, controlling, sales and distribution, materials management, logistics, plant maintenance, and production planning. We also encounter unstructured data, such as physical documents stored within the SAP database or externally in content management solutions like OpenText or Easy Software. These documents are often related to entries in the SAP modules, such as sales invoices, packing lists, or inbound invoices from suppliers.

Another area is SAP HR data, which includes infotype data, bespoke infotypes, payroll information, and employee self-service information. We can decommission all SAP HR data from your HR environment. Additionally, we handle SAP CRM and SRM systems, dealing with data related to tasks, opportunities, appointments, and interactions.

It is important to determine the relevance of data and how long it needs to be retained. For example, someone in financial audit control might need to keep documents for tax purposes for ten years, while someone in the pharmaceutical industry might need to keep information for 50 years under FDA regulations. Gathering all this information is crucial to ensure nothing is left behind and that we comply with all necessary regulations.

Key success factor in system decommissioning (Not just a technical task!)

1. Communicate early: Begin discussions with business users and data owners as early as possible to ensure everyone is informed and involved from the start.
2. Involve quality, regulatory, and compliance teams: In regulated industries, it’s crucial to keep quality, regulatory, and compliance teams informed about your plans for data handling. Engaging them early will help you navigate the process smoothly and prevent potential roadblocks after completing the technical work.
3. Engage with legal: If there are ongoing legal cases relying on data from legacy systems, involve your legal team. They need to ensure the data is preserved and accessible for the required duration, and that it is properly destroyed when necessary to comply with GDPR and other regulations.
4. Conduct workshops: Organise workshops with all stakeholders, including IT teams, to discuss requirements and plan the decommissioning process. IT teams must be ready to provide the necessary infrastructure to support data decommissioning.
5. Align with audit and user teams: Set clear expectations with users on how they will access data in the new environment. Some data might be infrequently accessed and only needed for audits, while other data may be used daily. Plan accordingly to ensure ongoing accessibility and usability of essential information once the system is decommissioned.

System decommissioning solution: Proceed Cella

Over the years, we have worked with numerous solutions and, through this experience, we’ve developed our own in-house solution, Proceed Cella. Recognising the needs of the market, it is very much an all-in-one solution designed to not only extract and store data but also provide comprehensive reporting and robust security features.

We have integrated retention management rules, allowing you to define how long different classes of data should be retained, whether in a high-level or granular way. For example, some data might be kept for three years, others for ten, and we’ve also included functionality for legal holds to address any ongoing legal issues.

This solution has been well-received; many customers have adopted it, and it’s even being promoted by other organisations as their preferred solution. We’re delighted with this response and have now made it available as a SaaS solution, responding to the overwhelming customer demand.

Explore our system decommissioning solution Proceed Cella >

Getting started

One thing we can do to assist you is to start with an initial assessment to understand where you currently stand. Within your organisation, there are various aspects to consider, but specifically for SAP systems, we offer a free assessment. This helps you gain a deeper understanding of your system. It allows us to identify which modules are in use, the level of customisation, and provide a cost estimate and project scope. Many organisations find this particularly useful.

For non-SAP systems, we can conduct a simpler assessment. This involves indexing your systems, identifying the underlying technologies, and understanding customisation, usage, and reporting requirements. This process helps build a comprehensive picture of your needs, and we are more than happy to assist if you’re interested.

If you want details on how we retire legacy systems while keeping access to history, see our system decommissioning service.