Legacy Application Retirement - A Complete Plan

Source: avendata.com

Business processes are implemented through IT applications, which aid firms in running their daily operations effectively. These apps exist because they are crucial to business. Therefore, it is important to properly plan the retirement of these apps to prevent any disturbance to business users and to ensure a seamless transition to a new platform.

The final phase of the application life cycle is retirement. This event can be brought on by a wide range of circumstances, including technology development, business requirements, acquisition, merger, and the obsolescence of the underlying business process. This article is based on a merger and acquisition experience. It has some organisational advantages and is associated with organisational strategy and goals.

The things you should think about before decommissioning an application are covered in this blog. It provides a high-level overview of the retirement process and will assist you in laying the groundwork for your strategy. I've broken down application retirement into four main parts, however depending on the application, there may be more or fewer processes. 

The whole strategy is predicated on the idea that the programme will be shut down gradually: first, lock it down (placing it in read-only mode), and then, after a certain amount of time, really shut down the application and associated host computers. The strategy will be straightforward if your application moves straight into the retirement phase, leaving no time between the read-only date and the actual decommissioning date.

Learn more about IT Legacy Systems 

Step 1: Create Questionnaire

1. Read-only date – When can application be marked read only?
2. Retirement date – When can application be retired completely?
3. Data Retention Requirements – Consider following topics

• Data Migration – Does Business need data to be migrated to a new platform?

• If YES – create a separate migration plan – create mapping with respect to the target system, make plans, test and migrate the data from legacy system.

• If NO – get Data Retention/Archival requirements – Where to archive/retain the data (on tape or live system)? How data will be accessed? How long and who can access? Any additional report requirement should also be planned here.

• Classification of the data (strictly confidential, confidential, internal, customer, public etc.): Are there any contractual obligations with customer(s) on the data? If so, consider during the data retention planning.

• Regulatory requirements of data retention – Are there any SOX, legal requirements?

Dependency – Will there be an impact on other applications? If so, you need to plan it jointly with both application’s Business Owners and mitigate the risk of disruption to dependent systems.

Has the Business identified new platform? And started using it?

Send the business owner the completed questionnaire when it has been created so they may fill it out with the information they currently have. This questionnaire might not be filled out right once since the business owner needs to take into account a lot of aspects, including... Can the company name the new platform (replacement system)? Does the new platform offer the same features they require? Will there be an impact on end users (external customers, if the application is utilised externally)? How do users transition to the new system? Etc. You will need to be patient and provide adequate time for this process. It may be necessary for you to schedule a few phone calls with your business owner (Business Information Officer). The majority of the fight is won after this is completed. You can plan the retirement around the inputs received from the business.

Now, focus on completing one activity at a time while creating a thorough strategy for each important task. If the application is huge and crucial, I advise tackling the data retention requirements first because it can take a long time. Another thing to take into account is that the work involved in creating new reports or a new archiving environment should justify the necessity for it. Most of the time, a significant effort is not necessary because historical data loses significance with time. For historical reporting purposes, existing reporting environments can be utilised. Validating the additional standards also heavily depends on the lifespan of the archival/reporting environment.

Step 2: Plan Read-only Day

This is the day you lock down the application. No inserts/updates/deletes to data are allowed once application moves into read-only mode. Following points can be considered in this step:

1. Create a detailed implementation plan to change the application in read only mode.
2. Identify the owners for all the tasks; you might need resources from various infrastructure teams like Web Administrator, Database Administrator, and Systems Administrator etc.
3. Set up a meeting to review the implementation plan with all the stakeholders and get their sign-off.
4. Test this in the Dev/Test landscape, and validate the implementation plan
5. Get the business owner (Business Information Officer) sign-off in test landscape.
6. Prepare the rollback plan – yes, it is not required, however sometimes it is worth having. There could be a scenario which was not considered in the planning phase.

At the end of this step, you are ready for a historical day for the application; it will go into static mode! After making the application static, final data can be migrated to target/archival system based on your Data Retention plan.

Best Archiving Legacy System Software

Step 3: Data Migration

Data migration is planned if business needs the historical data to be available in the new platform. You can consider following tasks while planning data migration:

1. Prepare Data Migration Plan
2. Get the mapping for target system and do the massaging as needed
3. Involve all the stakeholders and review the migration plan
4. Test the data migration in a test environment
5. Do the User Acceptance Testing and get business signage
6. Execute the same plan in the productive system after marking the application read-only

The need of creating an archive environment decreases if you want to migrate your data to a new platform. Even if the migrated data is available in the new system, an archive environment can be required for additional purposes like legal, SOX, etc. You and the business owner will need to evaluate the circumstances and come to a reasonable conclusion.

Data retention may need to be considered in situations when data transfer is not anticipated for historical reporting or regulatory requirements. When considering data retention and archiving, the following topics should be taken into account:

Build Archival/Reporting environment – if environment has been already available, additional report requests can be planned here.

Life of Archival/Reporting environment – how long this environment is needed? Administration of reporting environment – who will administer the access to data?

How do you make sure that the historical data is not manipulated / updated? 

This might be required for some SOX applications. After the retirement of reporting environment – how long data is required to retain on backup tape?

Step 4: Actual retirement of the application

In this stage, you really turn off the hosts and shut down the web server, application server, and data server. The device is then taken out of the datacenter by IT and disposed of safely. The decommission strategy you construct in this stage should take the following factors into account:

Prepare a list of all the server instances used – make sure you are not decommissioning a shared server instance.

1. Add steps to stop the web server/application server/data server instances
2. Add steps to power-off the host machines – definitely with the help of Systems Admin
3. Retire the host as per the organization’s host retirement policy
4. Update your application portfolio list accordingly to reflect the current status of the application.

Maintaining documentation in a single location that can be accessible by Project Management, Program Management, Change Management Authorities, etc. is another crucial step during the project. It should contain the business owner's completed questionnaire, a retirement plan, implementation plans, and emails from the business owner approving each step.

When planning an application retirement project, the majority of the work is done in the planning stage when coordinating with the company on the archive needs and deciding on the read-only/retirement dates; therefore, when making predictions, be sure to include enough time for planning.

World's Best Archiving Legacy Systems