With a migration of over 5000 mailboxes, there are plenty of lessons to be learned. I am going to list out the 10 that I figured I would share with all those who perhaps shared the lessons or are planning a migration themselves.

Moving Mailboxes between Migration Batches for simpler Exchange to Office 365 Moves. Create a migration batch with the users you wish to migrate. Start the migration batch, but don’t allow it to complete automatically. Allow the batch to synchronize in advance of the migration date. DELETE Command: Deleting a migrated data set from a migration volume. The DELETE command deletes a migrated data set without recalling the data set. When you specify the DELETE command, DFSMShsm deletes the MCDS data set record and the migrated data set. DFSMShsm does not delete backup versions of the data set.

Using a Hybrid environment that consisted of Exchange 2010 setup in Hybrid mode with Exchange Online. The 5000+ mailboxes data was about 7TB worth of mail data and plenty of hurdles and learning experiences.

These are not listed in any particular order:

1. Clean Up Your Environment with IDFix

We used Dirsync to get all of our user accounts out to Azure AD. In combination with ADFS our users were able to log in and access their Office365 apps using their familiar Active Directory username and passwords after a switch of their UPN. IDFix scans your AD environment and allows you to fix duplicate alias, invalid characters, non-routable addresses, and more. We had tons and tons of issues that we had to correct and it lead me to think, why would AD or Exchange allow you to do things that cause pain down the road?

2. Shared Mailboxes

It may not be as easy as just migrating a shared mailbox. What we found about our environment was that there were a lot more 'shared' mailboxes among teams that were not part of the same teams. For example TeamA had access to a mailbox called Testers. Well once you moved users from Exchange OnPrem to Exchange Online you had to move their shared mailboxes as well. As we prepared to move those users and that shared mailboxes we found out that there were members of TeamB that required access to that Testers mailbox so we had to move them. So now we had to find out what additional shared mailboxes TeamB had access to while also identifying if there was anybody else with access to their shared mailboxes. Just think a spider web of intertwined mailboxes in users or even a bowl of spaghetti. My recommendation? Plan for this by using a command to identify what shared mailboxes a user has access to.

Get-Mailbox -resultsize unlimited Get-MailboxPermission -user 'user' fl identity

*replace 'user' with the identity of the user you want to find what mailboxes they have access to

Of course you can get a list of users and put them in a csv file and create yourself a powershell script to automate this a bit more but that is for another post.

3. Cached Mode Works Better Especially for 2008R2 RDS

We have a wide user base that uses 2008R2 RDS for access to desktops and applications. With our Exchange 2010 on-prem environment 'Online' mode worked best. This was not the case with moving users to Exchange Online. We found that users in that 2008R2 RDS environment using Outlook 2013 in 'Online' mode experienced 'lockups' or 'frozen screens' quite often. We ended up putting some users in cached mode to test performance in those environments and wouldn't you know it, even though it wasn't the recommended way to go it worked out best. One issue we encountered with placing them in cached mode was the search feature was a bit shaky. Returning older results before newer search results or even at times taking 5-10 minutes to display results. To fix that on the 2008R2 RDS environments we installed the Windows Search Service. Since then the overall performance has been much better.

4. You Can Move Mailboxes While Users Are Working

Depending on the use of shared mailboxes (as mentioned earlier a user must be located in the same Exchange environment as the shared mailboxes), you may be able to move users while they are working during the day. When choosing 'Remote Move' the user will get a message that the Exchange administrator has made a change and to close and reopen Outlook. Be careful though if they are in cached mode the mailbox will re-download to the computer. Software cambium. Choose wisely

5. Automatic vs Manual Completion of the Migration Batch

When choosing to move mailboxes during business hours you may have to choose between manually completing the migration batch and automatically doing it. Manually completing the migration batch obviously requires some manual intervention on your part. You get an email notification that the batch has finished the initial sync. Then you just log in and click 'Complete this migration batch' and only deltas are synced. What is so good about this? Well if you don't want to interrupt users at all during the business day you can sync their mailboxes and then just complete the migration at a time you choose. Automatic completion does the initial sync plus the delta sync and completes as it states 'Automatically', without your intervention.

6. You Have 30 days...

Once migrated to Exchange Online the mailbox has 30 days of use if no Office license is assigned to the user mailbox. After that the mailbox goes into a soft deleted state and the user will not be able to access their mailbox. Don't worry though as once the mailbox is in the soft deleted state you have 30 more days until it disappears. Once you assign that license even in the soft deleted state the mailbox reattaches to the account. I wouldn't wait that long. Build a custom view in your portal.office.com to see which users have mailboxes but no exchange license assigned to them.

7. Shared Mailboxes do not have an Office 365 or Exchange License Assigned.

When using OWA is required or the preferred choice you have 2 ways of opening a shared mailbox.

Option 1 - Open the Shared Mailbox in a new Window

• First you log into Outlook.office365.com as yourself and when the mailbox loads click in the top right hand corner (where your picture goes if you choose to have it there) and select open another mailbox.
• Type in the mailbox name and click ok.
• As long as you have full access permission a new browser window will open with the shared mailbox

Option 2 - Open the Shared Mailbox as a Subfolder of your Mailbox

• First you log into Outlook.office365.com as yourself and click the 'More' link
• Right click on your name and select Add Shared Folder
• As long as you have full access permission a sub folder will appear in your mailbox which will allow you to view and manage both mailboxes from 1 browser window

9. Using CSVs for your Migration

When building your migration batch through the EAC you can choose mailboxes 1 by 1 or choose to import a csv. For 1 off mailboxes selecting just the mailbox is easy but when you have multiple buildings a csv may be more efficient. Simply open notepad or notepadd++, enter the word 'emailaddress' and then simply list all the primary smtp addresses of all the mailboxes you want to move and save it as csv file. Point your migration batch to import that csv and continue on with your migration batch process.

10. Prepare for Long Hours, Stress, and all the Rest

I am not even through my entire migration and I could probably write a book on the experience. The entire migration process requires lots of planning especially trying to avoid user downtime or any interruption during their business day. Don't be over confident, plan, plan, & plan and when you’re done plan some more. If email is a user’s lifeline like it is for the majority of the company I work for understand the stress a user will have when they encounter issues with their mailbox pre-migration, during migration, & post-migration. I listed 10 items here but there are way more. Make use of powershell, technet articles, friends in the industry, and anything else that can help you make the migration as smooth as possible.

Hopefully you found this post helpful or at least found that somebody shared the pains you have. My next post will cover using the Microsoft Message Analyzer to help identify email delays, reasons messages are sent to quarantined, and more. Stay tuned!

What I have is a migration batch, that has been stopped after it did the transfer of user mailboxes to office 365 from our on premises exchange. This was a cutover migration, users are using the office 365 now for two weeks.

The batch was running for 5 daysand it did a few incremental syncs, and then it was stopped.Now the question which I have is if I can delete this migration batch (which is currently in a stopped state) without it affecting current mailboxes users are using now for two weeks already. I am afraid it will delete the batch and the mailboxes with itas if I click on the delete (trash can) button, is telling me, that it will take a very long time.

Hi SamuraiS,It's OK to delete the migration batch if you have confirmed the following key points:1. You have already pointed the MX record to Office 365.2. Users are using the Office 365 mailboxes and can receive emails directly in Office 365.3. All emails that were sent to the on-premises mailboxes before the MX record is changed have been synced to the Office 365 mailboxes.Deleting the migration batch won't remove the current mailboxes and emails in Office 365. Depending on the number of the users, it may take some time for the batch to be deleted. It's an expected behavior and won't affect the Office 365 services.Thanks,Henry.