Understanding migration tool nuances during Domain moves in Microsoft 365

Domain migrations in Microsoft 365 are rarely as simple as shifting email addresses from one namespace to another.  The doDomain migrations in Microsoft 365 are rarely as simple as moving email addresses from one namespace to another. Before a domain can be reassigned to a target tenant, that domain must be fully removed from every object in the source tenant, including:

• Primary SMTP addresses
• ProxyAddresses
• UserPrincipalNames (UPNs)
• Users
• Distribution Groups
• Security Groups
• Microsoft 365 Groups and Microsoft Teams

Only once the domain is completely detached can it be re‑applied correctly to the corresponding objects in the target tenant.

When migration tools such as AvePoint Fly are involved, particularly for Microsoft Teams and Microsoft 365 Groups, additional nuances and tool limitations can introduce unexpected challenges if they are not fully understood and planned for well in advance.

The core challenge

One of the most common migration issues occurs when the custom (vanity) domain is removed from the source tenant during cutover.

When a domain is detached, any user, team, or group object that used that domain as its primary SMTP address or UPN automatically falls back to the tenant’s default (initial) domain, for example:

@tenantname.onmicrosoft.com

This behaviour is expected, but it can quickly cause naming conflicts.

The default Microsoft tenant name is sometimes referred to as the MOERA (Microsoft Online Email Routing Address) and can also include:

@tenantname.mail.onmicrosoft.com

How naming conflicts arise

Consider a tenant containing two custom domains:

• nzo.com
• nzoit.com

If both domains are removed at cutover, the following users:

• joe.bloggs@nzo.com
• joe.bloggs@nzoit.com

will both attempt to revert to:

joe.bloggs@nzocorp.onmicrosoft.com

Microsoft 365 cannot support two objects with the same default tenant domain address. This creates a conflict that can result in:

• Azure AD synchronisation errors
• Manual remediation requirements
• Migration delays
• Failed or incorrect source‑to‑target object matching

Impact on Microsoft Teams and Microsoft 365 Groups

Microsoft Teams and Microsoft 365 Groups experience similar problems because their underlying SMTP identities also revert to the default tenant domain.

For example, two groups such as:

• support@nzo.com
• support@nzoit.com

may both attempt to become:

support@nzocorp.onmicrosoft.com

Microsoft will automatically resolve these conflicts by assigning one group an alternative address, often based on an existing proxyAddress if one is present. However, this can make it difficult to identify which group is which, especially during migration validation or troubleshooting.

Tool‑specific limitations

Some migration tools have additional constraints around email address handling when domains change mid‑migration. For example, AvePoint Fly (Server and SaaS) allows you to modify only the domain portion of an email address during a migration. The left‑hand portion (alias) cannot be changed.

This limitation exists because licensing is assigned:

• Per object
• Based on the email address
• Not on the immutable objectId (GUID)

Since the left‑hand portion of the email address forms part of the licensing identity, it cannot be changed mid‑migration. If licensing were instead based on the immutable objectId, migrations could support alias changes, dramatically reducing conflicts and giving engineers greater flexibility.

When conflicts occur, Microsoft 365 often appends a random numeric suffix to the alias to maintain uniqueness. If this change is not anticipated or documented, the migration tool may fail to bind the source and target objects correctly.

When this happens:

• The migration run for that Team or Group must be abandoned
• No final delta migration can be performed
• A brand‑new source/target pairing must be created
• The migration must restart from the beginning

However, in scenarios such as cutover, where time is critical and the options described above may be impractical or unacceptable, the only viable approach is to manually correct the source object, complete the migration for the affected object, and then proceed with the next object involved in the same conflict.

How OneDrive is affected

OneDrive for Business URLs change when a user’s UserPrincipalName (UPN) changes, and migration tools rely heavily on these URLs.

A typical OneDrive URL looks like:

https://nzocorp-my.sharepoint.com/personal/john_smith_nzo_com

After a domain fallback, it becomes:

https://nzocorp-my.sharepoint.com/personal/john_smith_nzocorp_onmicrosoft_com

Because domain moves often modify all users at once, these URL changes can disrupt active migrations until mappings are fully refreshed.

How Exchange is affected

Exchange migrations are also impacted because source and target address mappings must be updated everywhere.

Before removing the domain, a mapping may look like:

Migration tools must be updated across:

• Mailbox migration mappings
• Team membership and ownership permissions
• Mailbox delegation
• OneDrive and SharePoint sharing permissions

Additionally, the backend Microsoft SharePoint service needs time to update its source and target endpoint URLs before migrations can resume. This process is not always immediate and can occasionally stall, requiring manual intervention.

How to avoid these issues

To reduce risk and avoid costly delays:

Prepare renaming and conflict‑resolution strategies before cutover
This prevents emergency remediation during critical migration windows.main value in use needs to be first removed from ever primary smtp address, proxyAddress and UserPrincipalName for all users and groups – including Distribution Groups, Security Groups and Microsoft 365 Groups (and Teams), and the re-applied correctly on the corresponding objects in the target tenant. 

Record original UPNs and SMTP addresses
Capture them in detailed migration runbooks, spreadsheets, or custom attributes for reference.

Maintain a master migration mapping list
Track every source‑to‑target change over time to improve planning, validation, and conflict detection.

Plan for default tenant domain fallback
Identify objects that could conflict when reverting to the onmicrosoft.com domain prior to starting pre-staging, and update the left‑hand portion of those objects before starting the migration process. This ensures that, during domain migration, only the domain suffix changes, allowing the migration tools to manage the transition effectively.

Understand tool limitations early
Especially around alias handling, licensing behaviour, and mid‑migration changes.

When Migration Tools such as AvePoint are involved, particularly when migrating Microsoft Teams and Microsoft 365 Groups, the nuances and limitations can introduce unexpected challenges if not completely understood and managed well in advance as they do not handle modifications to the left portion of the SMTP/UPN once the object has already been migrated.

The challenge

One of the most common issues appears when a domain is removed from the source tenant during cutover. Once a domain is detached, any user, team, or group object using that domain as its primary SMTP address or UPN will automatically fall back to the tenant’s default / initial domain address once the vanity domain being migrated is removed. (e.g. @tenantname.onmicrosoft.com). This behaviour is expected, but it can create conflicts quickly. 

The default Microsoft tenant name is sometimes referred to as the MOERA – Microsoft Online Email Routing Address but will also include @tenantname.mail.onmicrosoft.com 

Planning a Tenant-to-Tenant or Domain Migration?

Microsoft 365 domain migrations involve far more than moving SMTP namespaces. Identity conflicts, Teams and Group mappings, SharePoint URL changes, and migration tool limitations can all introduce major risk during cutover.

Nero Blanco has delivered complex Microsoft 365 migrations for enterprise organisations worldwide, helping customers navigate:

• Cross-tenant Microsoft 365 migrations
• Microsoft Teams and SharePoint migrations
• Domain consolidation projects
• Mergers, acquisitions, and divestitures
• Hybrid and cloud identity remediation

If you are planning a migration project and want to reduce risk, avoid costly delays, and ensure a smooth cutover:

Get in touch with our migration specialists today