• Determine if the application should be decommissioned
• Steps to take once the decision has been made

Determine if the application should be decommissioned

A determination will be made that an application should be decommissioned

1. The developer, functional lead (i.e. business application owner/contact), Org Admins (if applicable) and LCS service team will all be involved in the decision-making process to determine if an application should be decommissioned.
2. A few indicators will help in the determination. 
   1. Betty Blocks will be providing the last time the application had been changed in the IDE (Betty Blocks app dev platform). 
   2. Betty Blocks also can track internal and external application users to determine when the last time someone logged in. 
   3. The functional lead will inform the rest of the group that an alternative has been established. (e.g. new application, new module of an existing application or just no longer needed) 
3. The application manager/functional lead will approve the decommissioning of the application by signing the Fillable_UW Madison Low Code Solutions Application Decommissioning SignOff 
   1. Per the signoff, the application manager is responsible for notifying all application users, appropriate data stewards, and all other appropriate parties of the decommissioning. 
   2. Per the signoff, the application manager must also ensure that all links to the application have been removed from websites, other applications, etc. 

Steps to take once the decision has been made

Once an agreement has been made to decommission the application, 

1. The Org Admin (if applicable) or LCS team should change the production instance from Live back to Development.  
2. A Betty Blocks support ticket should be created requesting Betty Blocks to make the application totally inaccessible, even from within the IDE. 
3. Users should be removed from having access to the application. For example, if Manifest groups were used associated with the application roles, the Manifest groups should be removed. 
4. Data retention 
   1. Determination should be made if any application data needs to be retained, making note of data that would be relevant under UW’s data retention policy. 
   2. Determination should be made of the sensitivity level of the data (e.g. restricted, low/med/high risk level) 
   3. Data is exported from Betty Blocks using appropriate security. 
      1. The methodology would consist of utilizing the data API for the application to move the data into an encrypted at rest AWS S3 bucket, such that there is a separate bucket for each application. Then move the data into S3 Glacier if extended retention is needed. 
5. Image and document retention 
   1. Determination should be made if any application saved images or saved documents (e.g. actual pdfs, uploaded artifacts) is under UW’s retention policy. 
   2. If images or documents must be retained, they will be exported using the same methodology as outlined above. 
6. The Org Admin or LCS team should update the IT inventory indicating the decommissioning of this application along with uploading (if possible) the approval by the application manager/functional lead and/or indicating in the description who approved the decommissioning, time/date and the location of the data if retained. 
   1. Access to retained data, images and/or documents will be made available only on a need-to-know basis. Approval can be granted by the appropriate data steward, the cybersecurity team or the application manager/functional lead.