Decommissioning an application or platform

[#1]

For those of you who have unfortunately found yourself managing applications for a company that is closing its doors, you’ve undoubtedly been faced with the task of decommissioning an application or platform.  Hopefully, your application documentation is thorough enough to make this process less painful but this article aims to outline the steps involved and open a conversation to address any gaps and refine the process.  Please note that while some of the content may apply across platforms, this article is specific to applications that are managed on-premise as opposed to cloud-based (SaaS) apps.

Not all items listed below will apply for all scenarios and the order or execution is dependent on your own environment. 

⭐ALWAYS decommission lower-environments (dev, test, staging) first before decommissioning your production environment.⭐ Another good rule-of-thumb before fully decommissioning any application is to first disable services for a period of time.  If no issues surface, proceed with the decommission process.  You will also want to take a final backup in the event that you need to restore the application.

• ALWAYS NOTIFY YOUR STAKEHOLDERS / END USERS WELL BEFORE APPLICATION SHUTDOWN WITH THE SPECIFIC DECOMMISSION TIMELINE.

• Determine what to do with the application data (archive?  migrate to another application?)

• Refer back to your architectural diagram to capture dependencies
• Cancel open requests pertaining to the application / platform
• Decommission any automation residing outside of the application.  This may require full source code repository decommissioning or various stand-alone script or cron disables.  This may also include startup scripts, automated monitoring and application backup processes.
• Cancel support contracts / licensing
• Archive and update documentation (policies, procedures, Confluence spaces).   This includes updating all references to the application being decommissioned.
• Adjust allowlists, ACLs, subnets, and firewalls as needed
• Archive / Disable DR procedure
• Decommission Service Accounts
• Decommission email Distribution Lists
• Decommission onboarding / offboarding workflow
• Disable Runbook
• Archive associated Jira projects
• Retire Asset/CMDB entries
• Remove / revoke public and private SSL certificates
• Decommission Database and Storage (including dev, DR and backups)
• Decommission Hardware (servers, load balancers)
• Decommission container platform
• Reclaim IP addresses
• Remove DNS records

I hope this helps.  Please feel free to suggest edits to this article!