A frequently-neglected part of the plan for implementation of a new application is the retirement of the one that is being replaced.
However, there is good reason to do that work at the same time as your new project, as there are risks and costs related to keeping an old system running after it is no longer actively used.
Why decommission
The most obvious concern with maintaining applications that are no longer used is the cost of licensing and support agreements. There are also less obvious costs. For example, you may be running certain hardware or operating systems for the sole purpose of maintaining the legacy applications. You may also pay consultants with legacy expertise to maintain that legacy hardware and software. Perhaps it is no longer feasible to apply some types of security to older systems.
Here is an approach to consider and tailor to your own application and organization.
Business ownership
Although managed by IT, there must be a business owner who will participate in retirement planning and approve any decisions that are relevant to the business.
Contracts
Unless the application being retired is fully home-grown, you likely have some contracts in place. For example, application licenses for users and administrators, and support agreements. The infrastructure or security support may also be covered by service contracts. Review all of the relevant contracts and determine what your rights and responsibilities are. E.g. if users are not maintaining any data, but are read-only, do you still have to pay? What is the notice period, and when is the deadline to give notice? Are your responsibilities truly clear in the contract, or do you need a lawyer to review it?
Continuing access to the data
Depending on the business use of the application, it may be necessary to keep the data for some period of time. Start by identifying the data that is kept in the system. Is it general ledger, purchase orders, energy usage? Also identify whether the application is the system of record for that data. If the application is just for reporting or transmitting, and the system of record is somewhere else, it may much easier to eliminate the application’s data set.
If the application is the system of record, map the data sets in the system to the corporate data retention policy. This policy will have been developed in alignment with compliance, legal, and regulatory requirements. Then, discuss with the business owner what their business needs are for ongoing access to the data. This may be different from the corporate data retention policy.
While you’re having that discussion with the business, find out what kind of access to the data is going to be needed. Do they still need to use the application to view the data, or will it be enough to be able to query the database?
Also ask the business owner how many users should have continuing access to the application. Perhaps you can reduce the number of users to just a few, either right away, or after a year or so.
If the application being retired is on some technology that you no longer use for any other applications, it may be tempting to copy the database to a technology that you support as a standard. However, this may not provide what the business needs. If the data structure is complex, you may no longer have an employee with the experience to query that structure and get the right answer. In addition, if there is a need to re-generate reports or documents, it may not be feasible to do so without the application.
Operations
Perhaps based on either the retention policy, or the business needs, you have learned that the application is still needed for inquiry and reporting for several years. There still may be steps you can take to reduce the effort of operating the application.
For example, since the data isn’t changing, it may not be necessary to do daily backups or manage high availability. Perhaps the business would now be fine with a monthly backup, so you have fresh media. Maybe the business would agree with a longer recovery in the event of failure.
It’s also likely that you could eliminate the development and testing environments for the retiring application.
Security and controls
You can also examine the security and controls for the retiring application. For example, discuss with the business whether they still require two-factor authentication.
It’s also a good time to discuss whether the controls for the application and its supporting infrastructure should be tested any more as part of the audit. Some of the testing may no longer be needed, which could reduce the effort of internal or external auditors.
Other considerations
If you are generally moving applications to the cloud, or no longer wish to support the particular technology platform of the retiring application in your data centre, you may consider options to have someone else manage it for you. There are usually vendors who would agree to host the hardware and application in their own data centre. Note that this approach requires considerable planning, and you should engage the potential vendor early to discuss requirements.
Conclusion
When you implement a new system, planning for the retirement of the old one should be planned at the same time. It should be possible to manage costs and risks by appropriate planning and execution.
This article provided some high-level guidance on retirement planning to get you started. You can use it as a framework, and customize it to your own organization’s needs
