Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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 service dependencies are on this service.
    The Sunsetting group will work with the owner and technical manager to document all uses and dependencies.
    1. Should/can dependencies 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. Execute the decommissioning process.
    1. Disconnect devices from the network, wait at least two weeks to see if users complain.
    2. Backup the service and power off the device. 
      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).

  9. 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.
  • No labels