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 domain.com. 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 .onmicrosoft.com domain. To verify that this is done properly you can connect PowerShell to Office 365 and run Get-MsolUser -DomainName domain.com. 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 domain.onmicrosoft.com 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.

 

Dan Patrascu-Baba

Partner Technical Consultant at Microsoft
Azure PaaS and dev consultant, working for Microsoft. Mostly dealing with Microsoft Azure services, ASP.Net Core, AngularJS, Javascript. Helping partners and customers to write good code and to architect their cloud and hybrid solutions.

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

  1. Dan Patrascu-Baba Post author

    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. Tom Vitucci

    Hi,

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

    Thanks,

    Tom

    1. Dan Patrascu-Baba Post author

      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. I3500j

    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. Priya Nair

    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. soujanya

    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. Dan Patrascu-Baba Post author

    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.

Leave a Reply

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