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.  

Microsoft Platform Migration Planning and Consolidation

Minimize the risk, time, cost, and complexity associated with your next Exchange Online Domain Transfer

Learn more!

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

Subject: IMPORTANT: Upcoming Email Migration and Impact to Your Login Credentials 
Dear [User], 

We wanted to let you know that we will be performing a migration that will impact you starting on [date and time]. This migration will enable us to better serve you and provide improved features and functionality within Microsoft 365. 

During this migration, there will be a temporary suspension of your email service, which means that you will not be able to access your email for a period. We understand that this may be inconvenient, but we will work to keep the downtime to a minimum. 

Additionally, we would like to make you aware that once the migration is complete, you will continue to use the same email domain to access your email and other company resources. Your old email domain will no longer provide access to resources in the old tenant. However, you can temporarily switch to your onmicrosoft.com domain to authenticate to the old resources while available. 

To help prepare for the migration, we have created a list of frequently asked questions (FAQs) and “How Tos” that you may find useful. You can access these FAQs [insert link to FAQs]. 

We apologize for any inconvenience this may cause, and we appreciate your patience and understanding during this transition. If you have any questions or concerns, please do not hesitate to reach out to our IT support team at [support email/phone number]. 

Thank you for your cooperation and understanding while we continue to improve privacy, safety, and productivity! 

Best regards, 
[Department and Name] 

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.  

Microsoft Platform Migration Planning and Consolidation

Minimize the risk, time, cost, and complexity associated with your next Exchange Online Domain Transfer

Learn More!

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. 

About the Author

Richard Dean

Richard Dean is an accomplished product leader and experienced solutions architect with over 20 years in the IT industry, specializing in Microsoft Cloud & Hybrid technologies. As the Senior Manager of Technical Product Management for Quest, he excels in addressing the complex challenges associated with Microsoft 365 management, resiliency, and migration. With his extensive experience in the industry, Richard has helped both SMBs and large enterprises to consolidate, modernize and transform their IT infrastructure, resulting in significant cost savings, efficiencies, and reduced overhead.

Leave a Reply