Decommission Plan for MyUW applications and widgets
Overview
Applications that are found to be broken, no longer used, are no longer useful etc need to be removed from the MyUW system. This plan outlines that process.
Purpose/Reason
Common reasons for application decommissioning:
- They are not currently operational
- They have not been updated
- They have other technical debt
- Decline in use
- Technology has improved since the apps were developed and app functionality is no longer needed
- Resources required to update the app exceed the benefits gained from use of the app
End of Service Plan
|
Things to consider |
Examples |
|---|---|
|
Stakeholders |
Example: Students, Registrars office, Users of the service, Employees |
|
Communication Plan/User off-boarding |
Example: Banner message or bell alert in MyUW, KB article, email, newsletter, verbal announcement within a meeting |
|
Decommission Date |
Example: Start Communication Date: December 23, 2022 Date Service Offline Date: January 20, 2023 End Communication Date: March 21, 2023 |
|
Feedback Channel for Users |
Example: Feedback form |
|
Plan to address feedback from Users |
Example: Review data from feedback form every 48 hours and respond weekly. Tom will be responsible for this task. |
|
Address any outstanding use cases |
Example: Workaround identified. Details provided in KB doc #XXX |
|
Develop a plan to monitor usage during service decommission |
Example: Google Analytics will be used to monitor attempts to access the apps. A feedback form has been created to collect feedback around the services going offline. |
|
Develop an End of Service Plan |
Example:
|
Offline the Service
High-level Overview to Offline Service
- Notify interested/affected groups of the Service Offline and Service End Dates
- Users can no longer access the system after the Service Offline Date
- Enact Engagement Strategy and include plans to direct users to alternatives
- Remove access to the application
- Data migration to archives as required
- Update, remove, or redirect KB documentation for the service
- Modify entries in Change/Mgt tool (CMDB) to reflect the decommissioning process status
Technical Process to Offline the Service
Include tasks to be completed by the team that hosts and/or maintains the service.
MyUW Tasks
- Place application into maintenance mode.
- Consider UX options
- applying a soft message or shade over the application in which the Learn More button directs the user to the app’s KB.
- redirect the tile to a feedback form.
- Disable Jenkins Job (if necessary)
- When something is purely data (an entity file), there's no change in Jenkins.
- When something is a Portlet or custom web application, usually there will both be Jenkins job(s) for building the software product and also Jenkins jobs for building overlays on the software product.
Decommission Process
MyUW Tasks
- Layout Engine Considerations
- Remove widget from personal engine
- Remove app from defaults in layout engine (if needed)
- Enterprise Archiving
- Remove from Entities
- Remove from Ear
- Delete Jenkins Job from automatic builds
- Archive app in the git.doit git repos
- Delete configuration from Apache HPD
Decommission Support:
Contact the Service transition team to file a Service Decommission WiscIT change Request.
The Service Transition team handles the following areas of decommissioning a service's support:
- Help Desk incident handling and escalation
- Help Desk KB documentation
- Event Management and Monitoring
- SNCC 24x7 Problem and Outage escalation
- Status of the service's Configuration Items and their relationships in the CMDB
- COOP (Continuity of Operations)
End of Service Plan Completion
- Review the Decommission Process tasks with stakeholders where necessary
- Review Decommission Process tasks with technical team
- Complete an End of Service Review with product owner, reviewing feedback received in feedback form.
- Complete the Project Close document (template may be available).