Tenant-to-Tenant Migration with Orchestrator – Technical Overview (Microsoft 365 | Preview)
Tenant-to-tenant migration with Orchestrator in Microsoft 365 introduces a native, API-driven, and highly validated approach for cross-tenant migrations. It is designed for enterprise scenarios where sequencing, dependencies, and governance are critical. Note: This capability is currently in preview. Features and behavior may change before GA. Architecture and execution model Migration is executed through batches (jobs) managed via Microsoft Graph (Beta) User-level execution: one user failing validation does not block others in the same batch Mandatory Standalone Validation before migration submission Date-driven cutover using completeAfterDateTime Supported workloads (actual scope) Exchange Online Microsoft Teams ODSP (OneDrive for Business) Important clarification on SharePoint Orchestrator does not migrate shared SharePoint content such as Team sites, Channel sites, or collaboration sites. The ODSP workload covers personal user data (OneDrive) only. SharePoint team/workload sites remain out of scope and require separate tooling or processes. Critical prerequisites Identity Mapping (CTIM) is mandatory and must remain stable during migration Target users must not have Exchange mailboxes or OneDrive sites provisioned before migration Licenses must be assigned only after Identity Mapping (ExchangeGuid stamping) Migration apps and service principals (Teams, Meetings, CTMS) must be correctly provisioned Organization Relationships and Migration Endpoints must be in place Exchange autoforwarding must be enabled for Meetings migration Validation and lifecycle Standalone Validation acts as a full “what-if” check Key states include: Cancellation or user removal is possible only before cutover Post-migration cleanup After completion, tenants must be returned to a non-migration state: Remove Identity Mapping data Remove Organization Relationships Remove Migration Endpoints Revoke migration app permissions and service principals Decide whether to retain or remove MailUsers in the source tenant Skipping cleanup leaves the tenant in an exception state. When this approach fits Mergers and acquisitions Divestitures and tenant splits Regulated environments requiring strict control Scenarios where dependency-aware sequencing matters more than speed Technical conclusion Orchestrator is not a one-click solution. It delivers native orchestration, deep validation, and predictable execution when Identity Mapping, licensing order, and scope boundaries are fully understood. For experienced administrators and architects, it represents a major step forward in tenant-to-tenant migrations within Microsoft 365, even while still in preview.
Exchange Decommissioning Set-Remotemailbox command
Hi all, I have a situation where someone was with a hybrid Exchange Server configuration was using scripts to provision accounts with Set-RemoteMailbox. Testing was being done with the recipient management using the exchange management and noticed mailboxes are being provisioned and working as expected without even running their set-remotemailbox commands and are curious if this is even needed anymore. So I guess my question is, at this stage where .\CleanupActiveDirectoryEMT.ps1 is the last thing to do, would set-remotemailbox still be necessary, and what would it be used for. I know usually you can just create an on-prem mailbox, synced and license, so I'm not sure if set-remotemailbox is required for new mailboxes or but I'm thinking it's for managing mailboxes that were previously migrated. Thanks for any input.
Exchange Mailbox Export Import PST Migration
Hello All, Below is the Customer's messaging environment: Company-A is already running with on-prem Exchange 2016 with hybrid configurations. Company-B is running with purely on-prem Exchange 2016. Now Company-B is acquired by Company-A. Current status of Company-A Hybrid Configuration: Company-B domain verified and added as accepted domain in Company-A O365 portal. Also Mail flow for Company-A and Company-B MX records pointed to ProofPoint Gateway for all the inbound and outbound mail flow. Company-B will be going to decommission post movement of all the on-prem mailboxes to Company-A O365 EXO. Hence we selected to migration type is Mailbox export to PST, upload PST into Azure Blob storage container, Mapping the PST file and Import PST into O365 mailbox. All the AD accounts will be create in Company-A local AD and sync to Azure AD via AD connect. Current Stage and Future stage: Current SMTP address in Company-B: mailto:email address removed for privacy reasons as primary address Post migrating to Company-A domain: mailto:email address removed for privacy reasons as primary address and mailto:email address removed for privacy reasons as secondary address. We will be going to create a contact for Company-A and will keep it on Company-A mailbox, so that Company-A emails forwarded to Company-B mailbox. We will be going to keep the on-prem mailbox as it is but we will block the Exchange protocols for migrated mailbox. In this scenario we will be having Domain-A and DOmain-B email addresses as mailto:email address removed for privacy reasons as primary address and mailto:email address removed for privacy reasons as secondary address-Post migrating to Company-A O365 EXO. Additionally we will be having on-prem mailbox as mailto:email address removed for privacy reasons as primary address This will be applicable for all the mailboxes, resource mailboxes, Distribution Groups as well. MY CONCERN: When someone from the internet sends email to mailto:email address removed for privacy reasons does it sends directly to Company-B on-prem Exchange or does it send that email directly to O365 mailbox. Any help really appreciated. Anand Sunka
