Running Orchestrated Migration End-to-End: Validation, Sync, Cutover, Monitoring, and Cleanup

-

Orchestrated migration is executed as a migration job (a batch). Microsoft states that the maximum batch size is 100 users and migrations are managed through Microsoft Graph APIs (beta) using PowerShell or Graph Explorer.

Step 1: create a validation batch (recommended)

Use standalone validation to confirm prerequisites before you submit an actual migration. Validation behaves like a what-if: it checks prerequisites at tenant and user levels (permissions, relationships, identity mapping, licensing, and more).

Step 2: submit the migration batch and understand the stages

·       Validation: checks prerequisites; if checks fail, the user's migration does not begin.

·       Mailbox syncing: mailbox content is synced in the background while the user continues working in the source tenant. Microsoft strongly recommends submitting batches two weeks before the cutover date.

·       Cutover: after CompleteAfterDateTime passes and sync completes, mailboxes cut over to the target tenant. After cutover, cancellations are no longer possible.

·       Teams and OneDrive: after mailbox cutover, Teams chats, Teams meetings, and OneDrive sites begin migration.

Batch control and monitoring (Graph beta PowerShell examples)

# Create a validation job
Test-MgBetaCrossTenantMigrationJob -DisplayName "xtmigration1" -CompleteAfterDateTime 2026-02-01T00:00:00Z -ResourceType Users -SourceTenantId <sourceTenantId> -Resources @(<targetUserObjectId1>, <targetUserObjectId2>)

# Create a migration job
New-MgBetaCrossTenantMigrationJob -DisplayName "xtmigration1" -CompleteAfterDateTime 2026-02-01T00:00:00Z -ResourceType Users -SourceTenantId <sourceTenantId> -Resources @(<targetUserObjectId1>, <targetUserObjectId2>)

# Retrieve all jobs (batches)
Get-MgBetaCrossTenantMigrationJob

# Retrieve user status within a job
Get-MgBetaCrossTenantMigrationJobUser -CrossTenantMigrationJobId <jobIdOrName> -CrossTenantMigrationTaskId <targetUserObjectId> | ConvertTo-Json -Depth 100

# Update the cutover date
Update-MgBetaCrossTenantMigrationJob -CrossTenantMigrationJobId <jobIdOrName> -CompleteAfterDateTime 2026-02-08T00:00:00Z

# Cancel a job (only before CompleteAfterDateTime)
Stop-MgBetaCrossTenantMigrationJob -CrossTenantMigrationJobId <jobIdOrName>

Cleanup after migration

After migration completes, remove temporary permissions and return tenants to a non-migration state. Typical cleanup actions include:

·       Remove organization relationships (Remove-OrganizationRelationship).

·       Remove migration endpoints (Remove-MigrationEndpoint).

·       Remove meeting migration permissions (Remove-MMSAppPermissions).

·       Remove identity mapping permissions (Remove-CtimServicePrincipal) and Teams chat migration permissions (Revoke-CTTMAppPermissions).

·       Remove CTIM data (Remove-CtimData) when you have confirmed migration completion and business acceptance.

Note: users remain on the source tenant as MailUsers after migration. Depending on business needs, you can choose to remove or maintain these objects.

Important: avoid outdated guidance

This blog series intentionally avoids using the older Tenant-to-tenant migrations overview page you flagged as outdated. Prefer the Migration Orchestrator and workload-specific cross-tenant migration pages linked above.

Source links (Microsoft Learn)

·       https://learn.microsoft.com/en-us/microsoft-365/enterprise/migration-orchestrator-5-running-migration?view=o365-worldwide

·       https://learn.microsoft.com/en-us/microsoft-365/enterprise/migration-orchestrator-6-post-migration?view=o365-worldwide

·       https://learn.microsoft.com/en-us/graph/api/resources/crosstenant-migration-overview?view=graph-rest-beta

·       https://learn.microsoft.com/en-us/microsoft-365/enterprise/migration-orchestrator-1-overview?view=o365-worldwide

Comments

Post a Comment

Popular posts from this blog

Skype for Business, Lync and Exchange Web Services (EWS) and different DNS Domains- Exchange crawling e.g. for presence

-
Image
Hi all, (This is an updated version 2.2: 09 .07.201 5 ) This blog entry is valid for Lync 2010, Lync 2013 and Skype for Business Server. Generally, I'll write a new blog article, since the conversion history over multiple device and other service have change with Skype for Business 2015 Server. Once this written, I post the link here. there is always confusion in how Lync is crawling Exchange Web Services (EWS). Generally it is necessary to understand how DNS must be implemented: Just remember, identify if you have DNS Split configuration, different internal and external DNS names and what are your SMTP and SIP Domains. Very often you find in Lync/ Exchange deployments an issue, where the Lync configuration show up with empty: EWS Internal URL EWS External URL and EWS Information = EWS not deployed Therefor Exchange Web Service are not connected deployed and several Lync Integration Features are not working, e.g. Presence Information based on your Outlook Calendar....
Read more

How to hide users from GAL if they are AD Connect synchronized

-
Image
How to hide and un-hide users from Global Address List (GAL) in Exchange Online if they are AD Connect synchronized Hiding User from GAL isn't possible if those are synchronized form On-Premises Active Directory. The local AD is the leading system for all important attributes, like SMTP, UPN and hiding from GAL. Especially during a cross-tenant migration, you do not want to see not migrated user in the GAL. Those User aren't actively working until their cut-over day. Since the Exchange Online attribute  msExchHideFromAddressList s is an AD on-premises parameter, we have two possible ways hiding user in BME from GAL.   Modify the AD Connect for your teant with a custom rule, by using a extensionAttribute to set the HidefromGAL. In this rule, for users which have an entry in the extensionAttribute, hiding / un-hiding will be controlled by AD Connect This is the best option for Cross-Tenant Migration, if you run 2 or more AD Connect system We direct modif...
Read more

Exchange x500 address x500:/o=ExchangeLabs

-
Image
 You have Exchange Hybrid in place. Now you wonder about an address with you see on-premises with all users. This address has the following format: x500:/o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOxxxxxx)/cn=Recipients/cn=234xxxx This address is now found in the Exchange proxyAddresses in On-Premises as well as in Entra ID. Additionally you will see them in msExchShadowProxyAddresses The ExchangeLabs is Microsoft internal Exchange Online Organization and therefore needed. This x500 address is created in Exchange Online and sync'ed via Azure AD Connect (Entra ID Connect) back on-premises. If you delete this address on-premises, the connection between will sync this Cloud leading attribute back to on-premisses. If you have multiple Domains and Active Directories connected to your Tenant, this x500 address from your tenant will be added to ALL users. Also to users which are from an local AD without Exchange / Exchange Hybrid. As long AAD Connect/ Entra ID Connect will...
Read more