Q4: Decommissioning Authorisation

Decommissioning Authorisation - [Project name]

Decommissioning lead	Normally an analyst
Date	Date documentation begins
Contact(s)	Check SLA to add relevant names, including technical contact for migrated sites
Authorisation	ie. who is supposed to be responsible for authorising the decom - usually PI
Date of activity	Add funder if applicable e.g. 2004-2005; 2007-2009 (funded by [funding-body])
Project management ticket	Link to decommissioning [project-management-software] task/s for sysadmin/developer
Archive URLs	- Project URL (original URL to become placeholder page if minimally archived (original URL)1 - Access to archived site/data (e.g. [institution-repository-here], other subject/institutional repositories, Web Archive) - Access to any relevant available code (e.g. [institution-repository-here])
Domain management	Project URL is managed by [institution-name-here]/Other institution/Person

1 There might be more than one URL for a project (see nagios). The aim is to pay domain name for one only but projects would need to be examined case by case. ↩

For guidance in completing this documentation stage please see the Decommissioning Authorisation guidelines.

OVERVIEW

Project overview; this can come from Terms of Reference or Service Level Agreement documents.

BACKGROUND CONTEXT

Any relevant background information that is relevant to the project, incl. rationale for the decision to archive or shut the site down.

SITE FUNCTIONALITIES

Decommissioning lead should choose a minimum of 3 screenshots representing the core site functionalities/interface (e.g. homepage; search page; browsing) and include minimal descriptive captions.

REQUIREMENTS

Any special requirements in regard of archiving (e.g. formats for depositing).

DECOMMISSIONING SOLUTION

Tick list followed by rationale for the chosen solution/s E.g. SQL files and content dump, stored in cloud storage - insert URL above in header table.
Some sample solutions:

• [RSE Team] minimal storage - retain VM image on high quality storage for a minimum of two years and then on a lower quality backup for as long as practicable thereafter
• [RSE Team] minimal hosting - static site from the resource
• [RSE Team] data repository - (e.g. CKAN - data entry so far costed @ 1 day per project)
• Migration to another host (specify which one) - suitable container for transferral to another host (include link to Statement of Work if applicable)
• Institutional data management service - deposited project-generated data and metadata on an institutional research data management service
• Other institutional/subject-specific/commercial archival or storage solutions (to be described e.g. ADS; UKDS; Web Archive; external clouds services) (include link to Statement of Work if applicable)

Rationale: rationale for the chosen solution/s e.g. SQL files and content dump, stored in AWS Glacier - insert URL above in header table

SUPPORTING DOCUMENTATION

Evidence such as correspondence, meeting minutes, awarded funding proposal (redacted as needed) and so on, for authorisation to archive. Wherever possible, include a stable link to the submitted proposal. This is to ensure, if there is an issue in the future with a complaint around what the funder expected, we can easily find what was stated.

Authorisation	Authorised by X at meeting/via email on DD Month YYYY
Role

SITE SPECS

Any relevant specifications connected to the working specs of the site at the time of archiving (e.g. software version, disk allocation, security issues) as well as any known vulnerabilities.

##DECOMMISSION CHECKLIST

Requirements met?	Yes/No/Not applicable - if No, give reason why
Date archived
Web stats	Link to analytics; PDF report from analytics platform)
Date fully decommissioned	Note date when project fully decommissioned (i.e. the dynamic KDL version of the site has been turned off) and notify decommissioning analyst and PM when done