Five Best Practices for Microsoft 365 Exchange Online Domain Transfers

Standardized Exchange Online Accepted Domain Transfers Ensure a Seamless User Experience

Domain Name plays a vital role in your organization because it lays the foundation to support all business applications. For example, it is utilized to establish your corporate identity, email delivery, and authentication. After you have completed your content migration during a cross-tenant consolidation project and your users are working from the new target tenant, it is time to transfer the Exchange Online domain name space to the remaining tenant if it will continue to be used by the new organization. Unlike migrating traditional content such as mail, files, and devices, moving a domain in an office 365 tenant-to-tenant migration is a monolithic, multi-step, and risky procedure. In this guide, you will learn five (5) best practices for moving your domains between Microsoft 365 tenants. These best practices are designed to assist migration administrators in the deployment of a well-orchestrated, standardized process from planning to execution to ensure a seamless user transition with little or no email downtime. 

In this blog series, we will provide a detailed project workflow that can be adapted for your project purposes. We will list our top 5 must-do best practices for any upcoming domain move project. Finally, we’ll break it all down into the details you want with a comprehensive set of best practices for you to consider when planning your next Cross-Tenant domain migration project.

Top 5 Best Practices for Exchange Online Domain Transfers

Analyze

Always start by assembling a complete picture of the environment. – Know what you have. Track the known application and information systems dependencies. Recognize your business needs. Understand the email downtime risks and mitigation strategies.

Strategize

Formulate strategies to address the known pitfalls – Every organization planning a cross-tenant domain move must have answers to these six potential problem areas.

1. Plan what type of end-user experience your business requires before, during, and after the migration.

2. Plot how email will flow during the period when the domain is removed and transferred.

3. Know how this could impact service accounts

4. Decide if this environment is the right size for a single (big-bang) event or whether a phased approach will work better due to the size of the enterprise or having multiple domains to move.

5. Have a rollback or recovery strategy

6. Agree on when is the “point of no return” for any potential rollback to occur.

Validate

Always pilot the process using temporary vanity domains. – You’ve completed your analysis and strategy planning. Now it’s time to put your plan to the test for Exchange Online domain transfers.

1. Procure and configure one or more vanity domains to validate the process from end to end.

2. Configure directory test objects to meet the pilot requirement.

3. Test your communication plan.

4. Document end-user experiences before, during, and after the pilot migration

5. Complete a dry run of your rollback recovery plan.

6. Finally, assess the results, refine the plan based on lessons learned, and fully document the process in a project plan to verify each step along the way.

Implement

Assemble your stakeholders and implementation team so everyone knows the event timetable and the parts they play, and always establish a Go/No Go event bridge.

1. Before executing the live event, be sure to fully review in detail the planned processes and strategies with the entire event team. Upon review, decide when it is best to start this event based on business requirements.

2. Before starting, meet to decide if all prerequisites are ready and confirm that no new business events are superseding the planned event.

3. During the event, communicate with stakeholders throughout each phase and always keep a line of communication open during the event in the form of a triage center. Establish a central phone or meeting bridge where the principal engineers orchestrating the implementation can continuously communicate and where other stakeholders may connect at any time for live status updates.

Remediate

Always make sure it’s working afterward; if not, have the right people in the room to fix it quickly.

1. Tally the results of each of the moving parts and ensure all the target objects have their updated address.

2. Confirm that mail is flowing in all directions again.

3. Repair any anomalies that are identified.

4. Compose a final status message to the stakeholders and end-users.

5. Finally, mothball the old tenant but only, when necessary, because there is no technical reason that it must be decommissioned directly after the domain move event(s).

What’s Next?

In the next part of this blog series, we will discuss the analysis stage of the migration. In this stage, we focus on identifying and documenting directory objects, application dependencies, hybrid tenants, directory synchronization, business continuity requirements, and risks and limitations.