As an organization we perform a variety of email migration types. Often times, even lately, we have seen quite a few Lotus Notes and GroupWise customers getting ready to migrate to Exchange Online (BPOS and Office 365.) These organizations vary from hundreds to thousands to tens of thousands. When planning an Exchange Online migration, most customers try to avoid or minimize any sort of coexistence period. This means we have to plan for a large number of users (email objects) to migrate over a single weekend.
Many of the migration tools for Lotus Notes and GroupWise leverage the Outlook client/ MAPI to perform migrations to Exchange Online. A great example of this is the Quest migrations tools (NME and GME.) In order to use MAPI, you have to dedicate an Exchange Online account that has receive-as permissions for all accounts provisioned/ being migrated.
When building a migration plan, most migration plans will include a deployment of multiple migration consoles to support a mass migration. The number of migration consoles is typically determined by many factors. Those include bandwidth to the internet, number of source messaging servers (and their health), and the amount and type of data to be migrated over that weekend. We’ve deployed anywhere from one to forty migration consoles to execute varying types of migrations.
Each migration console requires an Exchange Online account to be assigned to it, as mentioned above. These migration consoles are able to achieve multiple migration threads (also known as MAPI sessions). Exchange has a limit set on how many sessions a single user can have open, which is 32. (Sessions can be compared to having Outlook open and then having multiple user mailboxes attached to it… this will create additional MAPI sessions. If you open enough mailboxes, within your mailbox, you’ll eventually hit this limit.) This limit causes a problem with migration consoles. The problem is, if you have five migration consoles and try to run 10 migration threads each, that’s technically 50 MAPI sessions. If you only assigned one Exchange Online migration account to all of these consoles, you will see many of these migration threads fail (if you run all of these at the same time.) To avoid this, we will typically assign one Exchange Online migration account to every two consoles. This guarantees that a limit won’t be hit for that migration account, that is, if the account is not opened anywhere else (like an Outlook session.)
