Migrate mailboxes between Office 365 tenants

Our company acquired some smaller companies lately and since most of them are working in Office 365 I am tasked for a smooth integration. With this blog I want to give some basic tips and address things which can be easily overlooked. I am using BitTitan’s MigrationWiz product in order to do tenant to tenant migrations since they have proven to be (one of the) best and easiest tools to move content from A to B. With this blog I basically want to give you a basic understanding in the steps you need to take and the things you have to keep in mind while planning for a mailbox migration between Office 365 tenants.

 

MigrationWiz useful information
1. MigrationWiz copies the mailbox data but will not keep it in sync between source and destination. Communicate to your end users that after you have performed the first migration they don’t move or delete email from their source mailbox. Example; a end user removes 100 emails from their inbox after you did the initial full mailbox migration and 2 days later you are performing a delta sync in MigrationWiz. These emails will not be removed as from the destination mailbox.

2. With MigrationWiz’s mailbox bundle or user migration bundle you receive 10 passes per license which means you are able to perform 10 synchronizations per mailbox. What I usually do is start in a weekend with full migrations and towards migration date I sync every few days to keep the amount of data to be copied over as low as possible. Of course it is best to not keep them in sync for too long.

3. With a BitTitan mailbox license you can not migrate (online) archives as you need to buy a user migration bundle for this (slightly more expensive). The amount of archive data within this user migration bundle is unlimited.

4. Email forwards, calendar responses, client side rules and rules created in a Exchange environment older than 2010 and will not be migrated from source to destination mailbox.

5. Make sure you connect both source and destination mailbox on the .onmicrosoft.com address when adding them to MigrationWiz. Doing this you can still run a delta sync after the domain has been moved from the source to the destination tenant resulting in you able to perform a last delta sync after modifying your MX records.

6. Ask your network team if they expect performance issues as copying mailbox data from A to B means also that users might potentially synchronize hundreds of GB’s or even TB’s to their local Outlook OST files once they show up in the office.


Office 365 useful information

In Office 365 you will at some point disconnect the domain in the source tenant and connect it to the destination tenant. With proper planning this is not that difficult but I want to address some tips here.

1. Be mindful that once you remove email addresses from the source tenant any senders will receive bounce mails saying the email address doesn’t exist even though the MX record stays the same. There are 3rd party solutions which you can use to temporarily point your MX to so that received mails are stored until you are done with the migration. What I usually do is script the removal of email addresses in the source tenant and script the adding of email addresses in the destination tenant and accept the couple of minutes  downtime on a Friday evening. But of course, this is not always acceptable.

2. Make sure that before you are able to remove email addresses you have converted AD synced users (if applicable) to cloud only users. This can be done with the following cmdlet
———————————————————
Set-MsolDirSyncEnabled –EnableDirSync $false
———————————————————
After the users are in the cloud only state you can modify the logins and default email addresses to the onmicrosoft.com ones and kick of the removal of the vanity domain email addresses.

3. You are not able to remove a domain if there is any mailbox, contact or Office 365 group still using an email address of the domain you want to remove. There is an easy way of checking any recipients still using the vanity domain with Powershell.
——————————————————————–
get-recipient -ResultSize unlimited | where {$_.EmailAddresses -match “domain.com”} | fl Name, RecipientType, EmailAddresses
——————————————————————–

4. A script to remove any vanity email addresses (only adjust the domain). Before you are able to run this script you have to make sure that the user logins and default email addresses are not anymore of the domain you want to remove. From the Office portal you can do this by bulk selecting your accounts and click on “domains” and then select the onmicrosoft.com tenant name in order to change the login of your users.
———————————————————————
$Domain = “domain.com”
$RemoveSMTPDomain = “smtp:*@$Domain”
$AllMailboxes = Get-Mailbox | Where-Object {$_.EmailAddresses -clike $RemoveSMTPDomain}
ForEach ($Mailbox in $AllMailboxes)
{
$AllEmailAddress = $Mailbox.EmailAddresses -cnotlike $RemoveSMTPDomain
$RemovedEmailAddress = $Mailbox.EmailAddresses -clike $RemoveDomainsmtp
$MailboxID = $Mailbox.PrimarySmtpAddress
$MailboxID | Set-Mailbox -EmailAddresses $AllEmailAddress #-whatif
Write-Host “The follwoing E-mail address where removed $RemovedEmailAddress from $MailboxID Mailbox “
}
———————————————————————

5. One more tip or more or less an issue I had after moving the tenant is that I was not able to enable back DKIM for the domains from the portal. From Powershell however it worked instantly with the following cmdlet:
———————————————————————
New-DkimSigningConfig –DomainName “domain.com” –Enabled $true
———————————————————————

Share this blog!

Leave a Reply

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