Post migration cleanup
The intention of this document is to provide a run book for all activities required post migration to the Cloud Platform. This is an instructional document and will not provide a detailed description of each task.
Table of contents
- When to use this document?
- Turn off Template Deploy monitoring and alerting
- Archive the
- Backup old Template Deploy data
- Delete the old CloudFormation stack
- Ensure removal of resources
- Ensure live service is still functioning!
When to use this document?
Once a service has been migrated to the Cloud Platform from Template Deploy there will be a number of cleanup tasks required to ensure legacy resources have been removed. These tasks will be listed in this document.
Throughout this document, when using the term “service team”, we’re referring to the team in charge of the project that’s been migrated.
There are a couple of suggested pre-requisites before performing the tasks in this document.
0.1 Identify AWS account
Traditionally, production Template Deploy applications lived in the mojdsd AWS account, however, this isn’t always the case. You’ll need to identify which AWS account your application lives in. The recommended approach for this task is to speak to the service team’s Product Manager.
0.2 Ensure newly migrated application works
A lot of tasks in this document will involve destroying resources, it is vitally important you are sure 100% of production traffic is being routed to the Cloud Platform.
0.3 Identify and inform service team
All service teams generally have a Slack channel and a project manager. Please use these means to inform the team of the impending deletion of the Template Deploy version of their application.
1. Turn off Template Deploy monitoring and alerting
Monitoring and alerting for Template Deploy was achieved via a separate CloudFormation stack using a template from another project. This stack mainly consisted of Cloudwatch alarms and dashboards.
1.1 Identify the monitoring CloudFormation stack name
Access the AWS console and open CloudFormation. Identify the stack name, which has a suffix of
-monitoring, for example,
1.2 Delete the monitoring CloudFormation stack
CloudFormation stack deletion is fairly trivial. In the AWS console, select your stack, click actions and then delete. This will take a few minutes to complete but will disappear from your list of available stacks.
2. Archive the deployment repository
Traditionally there will be a Template Deploy GitHub repository usually named in the format
graphite-deploy). This repository is redundant and can be archived.
All actions in this task are performed in the
ministryofjustice GitHub organisation.
2.1 Identify the appropriate repository name
As stated above, perform a search in the
ministryofjustice GitHub organisation for your service name with the
2.2 Change the repository description
Simply add a
**DEPRECATED** message at the front of your description and perhaps a message explaining why the repository has been archived.
2.3 Add a note in the README.md
It is also appropriate to add a note at the top of the
README.md file signaling the reason for deprecation.
2.4 Actually archive the repository
GitHub have written a handy article on how to archive repositories. Please read through this document.
3. Backup old Template Deploy data
Not all Template Deploy applications have an RDS or data storage of some kind, so this task won’t apply to all services.
3.1 Identify RDS name in AWS console
This can either be identified by the
DB Instance name or via a tag. Either way, you can use the search functionality within the AWS console to identify the correct database.
3.2 Take a snapshot of the database
It is vitally important that we keep a snapshot of the database before it’s removed. This allows us to perform an emergency recovery if needed.
To complete this task in the AWS RDS console,
select your database > actions > take snapshot. Give the snapshot a meaningful name and select
4. Delete the old CloudFormation stack
This task is destructive, so please take care in selecting the correct resources. It is recommended to have a second pair of eyes on this task to ensure mistakes are at a minimum.
4.1 Identify CloudFormation stack name
Similar to the step above, the CloudFormation for the application stack will follow a logical naming structure, for example,
correspondence-staff-demo. Find the CloudFormation stack that belongs to your migrated service.
4.2 Delete CloudFormation stack
Before embarking on this task, please ensure you have the correct stack name (this is vitally important). To delete the stack, you must open CloudFormation, use the search function if necessary to locate your desired stack and select the delete button.
5. Ensure removal of resources
Following the destruction of the CloudFormation stack, it is recommended that you open services like EC2 to ensure all resources have been removed. This step is optional.
5.1 Search for resources
Open EC2 and perform a plaintext search for your project. For example, if your migrated project is named
pvb-prod simply type it into the search. Not all resources are named appropriately but they’re all tagged correctly.
5.2 Clean leftover resources
If your search proves successful and you find resources with your project name, simply select and delete them manually. Making a note for future reference.
6. Ensure live service is still functioning!
Following the successful migration to the Cloud Platform and deletion of the Template Deploy CloudFormation stack, please ensure the service is functioning correctly.
6.1 Is the service accessible by URL
Access the URL using your browser and ensure full functionality (make sure you aren’t seeing a cached version).
6.2 Check with service team
Any notes you might’ve taken should be shared with the service team, via Slack or email.