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 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.
