%3CLINGO-SUB%20id%3D%22lingo-sub-1692465%22%20slang%3D%22en-US%22%3ECross-tenant%20mailbox%20migration%20in%20now%20in%20Public%20Preview%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1692465%22%20slang%3D%22en-US%22%3E%3CP%3EHistorically%2C%20when%20an%20Exchange%20Online%20admin%20needed%20to%20move%20mailboxes%20from%20one%20tenant%20to%20another%2C%20the%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fexchange%2Fmailbox-migration%2Fmigrate-mailboxes-across-tenants%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Etypical%20way%20to%20do%20that%3C%2FA%3E%20was%20to%20offboard%20the%20mailbox%20from%20the%20source%20tenant%20and%20import%20it%20into%20a%20target%20tenant.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EToday%2C%20we%20are%20thrilled%20to%20announce%20the%20Public%20Preview%20of%20a%20built-in%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fenterprise%2Fcross-tenant-mailbox-migration%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ecross-tenant%20mailbox%20migration%3C%2FA%3E%20service%20that%20enables%20you%20to%20move%20mailboxes%20between%20tenants%20with%20minimal%20on-premises%20infrastructure%20dependencies%20(the%20new%20service%20eliminates%20some%20but%20not%20all%20on-premises%20components).%20The%20new%20cross-tenant%20mailbox%20migration%20service%20eliminates%20the%20need%20to%20offboard%20and%20onboard%20mailboxes%2C%20resulting%20in%20a%20faster%20and%20lower-cost%20migration.%20This%20is%20particularly%20beneficial%20for%20organizations%20undergoing%20mergers%2C%20acquisitions%2C%20divestitures%2C%20or%20splits.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20new%20move%20process%20includes%20enhanced%20security%2C%20as%20well%20as%20the%20ability%20to%20scope%20moves.%20It%20uses%20an%20Enterprise%20Application%20in%20Azure%20Active%20Directory%20(Azure%20AD)%20and%20Azure%20Key%20Vault%2C%20allowing%20tenant%20admins%20to%20manage%20both%20authorization%20and%20the%20scoping%20of%20mailbox%20migrations%20from%20one%20tenant%20to%20another.%20Cross-tenant%20mailbox%20migrations%20use%20an%20invitation%20and%20consent%20model%20to%20establish%20the%20Azure%20AD%20Enterprise%20Application%20used%20for%20authentication%20between%20tenants.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId--1264945323%22%20id%3D%22toc-hId--1244656659%22%3EPrerequisites%3C%2FH2%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fkey-vault%2Fbasic-concepts%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EAzure%20Key%20Vault%3C%2FA%3E%20is%20used%20to%20securely%20store%20and%20access%20the%20certificate%2Fsecret%20used%20to%20authorize%20and%20authenticate%20mailbox%20migration.%20For%20this%20reason%2C%20an%20Azure%20Key%20Vault%20subscription%20is%20required%20on%20the%20target%20tenant%20to%20perform%20cross-tenant%20mailbox%20migrations.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EFor%20the%20Public%20Preview%2C%20it%20is%20a%20recommended%20best%20practice%20to%20run%20the%20Microsoft-provided%20scripts%20with%20Global%20admin%20permissions%20to%20configure%20the%20Azure%20Key%20Vault%20storage%20and%20certificate%2C%20the%20move%20mailbox%20app%2C%20the%20migration%20endpoint%2C%20and%20the%20organization%20relationship.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIn%20the%20source%20tenant%2C%20a%20mail-enabled%20security%20group%20is%20required%20prior%20to%20running%20setup.%20This%20group%20is%20used%20to%20scope%20the%20list%20of%20mailboxes%20that%20can%20move%20from%20the%20source%20tenant%20to%20the%20target%20tenant%2C%20which%20helps%20prevent%20unintended%20users%20from%20being%20moved.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20will%20also%20need%20the%20Tenant%20IDs%20for%20the%20source%20and%20target%20tenants%2C%20which%20you%20can%20find%20using%20these%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fonedrive%2Ffind-your-office-365-tenant-id%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Einstructions%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CH2%20id%3D%22toc-hId-1222567510%22%20id%3D%22toc-hId-1242856174%22%3EMoving%20mailboxes%3C%2FH2%3E%0A%3CP%3EAfter%20setting%20up%20the%20necessary%20prerequisites%2C%20including%20tenant%20relationships%20and%20configuration%20settings%2C%20admins%20with%20the%20Move%20Mailbox%20management%20role%20can%20use%20the%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fpowershell%2Fmodule%2Fexchange%2Fnew-migrationbatch%3Fview%3Dexchange-ps%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3ENew-MigrationBatch%3C%2FA%3E%20cmdlet%20to%20move%20mailboxes%20between%20tenants.%20The%20move%20process%20performs%20the%20necessary%20tenant%20authorization%20checks%2C%20and%20in%20all%20cases%2C%20the%20admin%20of%20the%20target%20tenant%20initiates%20the%20move%20(which%20we%20refer%20to%20as%20a%20pull%20move)%2C%20just%20like%20the%20on-premises%20to%20cloud%20migrations.%20Currently%2C%20all%20moves%20are%20triggered%20using%20PowerShell%2C%20but%20support%20for%20the%20Exchange%20admin%20center%20is%20coming%20soon.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EBe%20sure%20to%20read%20this%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fenterprise%2Fcross-tenant-mailbox-migration%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Earticle%3C%2FA%3E%20(documentation%20available%20soon)%2C%20which%20covers%20the%20necessary%20prerequisites%2C%20walks%20you%20through%20the%20steps%20needed%20to%20use%20perform%20cross-tenant%20mailbox%20migrations%2C%20and%20it%20details%20about%20the%20Microsoft-provided%20scripts%20on%20%3CA%20href%3D%22https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fcross-tenant%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3EGitHub%3C%2FA%3E.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWe%E2%80%99re%20excited%20to%20have%20you%20try%20out%20this%20new%20feature%2C%20and%20we%E2%80%99d%20love%20to%20hear%20your%20feedback.%20Let%20us%20know%20what%20you%20think!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-1692465%22%20slang%3D%22en-US%22%3E%3CP%3EToday%2C%20we%20are%20thrilled%20to%20announce%20the%20Public%20Preview%20of%20a%20built-in%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fenterprise%2Fcross-tenant-mailbox-migration%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ecross-tenant%20mailbox%20migration%3C%2FA%3E%20service%20that%20enables%20you%20to%20move%20mailboxes%20between%20tenants%20with%20minimal%20on-premises%20infrastructure%20dependencies.%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1692465%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExchange%20Online%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EMailbox%20Migration%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EMulti-tenant%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1700879%22%20slang%3D%22en-US%22%3ERe%3A%20Cross-tenant%20mailbox%20migration%20in%20now%20in%20Public%20Preview%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1700879%22%20slang%3D%22en-US%22%3E%3CP%3EGreat%20Work.%20Thank%20you%20Microsoft%20Exchange%20Team.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1700715%22%20slang%3D%22en-US%22%3ERe%3A%20Cross-tenant%20mailbox%20migration%20in%20now%20in%20Public%20Preview%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1700715%22%20slang%3D%22en-US%22%3E%3CP%3EWill%20this%20update%20the%20x500%20addresses%20as%20well%2C%20so%20people%20will%20be%20able%20to%20reply%20to%20internal%20emails%20like%20they%20expect%20to%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1700547%22%20slang%3D%22en-US%22%3ERe%3A%20Cross-tenant%20mailbox%20migration%20in%20now%20in%20Public%20Preview%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1700547%22%20slang%3D%22en-US%22%3E%3CP%3EMailbox%20guid%20changes%20so%20the%20profile%20won't%20reconnect.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1700190%22%20slang%3D%22en-US%22%3ERe%3A%20Cross-tenant%20mailbox%20migration%20in%20now%20in%20Public%20Preview%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1700190%22%20slang%3D%22en-US%22%3E%3CP%3ENice%20work!%20Can%20you%20please%20clarify%20why%20Outlook%20profile%20needs%20to%20be%20reconfigured%20once%20mailbox%20has%20been%20migrated%20to%20new%20tenant%3F%20Autodiscover%20process%20cannot%20use%20targetaddress%20to%20find%20the%20moved%20mailbox%20like%20for%20%C3%A0%20traditional%20hybrid%20scenario%20%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Microsoft

Historically, when an Exchange Online admin needed to move mailboxes from one tenant to another, the typical way to do that was to offboard the mailbox from the source tenant and import it into a target tenant.

 

Today, we are thrilled to announce the Public Preview of a built-in cross-tenant mailbox migration service that enables you to move mailboxes between tenants with minimal on-premises infrastructure dependencies (the new service eliminates some but not all on-premises components). The new cross-tenant mailbox migration service eliminates the need to offboard and onboard mailboxes, resulting in a faster and lower-cost migration. This is particularly beneficial for organizations undergoing mergers, acquisitions, divestitures, or splits.

 

The new move process includes enhanced security, as well as the ability to scope moves. It uses an Enterprise Application in Azure Active Directory (Azure AD) and Azure Key Vault, allowing tenant admins to manage both authorization and the scoping of mailbox migrations from one tenant to another. Cross-tenant mailbox migrations use an invitation and consent model to establish the Azure AD Enterprise Application used for authentication between tenants.

 

Prerequisites

Azure Key Vault is used to securely store and access the certificate/secret used to authorize and authenticate mailbox migration. For this reason, an Azure Key Vault subscription is required on the target tenant to perform cross-tenant mailbox migrations.

 

For the Public Preview, it is a recommended best practice to run the Microsoft-provided scripts with Global admin permissions to configure the Azure Key Vault storage and certificate, the move mailbox app, the migration endpoint, and the organization relationship.

 

In the source tenant, a mail-enabled security group is required prior to running setup. This group is used to scope the list of mailboxes that can move from the source tenant to the target tenant, which helps prevent unintended users from being moved.

 

You will also need the Tenant IDs for the source and target tenants, which you can find using these instructions.

 

Moving mailboxes

After setting up the necessary prerequisites, including tenant relationships and configuration settings, admins with the Move Mailbox management role can use the New-MigrationBatch cmdlet to move mailboxes between tenants. The move process performs the necessary tenant authorization checks, and in all cases, the admin of the target tenant initiates the move (which we refer to as a pull move), just like the on-premises to cloud migrations. Currently, all moves are triggered using PowerShell, but support for the Exchange admin center is coming soon.

 

Be sure to read this article (documentation available soon), which covers the necessary prerequisites, walks you through the steps needed to use perform cross-tenant mailbox migrations, and it details about the Microsoft-provided scripts on GitHub.

 

We’re excited to have you try out this new feature, and we’d love to hear your feedback. Let us know what you think!

25 Comments
Senior Member

Nice work! Can you please clarify why Outlook profile needs to be reconfigured once mailbox has been migrated to new tenant? Autodiscover process cannot use targetaddress to find the moved mailbox like for à traditional hybrid scenario ?

 

Thanks 

Occasional Visitor

Mailbox guid changes so the profile won't reconnect.

Microsoft

Will this update the x500 addresses as well, so people will be able to reply to internal emails like they expect to?

New Contributor

Great Work. Thank you Microsoft Exchange Team.

Microsoft

Yes, the Outlook profile must be recreated post migration. AutoD will not redirect to the new tenant. This is a scenario we are investigating a solution for in a future release.

Microsoft

The mailbox guid on the target MailUser object pre migration should match that of the Mailbox in the source.

Microsoft

Yes, the X500 proxy is stamped on the source object post migration to support reply.

Frequent Visitor

What I do not see within the documentation: What is the process in keep the primary SMTP Address. A domain can only be registered in one Tenant. How does this work during a tenant to tenant migration where we will have in both tenants mailboxes with the same primary SMTP Address domain?

Visitor

Great !

Question : and all others services like Teams, Sharepoint, OneDrive ?

Frequent Visitor

Great work! This is long expected!

 

I just gave the process a try and failing to migrate the mailboxes. Getting error - "MigrationTransientException: The call to 'https://bn8pr14mb2497.namprd14.prod.outlook.com/mrs/Microsoft.Exchange.MailboxReplicationService.Pro... OAuth' failed. Error details: Access is denied.. --> The call to 'https://bn8pr14mb2497.namprd14.prod.outlook.com/mrs/Microsoft.Exchange.MailboxReplicationService.Pro...' failed. Error details: Access is denied.. --> Access is denied." 

 

Any help would be greatly appreciated!

 

I was able run the source and tenant scripts successfully but had to make a few adjustments in the SetupCrossTenantRelationshipForTargetTenant script as detailed below:

Included AzureRM.Storage in the Import-AzureModules function as Get-AzureRmStorageAccount command failed without it.

Included the command "Enable-OrganizationCustomization" if the (Get-OrganizationConfig).IsDehydrated is True as New-OrganizationRelationship command fails if the tenant is Hydrated.

New-OrganizationRelationship command did not include the -OAuthApplicationId $appId parameter, so added that too.

 

Microsoft

Hi @daysey. Can you make sure the application id values on both the Org Rel and the migration endpoint match and are correct? If they are and you are still receiving this error, go ahead and send the details to our feedback alias:

Frequent Visitor

Hi @Georgia Huggins, yes they match. I'll send you the details now. Thanks!

Microsoft

Hi @Peter Forster Post mailbox migration, the target address on the mailUser object will point to the migrated mailbox in the target tenant. If you need to take the domain from the source tenant and move it to the target, it will have to be removed from the source and given to the target during some sort of cut over window. I would also recommend viewing the Ignite presentation on these features at: https://techcommunity.microsoft.com/t5/video-hub/supporting-mergers-acquisitions-and-divestitures-in....

Microsoft

@Musa_Birkan I recommend watching this Ignite presentation for additional information on the other services: https://techcommunity.microsoft.com/t5/video-hub/supporting-mergers-acquisitions-and-divestitures-in...

Thanks!

Regular Visitor

Great feature get introduce as public preview ,waited for long time. 

Occasional Contributor

I am unable to migrate a test mailbox based on this issue:

 

Error: MigrationPermanentException: One or more X500 proxy addresses or legacyExchangeDN of source mailbox are missing on target MEU as X500 proxy address. --> One or more X500 proxy addresses or legacyExchangeDN of source mailbox are missing on target MEU as X500 proxy address.

 

I have verified that the x500 address (there's only one) has been applied to the MEU object. Removed and reapplied but cannot get past this error which makes me think this may not actually be the issue.

 

Any ideas and what I can do to get past this?

 

Thanks,

 

-Scott

 

UPDATE:

 

Roman (crosstenantmigrationpreview@service.microsoft.com) investigated and pointed out what should have been obvious to me that I had not included ALL x500 addresses from Source tenant object. After adding the other x500 address, not just the LegacyExchangeDN, the mailbox was successfully migrated.

 

Thank you Roman!

Occasional Visitor

@daysey , facing the very same issue. Initially thought it could be because of the various preparation and running the scripts. I redid the whole thing, prepared my batch and after a few minutes same as yours:

 

Error: MigrationTransientException: The call to 'https://gv0p278mb0115.chep278.prod.outlook.com/mrs/Microsoft.Exchange.MailboxReplicationService.ProxyService/OAuth' failed. Error details: Access is denied.. --> The call to 'https://gv0p278mb0115.chep278.prod.outlook.com/mrs/Microsoft.Exchange.MailboxReplicationService.ProxyService/OAuth' failed. Error details: Access is denied.. --> Access is denied.

 

Did you finally manage to go through it?

 

Thanks.

 

J.

Frequent Visitor

@Joa_B, nope, no luck. I continued to get the same error and tried reaching out to support for help with no luck. So recreated everything in a prod tenant and now getting the same error as @Scott Barr 

 

I have a case open with MS and will update if I find a resolution to the issue.

Occasional Contributor

@daysey  Please note the update to my post. Make sure you have the LegacyExchangeDN plus any additional x500 address. Many mailboxes have several x500 addresses in the Source tenant from multiple past migrations and the migration will not work until you match all x500 addresses between the Source and Target.

Also suggest using the crosstenantmigrationpreview@service.microsoft.com address instead of Support as they responded and resolved my issue on the same day.

 

Good luck!

Visitor

@Georgia Huggins 

 

Thanks for this feature, nice to see you guys are working on it.

 

A note though: if the user has to change the PrimarySMTP domain, then it kinds of completely defeat the purpose in most migration scenarios.

 

When we acquired a company, we also acquired its identity and domain. We did a migration O365 > Exchange OnPremises with all the liberties we have OnPremises (so declaring their domain in AD / Exchange), and so were able to do it granularly and keep all the time their email domain (source and onprem target).

 

But here if you tell me they have to change their email (so basically forget their identity), then your tool can realistically only be used for one-shot full tenant migration, or I suppose very rare cases where an acquired company accepts to "lose" its identity.

 

Couldn't you at least find a way to declare the Source Tenant domain in Exchange (e.g. as Internal Relay)? So users would still keep their email address domain (same as you can do OnPremises), and us admins can do granular migrations without caring to have to migrate everything (Teams, OneDrive, etc) one shot.

Senior Member

@daysey 

 

I am facing the same issue. Have you found any solution?

Frequent Visitor

Thanks @Scott Barr, I was able to complete the migration after adding all possible x500 addresses from the source user.

 

@Arjun_Rajan, which of the errors are you referring to? I experienced two different errors using separate tenants. Access denied error using trial tenants and x500 error using prod tenants.

Senior Member

Hi @daysey 

 

Facing the X500 issue, Even I added all X500 email address

Frequent Visitor

Hey @Arjun_Rajan, did you make sure the Exchangeguid is same and legacyexchangeDN also added as an x500 on the MEU? I can send you the script I'm using if you want.

Contributor

Hey @Scott Schnoll

 

I am testing this feature however I keep getting the below error with every migration batch

 

Error: 

Error: MigrationTransientException: The call to https://vi1pr05mb5647.eurprd05.prod.outlook.com/mrs/Microsoft.Exchange.MailboxReplicationService.Pro...' failed.

Error details: Access is denied.. --> The call to 'https://vi1pr05mb5647.eurprd05.prod.outlook.com/mrs/Microsoft.Exchange.MailboxReplicationService.Pro...' failed. Error details:

Access is denied.. --> Access is denied.

 

I have sent an email to 'crosstenantmigrationpreview@service.microsoft.com', hoping you or your team will be able to help me with this.