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.
Latest posts by Dan Patrascu-Baba (see all)
- ADFS in multi forest environments - 20/10/2017
- #Build 2017 – some exciting things - 10/05/2017
- Testing Azure AD per app MFA and conditional access based on network location - 29/07/2016