Microsoft 365 Exchange Online Domain Transfers: Validation Phase Part II

Welcome back! If you missed part one, be sure to give it a read before continuing. In addition, be sure to check out our previous pieces on the topic to get all caught up.  

In the previous blog in this series, we covered how to prepare for the pilot event(s) by diving into domain acquisition options, environment, third-party dependencies, directory, account configurations, and properties, along with establishing a pilot user group with representative devices. 

In this edition, you will learn about the who, what, where, when, and why of validating the current communication plan developed during the strategy phase of the process.  

Communicate the plan 

Effective communication is crucial throughout the entire Proof of Concept (POC) migration process. It is important to inform all relevant stakeholders of the project timeline, scope, objectives, and potential impact on business operations. This will help to ensure that everyone involved is on the same page and can work together to minimize any potential disruptions. 

In addition to internal stakeholders, it is also important to identify and communicate with any external parties who may be impacted by the domain migration, such as vendors or customers who rely on your systems. This will help minimize potential disruptions to your business operations and ensure a successful transition to the new tenant. 

Who should we communicate with? 

As stated previously, you should communicate with all the relevant stakeholders who are affected by the domain migration. This includes IT administrators responsible for Active Directory, Azure Active Directory, Azure AD Connect, DNS Management, Security, End User Desktop Support, and key contact persons for any third-party dependency system that will be impacted by the domain migration.  

Additionally, you should inform end-users who will be impacted by the migration and provide them with appropriate communication materials and support. It is essential to establish clear lines of communication and ensure that everyone involved is aware of the migration plan, timelines, and any potential impacts to their systems or workflows. 

When should things be communicated? 

Here is an example timeline for communicating with stakeholders during an Exchange Online domain migration: 

1. Pre-migration: At least 4 weeks before the planned migration start date, send out an initial communication to all stakeholders. This communication should introduce the migration project, explain the reason for the migration, and provide an overview of the expected impact on end-users and business operations. 

2. Technical implementation: 2 weeks before the migration start date, send out a communication to IT administrators. This communication should provide details on the technical implementation of the migration, including any necessary changes to DNS records or firewall rules, and highlight any potential risks or issues that may arise during the migration. 

3. User Awareness: 1 week before the migration start date, send out a communication to end-users. This communication should explain the reason for the migration, provide an overview of the expected impact on their email access and usage, provide details on any changes to their login credentials, and outline any necessary steps they need to take to prepare for the migration. 

4. Migration starts: On the day of the migration start date, send out a communication to all stakeholders. This communication should confirm that the migration is starting and provide any necessary updates or changes to the migration plan. 

5. Post-migration: Within 24 hours of completing the migration, communicate to all stakeholders. This communication should confirm that the migration is complete, provide an overview of any known issues or concerns, and outline any necessary steps for users to access their email in the new domain. 

What should be communicated to the stakeholders? 

When communicating about the domain migration pilot, it’s important to provide clear and concise information about the purpose of the pilot, what it will involve, and what stakeholders can expect throughout the process. 

At a minimum, communicate the following to stakeholders: 

1. Purpose and scope of the pilot: Explain the goals and objectives of the pilot and what specific areas it will cover. This should include information on which systems or services will be migrated and any expected downtime. 

2. Timeline: Provide a detailed timeline for the pilot, including key milestones and deadlines. This will allow stakeholders to plan accordingly and be aware of any potential disruptions. 

3. Roles and responsibilities: Clearly define the roles and responsibilities of each stakeholder involved in the pilot, including IT administrators, end users, and any third-party providers. 

4. Communication plan: Outline how and when you will communicate with stakeholders throughout the pilot. This should include details on what channels you will use to communicate, such as email, meetings, or a dedicated project management tool. 

5. Contingency plan: Explain what will happen if there are any issues or unexpected problems during the pilot. This should include details on how you will identify and address issues and what the plan is if the pilot needs to be delayed or canceled. 

6. Feedback and evaluation: Explain how you will gather feedback from stakeholders and evaluate the success of the pilot. This can help you identify areas for improvement and ensure a smoother migration process when it comes time to migrate the entire domain. 

What should be communicated to end-users? 

For end-users, communicate the following: 

1. A high-level overview of the domain migration project, including the reasons behind the migration and the benefits it will bring to the organization. 

2. A timeline of the migration, including when it will begin and end, as well as any specific dates or times when there may be service disruptions. 

3. Any actions that end-users need to take before, during, or after the migration. For example, if they need to update any passwords or settings, or if they need to log in to a different portal or system. 

4. A list of available resources for end-users needing help or support during the migration process. This can include IT support contact information, FAQs, or other documentation. 

5. Reassurance that their data and information will be protected during the migration process and that they will be able to access their resources once the migration is complete. 

6. A reminder that communication channels will be available for users to report any issues they may experience during or after the migration. 

Overall, it’s important to communicate the changes and impacts of the migration to end-users concisely, addressing any concerns they may have and providing support as needed. 

Here is a very basic example of communication that could be sent to end-users before the migration begins: 

This example may not reflect the impacts on your environment, so please only use it as a baseline template to communicate with your end-user population.  

What’s next?

Tune in again for our final piece on the validation phase of your migration project. For our final edition, we will cover proper pilot auditing and documentation of the results to make final adjustments to the plan before presenting it to the larger project team during the Implementation phase.