In my case, I had the $4 per month Exchange Online plan, which does do active directory sycning as opposed to the small business plan, which does not.
In my case, I had 77 mailboxes I wanted to migrate, some as small as 50 MB, a couple that were 6+ GB and about a dozen that were 3+ GB.
The things I'd like to remember for future migrations are:
1) really spend time archiving (either just for this process or overall) to get mailboxes as small as possible. Over time, mailboxes seemed to transfer at a rate of 5 MB per minute - whether I was migrating 3 mailboxes at a time or 10 at a time, so this seemed to be the max upload rate over time (over my 10 Mbps symmetrical circuit).
2) Migrate as many possible mailboxes at a time as the math allows. In the migration process, Microsoft recommends only doing 3 mailboxes simultaneously. I don't know where that number (3) comes from. The process tells you the speed of you upload as you do it, which seemed to average 5 MB/min per mailbox for me. So I'd recommend figuring out the maximum amount of bandwidth you'd like to use for the process. Let's say you have 4 Mbps for this process (or 4000 Kbps). Take that number in Kbps and divide by 666. That's how many mailboxes the bandwidth will allow. So in this case, you could do 6 mailboxes simultaneously.
3) When you start a batch, all the users in that batch start forwarding to the Office365 mailbox even though their actual migration has started. Let's say there are 30 users in your batch and you migrate 8 users concurrently. If your first 8 users are migrating, those last 22 will already be set to forward their mail to Office365. Just something to keep in mind.
2) Migrate as many possible mailboxes at a time as the math allows. In the migration process, Microsoft recommends only doing 3 mailboxes simultaneously. I don't know where that number (3) comes from. The process tells you the speed of you upload as you do it, which seemed to average 5 MB/min per mailbox for me. So I'd recommend figuring out the maximum amount of bandwidth you'd like to use for the process. Let's say you have 4 Mbps for this process (or 4000 Kbps). Take that number in Kbps and divide by 666. That's how many mailboxes the bandwidth will allow. So in this case, you could do 6 mailboxes simultaneously.
3) When you start a batch, all the users in that batch start forwarding to the Office365 mailbox even though their actual migration has started. Let's say there are 30 users in your batch and you migrate 8 users concurrently. If your first 8 users are migrating, those last 22 will already be set to forward their mail to Office365. Just something to keep in mind.
4) use as few batches as possible. I had told my users that "you'll be migrated from approximately 3 pm to 6 pm" and then put users in appropriate batches. While it looked nice to the user to give them exact timelines, making many batches is not efficient because only one batch at a time can run. Let's say you've got a batch with 10 users and 9 users with 1 GB mailboxes and 1 user with a 6 GB mailbox, that last mailbox will hold up the entire batch from finishing. Making the batches as large as possible allows for the process to be as dynamic as possible.
5) Don't run the PowerShell scrips to convert on-premise mailboxes to mail user objects until the migration process is complete for the mailbox. In step 5 of the above article, you can run some PowerShell scripts that will enable autodiscover to reroute to Office365 for migrated mailboxes even though your main autodiscover still points to your on-premise mailbox. This allows you to migrate a subset of your users (where autodiscover points to on-premise for some and Office365 for others). In my case, I told my staff that I'd be done Sunday at 6 pm. I had 8 users who were still mid-migration Sunday at 6 pm. I ran the PowerShell scripts on those users under the assumption that the migration process would continue afterwards. This is not true. The on-premise users no longer have a mailbox so the migration process will break. I'm going to open up the users's old OST file, export to PST and then import to their new mailbox and not import duplicates in order to fix that since only a subset of data was uploaded.
6) Check email addresses after migration. Some of my users were sending out email as USERNAME@DOMAIN.onmicrosoft.com after the migration. For some reason, 3/4 of my users had the correct email address set for them in my on-premise AD in the mail user objects, but the other 1/4 had a default reply address that included onmicrosoft.com. This should be checked by going to Recipient Configuration -> Mail Contact in the on-premise mail server. I didn't see where to set this globally, so I fixed this manually for my misconfigured users.
7) Public folders don't exist on Office365. Assuming you have shared calendars or contact lists, you can create users that will serve that function.
8) Be prepared for the saturation of your connection when downloading all data for the first time. The first day after the upload (after a weekend upload), I started configuring user Outlooks as they arrived. My 10 Mbps downstream bandwidth weas fully utilized all day which led to awful behavior. The larger OSTs never fully downloaded all their data by day's end and inboxes were updating very slowly. I got many complaints of "I haven't received an email in over an hour" since the Outlook was downloading data and not updating the inbox. I had users use webmail on day 1. Overall, for my network, I had users leave their computers on with Outlook open overnight and overall my connection was completely saturated from 8:30 am to midnight (15.5 hours).
8) Be prepared for the saturation of your connection when downloading all data for the first time. The first day after the upload (after a weekend upload), I started configuring user Outlooks as they arrived. My 10 Mbps downstream bandwidth weas fully utilized all day which led to awful behavior. The larger OSTs never fully downloaded all their data by day's end and inboxes were updating very slowly. I got many complaints of "I haven't received an email in over an hour" since the Outlook was downloading data and not updating the inbox. I had users use webmail on day 1. Overall, for my network, I had users leave their computers on with Outlook open overnight and overall my connection was completely saturated from 8:30 am to midnight (15.5 hours).
