IT Applications are implementation of business processes and help organizations to carry out day to day business efficiently. These applications are important to business and hence they are in existence. Therefore, retirement of these applications should be planned carefully so that there is no disruption to business users and they are smoothly migrated to a new platform.
Application retirement is the last stage in application life cycle. Many different factors can trigger this event such as technological advancement, business needs, acquisition, merger, underlying business process becoming obsolete, etc. This write-up is based on an experience in merger & acquisition. In some way, it benefits the organization and is also linked to organizational strategy and goals.
This blog explains the topics you need to consider while decommissioning an application. It gives a high level idea about retirement process and will help you build the foundation of your plan. I have divided application retirement into 4 major steps; however, there could be more/less steps by the nature of the application. The entire plan is based on the assumptions that the Application will be decommissioned in a phased manner: first, lock-down the application (putting in read-only mode), and, after a defined time frame, actual decommission of application and related host machines happens. If your application is directly going to retirement phase, meaning there is no gap between read-only and actual decommissions date, the plan will be simple.
Step 1: Create a questionnaire – The foundation stone
When you think of application retirement, the first question that comes to your mind is: where do I start? So, this is your stating point. Read through the below points and create a questionnaire by picking the questions of your interest. Make sure your questions are clear and to the point.
- Read-only date – When can application be marked read only?
- Retirement date – When can application be retired completely?
- 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?
Once a questionnaire is prepared, send it to the Business Owner to fill out the information he/she has at that point. You might not get this questionnaire filled immediately, because the Business Owner has to consider many factors before filling the questionnaire; for example... Is the business able to identify the new platform (replacement system)? Does the new platform have similar functionality they need? Will end users (external customers, in case application are externally used) be impacted? How to migrate customers on the new system? Etc. You will have to be patient and give this step enough time. You might have to set up a couple of calls with your Business Owner (Business Information Officer). Once this is done, most of the battle is won. You can plan the retirement around the inputs received from the business.
Now, attack one task at a time and prepare an exhaustive plan for each major task. I recommend attacking the data retention requirements first because it might take a considerable amount of time, if the application is large and critical. However, another point to consider is that the effort required in building the new archival environment or building new reports should justify the need for that. Most times, a large effort is not justified because as time proceeds the importance of historical data reduces. Existing reporting environments can be used for historical reporting purpose. Life of archival/reporting environment also plays a significant role in validating the new requirements.
Step 2: Plan Read-only Day - The data frozen 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:
- Create a detailed implementation plan to change the application in read only mode.
- Identify the owners for all the tasks; you might need resources from various infrastructure teams like Web Administrator, Database Administrator, and Systems Administrator etc.
- Set up a meeting to review the implementation plan with all the stakeholders and get their sign-off.
- Test this in the Dev/Test landscape, and validate the implementation plan
- Get the business owner (Business Information Officer) sign-off in test landscape.
- 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.
Step 3: Data Migration/ Data Archival Plan
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:
- Prepare Data Migration Plan
- Get the mapping for target system and do the massaging as needed
- Involve all the stakeholders and review the migration plan
- Test the data migration in a test environment
- Do the User Acceptance Testing and get business signage
- Execute the same plan in the productive system after marking the application read-only
Building an archival environment becomes less significant if you are planning data migration to new platform. Archival environment might be needed for other requirements like legal, SOX etc., even though migrated data is available in the new system. You will have to assess the situation and make a balanced decision along with Business Owner.
In some cases where data migration is not planned, data retention has to be planned for historical reporting or legal purposes. Following topics can be considered while planning Data Retention/Archival:
- 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/reporting environment
In this step, you actually shut down the web server/application server/data server and power-off the hosts.IT then removes the hardware from the datacenter and it goes for secure disposal. So in this step you have to create a decommission plan, following points can be considered in the plan:
- Prepare a list of all the server instances used – make sure you are not decommissioning a shared server instance.
- Add steps to stop the web server/application server/data server instances
- Add steps to power-off the host machines – definitely with the help of Systems Admin
- Retire the host as per the organization’s host retirement policy
- Update your application portfolio list accordingly to reflect the current status of the application.
One other important point throughout the project is: Maintain documentation on a central repository at each stage that can be accessed by Project Management, Program Management and Change Management Authorities etc. It should include Questionnaire filled by Business Owner, Retirement Plan, Implementation Plans and Business Owner Sign-offs/Approval emails at each stage etc.
In application retirement project, most effort goes into the planning phase while working with business on archival requirements and finalizing dates for read-only/retirement, so while doing projections make sure to allocate appropriate time in the planning.
Hope this will help you all working on application retirement projects! Thank you.
