# Communication planning for a large migration to the AWS Cloud
Communication planning

Be it a digital transformation to a cloud-first strategy or an organizational divestiture to exit data centers, there are many parallel business unit (BU)-specific or technology-driven activities that will be in process outside of the server migration project. It is extremely important to make sure that all BUs and technology teams work toward the same goal of migrating to the AWS Cloud. In addition, you'll need make sure that all dependent activities that impact the large migration project are aligned within these teams to meet deadlines.

To support the alignment, the migration team must quickly define the communication strategy and cadence that provides a high level of visibility into the project. The large migration plan must foster high customer stakeholder engagement and include communication gates. A *communication gate* is a point when you formally communicate ongoing wave activities and status to the stakeholders, such as commitment meetings, checkpoints, cutover, hypercare period, and transfer of workloads to the cloud operations (Cloud Ops) team. Communication gates must have clearly defined exit criteria so that teams understand the requirements and can escalate quickly to remove obstacles.

**Topics**
+ [

# Governance structure and cadence
](governance-layers.md)
+ [

# Communication plan for the management layers
](communication-management-layers.md)
+ [

# Communication plan for the delivery layers
](communication-delivery-layers.md)
+ [

# Escalation plan
](escalation.md)

# Governance structure and cadence


Before the formal project kickoff, work with your project sponsor and stakeholders to establish mechanisms to communicate delivery progress for both the executive and non-executive stakeholders. Sharing the defined mechanism should be part of the project kickoff and should visually depict the communication cadence, objectives, and participants within each governance layer. The governance structure helps participants understand how the project will be managed, who the leaders are, how leaders will oversee the project, how decisions will be made, how and when issues will be escalated, and how progress will be measured.

The following diagram shows a top-down approach in the governance layers. The top three layers are the management layers, which are responsible for establishing the large migration strategy, program governance, and the workstream approach. The bottom three layers are the delivery layers, which are responsible for governing the communication gates and regular meetings, such as infrastructure and operations meetings, and migration business hours.



![\[Governance layers in order of management to delivery, as described in the following table.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-intro-governance/images/large-migration-governance-layers.png)


The following table describes the objectives and typical participants for each governance layer.


|  |  |  | 
| --- |--- |--- |
| **Governance layer** | **Objective** | **Participants** | 
| Strategic governance | Develop business and strategic plans, review contractual commitments, address escalated issues, and check overall performance. | Executive sponsor or executive steering committeeLeads for partners or consultantsMigration delivery leadership | 
| Program governance | Report and review the status of all workstreams, determine the need for resources or subject matter experts, and allocate time for migration team reporting. | Workstream ownersLeads for partners or consultantsMigration leadScrum masters | 
| Workstream approach | Support and review the status of planned and completed activities, and review blocked items for the PMO, foundation workstream, migration workstream, and Cloud Ops team. | Workstream leadsScrum masterTeam membersOwners defined in the RACI matrixManagers for partners or consultantsProject managerMigration lead | 
| Application owner commit meetings | Confirm commitment to the wave that is scheduled to start | Application ownersLeads for partners or consultantsMigration leadCommunication leadCustom migration lead | 
| Infrastructure and operations | Review the progress of the migration, review active issues, and decide whether escalation is required. Collaborate across workstreams and plan resources for the next sprint. | RACI-defined membersMigration leadLead architectConsultants for the migration, applications, SQL, or other special workloads | 
| Migration business hours | Provide application owners with an open meeting to seek support or guidance. | Leads for partners or consultantsApplication ownersMigration leadEngagement manager | 

# Communication plan for the management layers


For a large migration, provide a weekly status update and schedule a formal review with at least a bi-weekly cadence. This helps ensure that the myriad of parallel activities do not diminish the migration team's ability to migrate waves on schedule. Establish the following key formal communication checkpoints to report the project status:
+ **Weekly status updates** – This report conveys the current project progress and includes a current roadmap and use metrics. It is designed to share progress against the plan, highlight issues, and describe the key actions and decisions the project stakeholders must make to support the schedule. Include an appendix of supporting documentation. Post this weekly report to a predefined, shared repository. Key participants include the project sponsors** **and** **the project managers. For more detailed information about this meeting and presentation templates to support it, see [Define meetings and their cadence](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html#step-define-meetings) and [Prepare meeting presentations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html#step-prepare-presentations) in the *Project governance playbook for AWS large migrations*.
+ **Benefit-tracking office** – This team is a small group of individuals who are responsible for assessing the migration against key performance indicators (KPIs). This team evaluates whether the migration is progressing according to schedule and can act on any delays or issues impeding progress. Also, the team can provide real-time progress reports that leadership can access at any time to understand progress against defined goals. This team meets outside of the weekly or bi-weekly project status meetings. Typical members of this team include the project sponsor, project manager, migration lead, and an empowered representative from each business unit that has workloads in scope. For more detailed information about this meeting, see [Establish a benefit-tracking office](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-project-management.html#step-benefit-tracking-office) in the *Project governance playbook for AWS large migrations*.

    
![\[The benefit-tracking office assess progress against project benchmarks and refines the benchmarks.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-intro-governance/images/large-migration-benefits-tracking-office.png)
+ **Financial reporting** – This meeting is typically scheduled bi-weekly. The purpose is to track the current financial state and financial forecast, both for the project and for AWS usage costs. This team also reviews project decisions that have a financial impact, such as resources, scope, amendments, and new statements of work (SoWs). This meeting typically includes the project sponsors, migration team senior leadership, and project manager.** **For more detailed information about this meeting and a presentation template to support it, see [Create a financial reporting process](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-project-management.html#step-financial-reporting) in the *Project governance playbook for AWS large migrations*.
+ **Steering committee meetings** – These meetings are typically held twice a month, and the objective is to share the project status and resolve any issues that require involvement from executive leadership. Participants of this meeting typically include the project sponsor, executive leadership, and a representative from the project management office (PMO). For more detailed information about this meeting and presentation templates to support it, see [Define meetings and their cadence](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html#step-define-meetings) and [Prepare meeting presentations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html#step-prepare-presentations) in the *Project governance playbook for AWS large migrations*.

# Communication plan for the delivery layers


The communications and meetings for the delivery governance layers are typically designed to facilitate the migration activities and coordinate across the portfolio and migration workstreams. There are communications that are intended to facilitate project management and communications that are intended to inform or help application owners and other owners of migration tasks, as defined in a responsible, accountable, consulted, informed (RACI) matrix.

## Project management team communications


The following communications and meetings are intended to support the project management aspects of the migration:
+ **Workstream daily stand-ups** – Using the roles and responsibilities defined within your RACI matrix, ensure the migration team participates in a daily stand-up meeting. As part of the working agreement within each workstream, establish a KPI that immediately starts the escalation process if one or more defined application owners are not participating.
+ **PMO daily stand-ups** – Schedule a daily stand-up meeting with the workstream leads and oversight leadership. Use this meeting to make sure the team is aligned and communicate any activities or delays that impact other workstreams.
+ **Communication gates** – The project management team must participate in all communication gate meetings and notifications, which are described in detail in the next section, [Application owner communications](#app-owner-communications).

## Application owner communications


When planning and cutting over waves, you must establish mechanisms with application owners to ensure their commitment and easily initiate escalations. We recommend that you adopt a communication gate framework. The communication gates are repeatable touchpoint events for each wave or group of waves, and they clearly establish the criteria that must be met to proceed to the next gate. For more information, see [Define the communication gates](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-create-communication-gates.html#step-communication-gates) in the *Project governance playbook for AWS large migrations*.

To align all parties on the communication gates and migration activities, the project management team should define a T-minus schedule. A *T-minus schedule* is a visual way to represent all of the high-level migration activities that need to be completed for each wave. It covers the period of time between the end of wave planning and the end of the hypercare period. For tracking tasks and progress, we recommend a visual management tool such as a Kanban board or Gantt chart. For more information, see [Create a T-minus schedule template](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-create-communication-gates.html#step-create-tminus-schedule) in the *Project governance playbook for AWS large migrations*. The following image shows an example of a T-minus schedule.



![\[Sample T-minus schedule\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-intro-governance/images/large-migration-t-minus-schedule.png)


As defined in your communication gates, you have the following regular meetings and communications with the application owners and migration team for each wave or group of waves:
+ **T-28 commit meetings** – About four weeks before the scheduled cutover, you conduct this formal wave kickoff. In this meeting, you share the T-minus schedule, make sure application owners understand the migration process and their tasks, and review key milestones. The purpose of this meeting is to make sure that the application owners are ready and committed to the cutover date the hypercare period. For more information, see [Hypercare period](preparing-organization.md#hypercare).
+ **T-14 checkpoint meetings** – About two weeks before the scheduled cutover, you conduct this formal checkpoint with the application owners, the communication lead, and the migration lead. The purpose of this meeting is to confirm the application owners are ready for cutover and address any questions or concerns. This meeting identifies key issues that need to be escalated to leadership, such as an application owner communicating that they want to remove their application from the wave. The project management office (PMO) prepares the agenda for this meeting and customizes the presentation to include the servers and applications in the wave.
+ **Weekly communications** – In your T-minus schedule, you define regular communications with the application owners and other stakeholders. These communications are intended to remind stakeholders about upcoming activities or notify them of meeting key milestones. Standard communication points include T-28, T-21, T-14, T-7, T-1, T-0, cutover compete, and hypercare period end. We recommend you create standard templates for these communications.

For presentation and communication templates, see [Create standard email templates for each gate](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-create-communication-gates.html#step-email-templates) and [Prepare meeting presentations](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html#step-prepare-presentations) in the *Project governance playbook for AWS large migrations*.

# Escalation plan


One key challenge for nearly all migrations is securing commitment from the application owners and technical support resources to support the wave plan. Therefore, in addition to having a well-defined communication plan, it is even more important to define an escalation plan. For each wave, starting with the T-28 commit meeting through the T-0 cutover date, you need to ensure that you facilitate commitment on a weekly basis. If any issues arise or an application owner cannot commit to the cutover date, you initiate the escalation plan.

When establishing the escalation plan, you need to define the type of issue, the circumstances in which you should escalate the issue (known as the *trigger*), and define the tiers of escalation. We recommend no more than three tiers. For each tier, you should identify the *audience*, or *response owner*, and the amount of time that the audience has to respond.


|  |  |  |  |  |  | 
| --- |--- |--- |--- |--- |--- |
| **\$1** | **Issue** | **Trigger** | **Tier 1** | **Tier 2** | **Tier 3** | 
| *Audience* | *Escalate after* | *Audience* | *Escalate after* | *Audience* | 
| 1 | Firewall ports need to be open to migrate workloads to AWS | Firewall isn't open by T-28 commit meeting | Network team, migration lead | 24 hours | Network team manager | 24 hours | Executive team, lead of impacted business unit | 

It is important that you share the escalation plan during the project kickoff. By defining and sharing this plan before the migration starts, you can provide a clear process to the team in advance, which helps prevent delay, frustration, or surprises. We also recommend that you share the escalation plan again during the T-28 commit and T-14 checkpoint meetings to reinforce commitment from the application owners.