The need and risks associated with decommissioning systems
Our thirst for IT solutions has grown exponentially in the last two decades, with the continuous acquisition of applications an inherent part of business life. However, organisations don’t have the same thirst for decommissioning legacy applications and are suffering severe software bloat to such a degree that their applications portfolios are becoming an expensive drain on their business. Decommissioning success is not always guaranteed.
Cloud computing has added another layer of complexity, and as we continue to move to cloud-based applications to run our businesses we’re likely to leave our on-premise based applications to fester on the network. There they take up storage and leave the business open to risk as they reach their end of support period and security patches are turned off. The IT department is faced with providing the business with new applications that can deliver more functionality, mobility, and analytics whilst retaining an ever-growing amount of applications that have been shelved but continue to be a drain on the business.
Whilst the risks and the costs are clear, most enterprises feel daunted by the prospect of decommissioning. Successfully running a decommissioning project is often seen as complex and expensive, and despite cost savings offered by the process, lack of expertise means many of these projects are avoided or started and then fail.
With the compelling need to move data centres from on-premise to the cloud, the opportunity offered by leaner, modern applications that improve cost efficiencies is clear. Therefore, many organisations are having to face down their fears and begin the process. Here we offer the key steps we feel are invaluable when undertaking a decommissioning project:
Key steps for decommissioning success
The following things need to be taken into consideration prior to starting to think about a decommissioning project.
Develop a strategy
A key element involves a firm strategy from the outset – whether you’re decommissioning a single system or a hundred, the absence of a decommissioning strategy is by far the biggest single point of failure for a decommission project. Ensure that the strategy is shared across the organisation, identify all stakeholders across the business within operations and IT and engage readily with them.
Keep your roles separate
Recently, Gartner coined the term ‘application undertaker’ for those tasked with removing ‘dead’ applications and their data. Instead of the same team being responsible for the implementation of a new application, and removing the old they recommend siloing the projects. They highlight the need for a whole separate body of people that take ultimate responsibility for the decommissioning of an application. To truly separate and distinguish the importance of the role of the decommissioner is the first step to achieving success.
Understand reporting needs
Lots of businesses may decide not to decommission applications because relevant data still sits inside an old on-premise application, and it’s still considered ‘useful’ to them. However with the technology available today, the data can be easily stored in a modern repository and is completely accessible by stakeholders in a format that is understandable. Pay attention to your stakeholders needs when planning to do this, it’s imperative to understand their needs and reporting requirements early on in the process to ensure the plan meets their requirements
Hire in expertise
Failed decommissioning projects can often be based entirely on lack of expertise. It is imperative that those that take the responsibility of the role of ‘application undertaker’ have a deep knowledge of legacy systems and prior decommissioning experience if the project is to be a success. Without having the right expertise you are putting the business at risk of investing a lot of money and with no guarantee that you will get the desired outcome. Experts are also knows where the common pitfalls are.
Ensure stakeholder communication
Businesses are focused on success, and IT is increasingly being seen as the driver to achieving that success – innovative applications that offer insights and analysis are key tools to improve business performance, especially with digital transformation taking hold. Whilst innovation is the focus of the C-suite, removing obsolete technology is often seen as a necessary evil that will resolve itself quickly and remains firmly within the IT team. However, the opposite is almost always true. It is imperative to success that communication lines remain open with key stakeholders, including the C-suite to manage expectations and measure success.
Planning and implementation considerations
Taking the above into consideration, the following things need to be taken into account when you get the planning and implementation parts.
Our experience shows that careful planning, the right methodology and due diligence are the key elements of this complex process. We’ve broken this down into project phases, that ensure each element is focused on at the right stage of the entire project, these essentially are the following:
Identify all the applications that are good candidates for decommissioning. Generally, this is already known but due diligence is key here. Identify more than just the name of the application, consider its business function, current and future costs and usage.
Discovery and analysis of systems
Once you’ve identified your applications, this second phase explores them in more detail and gives a clearer picture of the work required, potential savings and any disruption. This forms the foundation for the overall strategy.
The next phase should consider all the elements discussed above regarding stakeholders, potential business disruption, legal requirements for data, ROI etc. Without this decommissioning strategy you risk missing important pieces by diving straight to the details.
The decommissioning design phase includes the detailed instructions on how to accomplish the decommissioning tasks to be handed to developers. It is also essential for compliance reasons. For the business it offers traceability to ensure every business requirement is accounted for.
The main criterion to starting implementation is “do I have all the plans necessary for this piece of decommissioning effort?” This includes training where necessary, planning documents being in place, and stakeholders being communicated to. Your project will not be complete however until proven and validated rigorous testing with a complete documentation trail. The application to be decommissioned should be certified, ‘decommission ready’ which ensures:
- All data feeds have been ceased
- Business functionality has been replaced or eliminated
- Data has been converted, archived or destroyed
- Data required for continuing analysis is available
- Audit trails exist to ensure data transformations can be identified so as to recreate the original data values
It has never been more timely to undertake a decommissioning project as organisations face unprecedented challenges leading to new requirements to use technology to bolster every part of their business. The ensuing financial impact of Covid-19 is a compelling reason to reduce software bloat and all the related costs. Application decommissioning can be challenging. However with the right experience, strategy and implementation guidance real financial rewards can be reaped.
If you want to find out more about decommissioning, please get in touch with our team of experts. We’ve run hundreds of decommissioning projects over the years and we are happy to share this knowledge with you.
SAP data compliance, did you get it right?
Delve into the complexities of data compliance with Christopher Burfitt, where the focus extends beyond rule adherence: learn why being compliant involves a delicate balance between legal requirements and optimising data usage. Discover the critical considerations, challenges, and essential tools that shape an effective data compliance strategy.
What options are there to better manage legacy data?
Proceed’s managing director and subject matter expert, Robert Reuben explores the different options for managing legacy data and the best available tools. Join us as we unpack best practices, real-world results, and the invaluable lessons learned from those who have successfully offloaded their legacy systems.
Should businesses manage data before or after S/4HANA?
With firsthand insights and customer examples, Nick sheds light on the pivotal question: Should SAP customers address data management before or after their migration? Tune in as we unpack best practices, real-world results, and the invaluable lessons learned from those who have embarked on the journey to S/4HANA.