Microsoft 365 Exchange Online Domain Transfers: Analysis Phase

This post is a part of a series that covers the Five Best Practices for Microsoft 365 Exchange Online Domain Transfers. In this article, we will discuss the Analysis phase of an Exchange Online domain move project. Please refer to our previous post for a brief overview of the five best practices for Microsoft 365 Exchange Online Domain Transfers.

Deep Dive of the Analysis Phase 

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.  

Now let’s dig a little deeper and begin to examine the analysis phase of the project with six (6) best practices specific to assessing your source and target tenants.  

It is important to first assess your tenant to understand the full scope of the domain name space footprint within your organization. During this stage, you will identify and document the following key areas: 

• Directory Objects – Always assess the tenant and generate a comprehensive inventory report of all objects spanning impacted directories, including a list of users, service principals, contacts, guests, groups, and teams that utilize the domain as an email or SIP address, proxy address or User Principal Name. Understanding the full scope of the domain footprint in your tenant will be required as Microsoft does not allow the removal of the domain from the tenant if it is in use during the transfer. This inventory report will also be a vital part of any contingency planning if recovery is required.  

• Application Dependencies – Always identify all the dependencies related to third-party applications that utilize the domain being transferred. Domains will have different functional roles for each affected application. For example, you may have a support ticketing system that utilizes the domain to send or receive emails. If any email downtime is unacceptable, then it is considered a business requirement that you ensure the system continues to function during the domain migration. Another very common dependency is automation. IT administrators manage scripts, apps, and service principals to help manage their day-to-day IT operations; however, they will no longer function once the domain is removed from the tenant.  

• Hybrid Tenants– Always plan for hybrid organizations that utilize federated authentication or allow mail to transfer between the on-premises Exchange organization and the cloud. As an example, your on-premises Active Directory (AD) may share the same Fully Qualified Domain Name (FQDN) as your tenant, and it is configured with Active Directory Federation Service (ADFS) and Single Sign On (SSO) for your tenant. Your tenant ADFS configuration needs to be modified post- migration if you still plan to have users sign into your source tenant after the domain is moved. In addition, if the domain is used by service accounts configured for Azure AD Connect (AADC) (which allows objects and attributes to be synchronized to the Azure Active Directory) those services will also stop synchronizing.  

• Directory Synchronization – When changes made to the on-premises AD are not synchronized to Azure Active Directory (AAD), this will prevent the domain from being removed from your source tenant. Fully understand the directory synchronization configuration topology and rules. AADC plays a vital role during your domain move project. It will be used to ensure object changes are fully synchronized between your on-premises AD and AAD after the domain name is removed from your on-premises remote objects.  

• Business Continuity Requirements – Understand your business. Every organization will have different business continuity requirements based on their unique and regulatory requirements. It is paramount to capture input from the key stakeholders within your organization — and often even outside your organization — to both understand their needs and explain to them the known technical limitations and constraints of the project. Generally, all organizations must decide how much, if any, email downtime is acceptable. Other common areas of inquiry shared among all organization types include, but are not limited to: email and calendaring, authentication, hybrid directory integrations, Microsoft Teams meetings, SharePoint sites, and access to most services within Microsoft 365. 

• Risks and Limitations – Always rank risks and limitations that may impact the organization’s core business operations. The following list contains the four (4) known risks and limitations that all Microsoft 365 cross-tenant domain migration projects will encounter.  

1. Email delivery will be delayed while the domain is being moved unless you have an address rewrite solution to manage the flow.  

2. Projects that fail to complete on time will create downtime in normal business operations.  

3. A replacement domain must be added when removing the domain references for both Azure Active Directory and Hybrid Azure Active Directory objects.  Address conflict may occur if a non-dedicated replacement domain is used. As a result, not all domain references can be removed and could prevent the domain from being removed from the tenant.  

4. End-users may need to re-authenticate their desktop applications post-domain move migration.  

What’s Next? 

In the next part of this blog series, we will discuss how to formulate a migration strategy by identifying the requirements for the end-user experience, determining how much email downtime is acceptable to the business, classifying service account dependencies, determining which migration path to take, framing your contingency plans, and finally, finding the point of no return where moving forward is the only path remaining.