# Cutover runbook
As noted previously, migrations can be complex, with many moving parts that span hardware, software, people, processes, and organization. To ensure success, consistency, and eventual acceleration, a well laid out plan that is documented and agreed to by all stakeholders is essential across all stages of migration. Such a plan can be documented by using a cutover runbook.
A cutover runbook covers all the activities that must be completed for a given migration. It is a comprehensive and detailed guide of the following:
+ Activities
+ Planned timeline
+ Actual activity timestamps
+ Success criteria for each step
+ Ownership for each step
When preparing the cutover runbook, ask yourself the following questions and provide the answers in your plan.
| Question | Why it is important |
| --- | --- |
| Does the cutover need a downtime? | Extended downtime will impact your users' experience. When preparing your cutover plan, try to minimize the downtime of your application or system. |
| Do you need to synchronize the data before the cutover? | If you migrate the storage layer, such as Amazon Elastic Block Store (Amazon EBS) volumes or Amazon Simple Storage Service (Amazon S3) buckets before the cutover without using a continuous replication mechanism, the storage layer might get out of sync. In such cases, make sure to do a final sync after you shut down the source services but before you start the cutover. |
| Who should be aware of the planned cutover? | Notify all stakeholders and users about the planned downtime. |
| Do you want to split the migration into smaller parts or migrate everything at once? | If you migrate a complicated system, it makes sense to split the migration into phases and perform several cutovers. For example, you can migrate the data layer first. |
| Do you need any external vendor support? | You might need to contact the external vendors several weeks ahead of your planned cutover to ensure their availability. Check with the vendor about any licensing considerations to be aware of. |
| Do you need any special approval for any part of the process? | Get any required approvals a few weeks before the planned cutover. |
# Cutover runbook template
A cutover runbook should include all the activities that will be performed during the cutover. However, it is equally as important to prepare a pre-migration template or checklist. The template should include activities to be completed before the migration.
Both templates (which can be merged into a single document) should provide the answers for the following questions:
+ What activities are to be performed?
+ Who is going to perform the activities?
+ When should the activities be performed?
This section includes an example pre-migration checklist, a cutover runbook template, and a rollback plan. The task IDs help to make communication faster and more effective.
## Pre-migration checklist
| Task ID | Task | Dependency | Team | Owner | Completion date | Status | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| P1 | Target architecture document approved. | | | | | | |
| P2 | Target account for application exists. | | | | | | |
| P3 | Virtual private cloud (VPC) and subnets for the application exist. | | | | | | |
| P4 | Migration team has access to the target application account and has the required AWS Identity and Access Management (IAM) permissions. | | | | | | |
| P5 | Application team has necessary access to the target application account and its resources. | | | | | | |
| P6 | Change Request raised and approved. | | | | | | |
| P7 | Connectivity between source and target environment established and tested. | | | | | | |
| P8 | Application team contact list documented. | | | | | | |
| P9 | Cutover plan reviewed with key stakeholders. | | | | | | |
| P10 | Pre-migration backup activities completed. | | | | | | |
| P11 | Confirm if additional support contacts should be put in place. | | | | | | |
| P12 | Confirm resources for each application: Who will start and shut down each individual application. | | | | | | |
| P13 | Final cutover plan issued to all contributing teams. | | | | | | |
| P14 | Cutover commencement communication issued to key stakeholders. | | | | | | |
| P15 | Post-cutover retrospective meeting scheduled. | | | | | | |
It is equally important to document the previous items in an issue log to stay on track or, if anything goes wrong, bring it back on track.
## Cutover runbook
| Task ID | Task | Dependency | Team | Owner | Planned start date/time | Planned end date/time | Actual start date/time | Actual end date time | Status | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C1 | Send an information note to all stakeholders informing that the application will be down as specified in the CR. | | | | | | | | | |
| C2 | Confirm backup of the source servers and databases. | | | | | | | | | |
| C3 | Stop application and DB services on source servers. | | | | | | | | | |
| C4 | Shut down source servers. | | | | | | | | | |
| | **Milestone 1** **Pre-cutover activities completed ** | | | | | | | | | |
| C5 | Perform migration based on your migration approach (such as AWS Application Migration Service for lift-and-shift). | | | | | | | | | |
| C6 | Verify the infrastructure (target servers up and running). | | | | | | | | | |
| | **Miilestone 2** **Migration completed** | | | | | | | | | |
| C7 | Update DNS servers to point to the newly created endpoints. | | | | | | | | | |
| C8 | Verify DNS changes. | | | | | | | | | |
| | **Miilestone 3** **Post-migration activities – Infrastructure completed** | | | | | | | | | |
| C9 | Start application and DB services on the target servers. | | | | | | | | | |
| C10 | Apply application-specific configuration changes (for example, point to new IP addresses). | | | | | | | | | |
| | **Milestone 3** **Post-migration activities – Applications completed** | | | | | | | | | |
| C11 | Perform post-migration application testing – Technical verification. | | | | | | | | | |
| C12 | Perform post-migration application testing – Business verification | | | | | | | | | |
| C13 | Communicate to all key stakeholders that migration has been completed. | | | | | | | | | |
| | **Milestone 4** **Post-migration testing completed** | | | | | | | | | |
## Rollback plan
| Task ID | Task | Dependency | Team | Owner | Status | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| R1 | Stop application and DB services on target servers. | | | | | |
| R2 | Shut down target servers. | | | | | |
| R3 | Revert the update on the DNS servers (to point back to the source servers). | | | | | |
| R4 | Verify DNS changes. | | | | | |
| R5 | Start source servers. | | | | | |
| R6 | Synchronize data back to source servers (if required). | | | | | |
| R7 | Start application and DB services on sources servers. | | | | | |
| R8 | Perform application testing – Technical verification. | | | | | |
| R9 | Perform post-migration application testing – Business verification. | | | | | |
| R10 | Communicate to all key stakeholders that migration has been rolled back. | | | | | |
## Example template for the rehost strategy
One of the most common R type migration strategies used in the field is the rehost strategy, with Application Migration Service as the migration tool of choice. You can use the [sample template](samples/cutover-runbook_template.zip) as a baseline document in a rehost scenario. The template incorporates essential activities that were encountered during actual customer engagements. It also includes space for application teams to add their tasks and activities. The steps in the previous section can provide initial guidance for creating your own customized cutover runbook as required.