Microsoft 365 Exchange Online Domain Transfers: Strategy Phase

Phase Two of an Exchange Online Domain Transfer

We are continuing our series on the “Top 5 Best Practices for Exchange Online Domain Transfers.” In this edition, we will continue with a deep dive into one of those best practices: strategizing. This best practice is phase two of a Microsoft 365 domain move project, right after the analysis phase. As with any project, a well-thought-out strategy will help to avoid known pitfalls during the actual migration.

Deep Dive of the Strategy Phase

There are six (6) key decision points that you must make while drafting the technical approach of the Exchange Online Domain migration plan using the information you captured during phase one, analysis.

Desired Experience

Plan what type of end-user experience your business requires before, during, and after the migration. As an administrator, you must answer the following questions before you can determine the proper path for the domain and its impact on accounts.

• Is there a period of coexistence between the two tenants?
• How will the business utilize the domain(s) in the future?
• Will the original tenant be maintained for any period after migration?
• Will the original tenant be decommissioned immediately after migration?
• Will any target objects retain this domain as a primary address?
• Will any target objects retain this domain as a secondary address?
• Will source objects be retained or removed during this process?
• What source domain will replace the remediated source object(s)?

Email Downtime

Plot how email will flow during the period when the Exchange Online domain is removed and transferred. While a domain is being transferred, email cannot be delivered to the source tenant because all addresses have been removed from all objects, and the domain has been removed from the Exchange Online authorized list of accepted domains. It also cannot be easily delivered to the target tenant because the migrated accounts and groups do not possess the appropriate addresses for delivery to occur, and the domain has yet to be validated in the tenant.

IT and business stakeholders must determine if any email downtime is acceptable during the transfer, which could take several hours or days depending on the size and complexity of the organization.

The most common option is to queue all inbound mail during the migration; however, this may be unacceptable to some business stakeholders because it prevents any business transactions or processes from occurring through email at that time. In these cases, there are 3^rd party solutions that will allow mail to flow, even during the transfer, using technologies such as email address rewrite. However, this type of email address rewrite solution does increase the complexity and cost of the project.

Service Account Dependencies

Know how this could impact service accounts. During the Exchange Online Domain analysis phase, you assembled an inventory of Service Accounts using the domain being transferred. Next, administrators must map out the dependencies these service accounts will have on applications and services to determine the business impact and severity. After you have prioritized each service account’s impact on the business, you must decide how to mitigate any potential impact before or during the domain transfer. There are three general paths to follow:

• Modify the service account domain before the domain transfer under controlled conditions with application administrators ready to validate the services after the service account is updated.
• Remediate the service account on the day of the domain transfer. However, this has a higher risk, and the potential of a service or application to be inaccessible for an extended period.
• Retire the application or service. Before the domain transfer, adopt an alternative application or service to replace the existing one. Thus, removing the service account dependency.

Single Event vs. Multiple Events

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.

Let’s start by defining the two event types while providing some general pros and cons of each:

1. Single Event: This is when a single domain is a cutover along with all associated user data and user desktop applications within the same period, typically 24 – 72 hrs. -Pros: Best User Experience -Cons: Higher Risk; Less Change Capacity

• Pros:
  • Best user experience
• Cons:
  • Higher risk; less change capacity

2. Multiple Events: This is when one or more domains are cutover, but all associated user data and user desktop applications were previously cutover in separate events.

• Pros:
  • Fewer Moving Parts
• Cons:
  • Requires mail forwarding solutions
  • May require address rewrite services at an additional cost

How to Size a Big-Bang event?

When determining if a single event or big-bang is right for your situation, there are three key factors to consider:

1. Number of Users – How many users are planned for the migration event?
2. Amount of Data – How much user data remains to be copied during this migration event?
3. Help Desk Capacity – How many tickets can your support organization effectively process in a workday?

If your answer is many users with a large amount of data with little support capacity, then a single event migration may not be right for you. We recommend big-bang migration events be reserved for small to medium tenants (100 – 2,500) that require the existing domain on day one and do not have any coexistence options to allow domain sharing.

Back-up Contingency Plan

Its important to have a rollback or recovery strategy for the Exchange Online domain transfer. Things don’t always go as planned! To ensure business continuity, administrators must:

• Take a full backup of all directories involved
  • Pilot & document the directory recovery process
  • Pilot & document the roll-back steps

In the event the domain transfer must be aborted, a full backup will go a long way to ensure the business is operational sooner and they don’t suffer any ill effects due to unforeseen circumstances.

Point of No Return

Agree to when is the “point of no return” for a potential rollback. The “point of no return” is when the roll-back process is no longer achievable within the time remaining.  An example of this point of no return will be when the domain has already been removed from the source tenant and added to the target tenant. A rollback migration at this point will not be possible as domain references have already been updated in both source and target Azure tenants.  

Moving Forward

These six (6) key decision points are important questions an organization must ask themselves and also take into consideration as part of their overall Domain Migration strategy.  After completing the strategy phase of the project, in the next part of the series, we’ll continue to explore this topic by unraveling the next phases of the project, piloting, the go/no-go day, and post-migration clean-up opportunities.