Office 365 tenant to tenant migrations. Some things you should know about

With cloud adoption going at a fast pace, Office 365 tenant to tenant migrations are scenarios that IT pros have to face more and more often. When a company using Office 365 acquires another company that also uses Office 365, it is obvious that the resources have to be consolidated in a certain way. Being cloud-only organizations, the only choice is a tenant to tenant migration. As this process is pretty painful, I thought to blog about it and point out some things you should know about.

At first, we would have to migrate the users and mailboxes from one tenant to another, including the used mail domain, like My recommendation is to start the verification process of the mail domain in the target tenant and to create the necessary DNS record to prove domain ownership. Sure, we won’t be able to completely verify the domain since it is still present on the source tenant, but by doing this we can make sure that the new DNS record will be appropriately propagated in DNS by the time we have removed it from the source tenant. 

Then we would have to make sure that on the source tenant we remove all smpt addresses that still use the mail domain as suffix and that we change the primary SMTP address to the default domain. To verify that this is done properly you can connect PowerShell to Office 365 and run Get-MsolUser -DomainName If this cmdlet returns any objects, it means that these objects still have attributes linked to the mail domain. We have to make sure that we clear them and we can proceed only when this cmdlet doesn’t return any result.

No some MX considerations and mail flow. This type of migration would cause a certain mail outage. First of all it is important to set the TTL of the MX record to the lowest value accepted by our DNS hosting provider. If for example the lowest value is 2 hours and we want to start the migration itsefl at 6 PM, we would have to make this change at 4PM.

When we change the MX record, we will have a short outage until the domain is verified and configured in the target tenant. However, most e-mail servers on the internet will try to send e-mails for 24 hours if the MX is not present and will deliver the e-mails when the new MX record is present again. These messages are normally queued for delivery and delivered as soon the MX could be resolved. However, there are also mail servers on the internet that won’t queue the e-mail and will deliver a non delivery report (NDR) to the sender.

To avoid this we could use 3rd party MX tools that would queue the incoming messages for us and will deliver them once everything is set up again. These 3rd party tools are pretty efficient and some of them may queue the e-mails for days, weeks or even months.

Another way to resolve this issue would be to point the MX temporarily to another mail provider. Most domain registrars and DNS hosting providers also include and IMAP mail server. So we could point the MX there and create a forwarding rule for each mailbox to redirect the messages to the email addresses that are present on the source tenant.

When the domain is verified in the target tenant and the users are licensed, we can point the MX to this tenant and all mails will be delivered in the new mailbox.

However, now we would have to move the mails from the source mailboxes to the new target mailboxes. I must say, we don’t have a lot of options at this point. The only 2 available options are the use of a 3rd part like MigrationWiz or PST export via Outlook.

I personally tried a lot to perform such a tenant to tenant migration using an IMAP endpoint. However this did not work and always returned me the error “TargetRecipientNotFoundException”. I spent a lot of time with fiddler traces and Netmon traces to find out why this error occurs. My conclusion was that as we are logged in to the Target tenant when we start the migration, when the migration process looks up the source mailbox it recognizes based on the FQDN in the migration endpoint that it is also Office 365 and looks for the source mailbox on the target tenant. Obviously the source mailbox is not present there and therefore we receive the mentioned error. I also tried to see if it is possible to do this via PowerShell, but the same problem occurs.

So the conclusion is that unfortunately we can use only 3rd parties or PST export/import to move mailbox content from source to target in a tenant to tenant migration.

Next step would be to migrate Sharepoint data from one tenant to another, I will have a different blog post on this, since this post became pretty long.

I am looking forward to hear some thoughts from your side and tell me how you managed to perform such migrations.

How useful was this post?

Click on a star to rate it!

Average rating / 5. Vote count:

Dan Patrascu-Baba

Dan Patrascu-Baba

Developer, consultant, trainer at Codewrinkles
,Net Developer.Focusing on both the .Net world and Microsoft Azure. Experienced speaker and trainer.
Dan Patrascu-Baba
Spread the word!

10 thoughts on “Office 365 tenant to tenant migrations. Some things you should know about

  1. Hi Dak,

    Thank you for your reply. I was aware of this article, but still I tried to see if I could do this also via an IMAP migration. As you can see it’s not working.

    Often, when it is “not supported” this does not mean “not possible”. Seems, in this case it really is 🙂

  2. Hi,

    Great article. If I’m only moving 4 mailboxes from, ex: to is it better to just export to pst?



    1. Hello,
      Sorry for not responding earlier. Unfortunately, I lost sight of this blog during last 12 months. Am really sorry for that.
      However, to give a short answer, for 4 mailboxes i would do an IMAP migration or PST export/import.

  3. Very useful article, thanks a lot, it make me stop looking for perfect non-3rd party solution, because our organization is experiencing this problem now, we want to move our one region user from EURO tenant to Asia tenant. -_-!

  4. Very useful. Thanks for this. Did you manage to write the blog for SharePoint as mentioned, if so, could you please share the link. Thanks

  5. Useful article, Is there a way where I can move SharePoint sites (site structure, enterprise metadata, content types, workflows, list & libraries with content) and One Drive data from one tenant to another tenant in 0365?

  6. First of all, sorry for the late reply. I think I don’t have anything to do with SharePoint Online for around 2 years now, but as far as I know there still aren’t any out of the box migration capabilities offered by Microsoft. So for the structure, content, file and so on the best way would be to use some of the 3rd party tools that are out there. For smaller environments, we can also consider a lift and shift approach, and recreate a similar architecture in the new SharePoint organization. Then move the content.

  7. Hi,

    Tenant to tenant in a cloud only scenario is easy with 3rd party tools such as Quest but the GAP here is when you have a hybrid (on-prem AD + AAD connect sync to Cloud) scenario. No tools seem to exist at all! It seems strange as this is the most popular of the scenarios as far as i can tell. Example would be a badly named Tenant (cant rename i know) from which you want to migrate to a new tenant but the identities are mastered from on-prem AD not Azure AD. Any ideas on this? Not so great from MS part to leave things hanging and completely depending on the person naming the tenant correctly without a choice to rename later. Sucks..

    1. Hi Jesse. Thanks for getting in touch.
      First I need to say that this article was written more than 3 years ago and since then I have switched interests and right now I am working as a software developer. So I am surely not 100% up to date with what has changed.

      However, migrating tenant to tenant when you identities are mastered on-premises should not be a very big problem if you don’t have Exchange hybrid. Let’s assume that there no hybrid Exchange. In this case one can very easily synchronize the AD users to the new tenant and that’s it. Mailbox content could be migrated with 3rd party tools, that would also keep source and target mailbox in sync for the duration of the migration.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.