Sunsetting Evaluation Template

This is a template for sunsetting services/softwares, as opposed to infrastructure.

1. Identify the Product Owner(s) for the system. 
   Product Owners should be consulted on each of the steps that follow in this process.
   
   
2. Define the service that is being considered for sunsetting.
   The service should be defined in the Service Catalog Data section of Confluence and reviewed by the Sunsetting group with the owner/stakeholder and technical manager.
   
   
3. Determine who is still using this service.
1. Check access logs, timestamps for modified content.
2. Review LibAnswers queue and L-support tickets for references within the last year to this service.
3. If appropriate, touch base with users identified by the service owner/technical manager.
   
   
4. Determine what other services integrate with or depend on this service.
   The Sunsetting group will work with the owner and technical manager to document all integrations and dependencies.
1. Which dependencies/integrations transition to other supported services?
   
   
5. Does this service need a successor service?
   The Sunsetting group will determine whether there is a need for this with the owner and stakeholders identified by the owner.  The group will work with the appropriate developers to make a plan for a successor.
1. If so, develop a plan for the successor
2. If not, briefly document the reasoning behind sunsetting this service without a replacement.
   
   
6. Develop successor service(s).
   The Sunsetting group will work with developers and stakeholders to schedule and coordinate phases of development.
   
   
7. Transition service dependencies as appropriate to successor services or other systems.
   The Sunsetting group will develop a transition schedule and communication plan for stakeholders and users, with the owners and technical managers.
1. Are there any critical issues that should influence the decommissioning schedule (ie, end-of-life software, license expiration for a service we hope to retire, etc)
2. How does the decommissioning process impact staff?  Are there previously-set project deadlines or training needs that need to be considered?
   
   
8. Determine an appropriate backup/restore strategy.
   Determine what is needed, and what is reasonably possible.  Is it necessary to be able to restore the service for some length of time after sunsetting?  Is it reasonable to plan for the ability to restore this service?  Does data need to be backed up?  What units of data are not reflected in a successor service, and would be valuable to back up to a dark archive, such as the pul-archivedbackups bucket on AWS?
   
   
9. Execute the decommissioning process.
   1. Document where backups are stored, how to access them, and how to restore the service.
   2. Keep backups of powered off services that can theoretically be restored for emergency staff access for one year (ensure this is communicated to Product Owners).
      
      
1. Disconnect devices from the network, wait at least two weeks to see if users complain.
2. Execute processes needed for backup/restore strategy, and power off the device. 
10. Record statistics for services sunset, including infrastructure that has been reclaimed and/or decommissioned.
    The Sunsetting group will ensure that the service catalog, documentation, and statistics on sunsetting efforts are recorded and kept up-to-date.