The Exchange 2016 migration project for Not Real University has reached the stage where they can begin their mailbox migration.

When planning a mailbox migration it’s useful to review how much data each mailbox actually stores. This is important to know so that you can plan your migration batch sizes in way that won’t overwhelm the destination server with too much transaction log generation from all of the database changes that will be occurring during the moves. You can use the Get-MailboxReport.ps1 script to generate mailbox size reports for your environment.

You can move mailboxes using either:

• Individual move requests
• Multiple move requests tagged with the same batch name
• A migration batch of one or more mailboxes (which is not the same as tagging a bunch of move requests with a batch name)

If you perform the migrations using the Exchange Admin Center, you’ll be creating migration batches. If you choose to use the Exchange Management Shell instead, you can use any approach you like. The process for moving mailboxes has not changed between Exchange 2013 and 2016, so you can refer to this tutorial on moving Exchange Server mailboxes for more details.

Note that after completing a migration batch there are some factors that might cause a delay before the users can access their mailbox:

• Active Directory replication delays
• Autodiscover caching

Any Active Directory delays will need to be accounted for in your migration timing, and should be revealed during the first few migration batches you run. For the Autodiscover caching, you can recycle the Autodiscover app pool in IIS on all Exchange servers, or lower the automatic recycle interval during your migrations. In both cases, if you’re completing migration batches overnight when there are several hours before users will be logging back on, then it’s unlikely you’ll run into either problem.

When the mailboxes have been migrated to Exchange 2016, the public folder migration can be performed.