Deco… what?
Obsolescence and inefficiency, mergers, acquisitions, security, costs, IT architecture, market adaptability.
The reasons for the decommissioning information systems (IS) are many. The process itself typically involves the shutting down and removal of a system that is no longer needed and whose operation is no longer effective. Simple as it may sound, the reality often varies greatly. Before we look at some important aspects of the IS shutdown process, we need to clarify the answer to a fundamental question:
Do you really want this?
Most likely, you’ve just reached the point where you want to shut down the existing information system and replace it with another one. When making this decision, it is worth keeping in mind that decommissioning and replacement (rip-and-replace) is only one of the possible approaches to modernizing your IS. It is by no means the only option, and often it is not even the best one. For example, Gartner defines 7 methods of modernizing an IS. You can read more about why rip-and-replace may not necessarily be the most advantageous strategy in the following article.
Business case
![dependency](https://profinit.eu/wp-content/uploads/2023/12/dependency_2x-2.png)
From a business perspective, the decommissioning process brings with it both opportunities and risks. When deciding on decommissioning, it is necessary to carefully weigh the pros and cons of the various options, such as:
- Internal execution vs. outsourcing
- Start from scratch or build on an existing solution
- Side-by-side operation of the old and new solution
- Purchase of an off-the-shelf solution vs. custom development vs. suitability for the organization
- Reputational risk
- Risk of loss of revenue
It’s decided! Shut it down!
Fine. Following a thorough analysis of the situation we’ve decided that shutting down the existing system will be best. Where to begin? What to watch out for? And how do you take decommissioning through to a successful conclusion?
The plan is key!
When planning decommissioning, we must make important decisions that will affect the overall process and its success. Will we shut down the system all at once, or will we gradually wind down system operations? If we’re planning a gradual winding down of operations, do we proceed by functional units, according to users, or will we oversee the tapering off process some other way? How do we deal with IS data? Are we going to archive it, migrate it to a new system or can we just toss it out? What are the other impacts of IS decommissioning and how will we address them? Do other systems depend on the given IS and how and when will these dependencies be supplanted? How do we guide the user through the entire process?
Data backup and migration
Operational IS are almost never synchronous. They often include various asynchronous processes, messages, queues, etc. It must be guaranteed that the system backup will be usable from this point of view as well and that the restored data will be consistent. If we make a backup, we should also test the recovery process – Murphy’s law applies even here. Data migration to a new or different system is never a trivial task – it should always be preceded by a thorough analysis of the current state and quality of data. The migration itself may need to be split into several stages, and each of these stages must be planned and the migration tested.
Data security
Just as for any other work we undertake with IS, it is necessary to ensure data security. The old system may contain sensitive data, and when we’re preparing to decommission the system and migrate its data to another system, this data must be secured against possible leaks and misuse.
Don’t keep it to yourself
All parties with an interest in the process, including users and customers for example, must be informed and involved in a timely manner. Shutting down the IS almost never happens without it having an impact on the environment at the organization.
Testing, testing… testing
We’ve already mentioned testing data migration above. Before the actual shutting down of the system, it is also necessary to very carefully verify through testing that the new/different system has taken over all the necessary activities of the system being shut down. Sometimes it’s only during a practice shutdown of the system that hidden dependencies are revealed.
Moving to decommission information systems is a strategic step towards modernizing an organization and increasing efficiency. A properly executed process can lead to reduced costs, improved security and increased competitiveness. However, the process must be planned keeping in mind the unique requirements and challenges it brings.
Author: Martin Zavrbsky