Migrator for Notes to Exchange can migrate to hosted Exchange services, typically to Microsoft Office 365 Exchange Online. Migration to Office 365 is similar to on-premises migrations, but there are key differences so the processes are described separately in this Scenarios Guide (chapters 2 and 3).
The account permissions required for migration to Office 365 are different from those required when migrating to proprietary Exchange since the hosted services are shared resources controlled by an external entity (Microsoft). Access to either target type is set at the mailbox level through Remote PowerShell, as described in the Migrator for Notes to Exchange Quick-Start Guide and Pre-Migration Planning Guide (see the System Requirements section in either book).
Office 365 introduced throttling on user connections which impacts migration performance. The throttling is a per-user limitation that reduces throughput after more than two connections by a single user (including the <MigrationAdmin> user). With previous versions of Exchange Online, migration throughputs of 3-5GB/hr per machine were common. But the Office 365 throttling reduces typical throughput to 500MB/hr or less per machine.
Quest recommends that you use multiple migration machines (or virtual machines) running in parallel to achieve the desired throughput when migrating to Office 365. Use a separate unique <MigrationAdmin> account for each machine, to bypass the Office 365 throttling. Also, each migration machine should be configured with fewer threads (2–4) to optimize throughput.
Quest is working directly with Microsoft to test modifications to Office 365 throttling policies and their impact on migration throughput. It may soon be possible to modify the throttling policies to improve migration throughput. However, multiple migration machines with unique migration accounts may still be desirable and/or necessary for more efficient migration to Office 365.
Since Microsoft throttling is applied per administrator account, Migrator for Notes to Exchange runs multiple administrator accounts simultaneously on separate machines, each set to migrate with only one thread at a time. The net throughput becomes a function of the sum of all these multiple accounts’ processing threads—one per administrator account.
MNE includes an Admin Account Pool utility that helps you manage a pool of Office 365 administrator accounts and to coordinate these administrator accounts. For information, see the “Office 365 Admin Account Pool utility” chapter in the NME Administration Guide.
The Microsoft AD synchronization tool can provision Office 365 with object data from local AD by synchronizing the two directories. This provisioning method permits single sign-on or identity federation so users can access Office 365 services with the same credentials (user name and password) they use for local AD.
If you are provisioning Office 365 using the Microsoft AD Sync tool, from local AD, you can provision the local AD the same as for a proprietary Exchange target—using MNE features (with or without Quest CMN). The Microsoft AD Sync tool can provision the hosted AD from the local AD.
If you do not have local Active Directory, you can use MNE to provision Office 365 directly from the Notes source and create the hosted mailboxes. Otherwise, you could provision a hosted AD manually using the Microsoft Office 365 admin portal. Many administrators use scripting to automate some portions of the process.
NOTE: Exchange-to-Notes mail forwarding requires mail-enabled objects in Office 365. However, an Exchange-to-Notes free/busy query (an Office 365 user seeking free/busy info for a Notes user) requires that the Notes user not have an Exchange mailbox. (Exchange cannot send a free/busy query to an external server for a user who already has an Exchange mailbox. Exchange can send such queries only to its own mailboxes.)
If you cannot provision objects and create mailboxes separately, one or the other of those two features will be sacrificed. Microsoft's AD Sync tool can provision mail-enabled objects from local AD into Office 365 without simultaneously creating mailboxes, but other provisioning methods create Office 365 mailboxes at the same time they create the mail-enabled user objects.
Provisioning Office 365 by any method other than by the Microsoft AD Sync tool (from local AD) makes it impossible to have both Exchange-to- Notes mail forwarding and Exchange-to-Notes free/busy queries during the transition period.
This Exchange free/busy limitation is irrelevant if you do not intend to configure any free/busy coexistence. In that case, provision all users (in all collections) into the hosted AD in the Pre-Migration Preparations, to preserve Exchange-to-Notes mail-forwarding.
For most scenarios, inbound external (Internet) mail is not redirected to Office 365 until the last user has been migrated. We leave the MX record pointing to Notes throughout the entire transition period, and Migrator for Notes to Exchange can set Notes-to- Exchange forwarding for users as their collections are migrated. When the last user in the last collection is migrated, we update the MX record to redirect external inbound mail to the new hosted mailboxes.
If you want to keep your Notes environment running for a time after the migration, you should leave the Notes-to-Exchange forwarding in place, so any internal Notes mail is routed to the new hosted Exchange mailboxes.
Since inbound external mail is not routed to Office 365 until after all users have been migrated, Exchange-to-Notes forwarding is necessary only for internal mail from already-migrated Exchange users to not-yet-migrated Notes users. Mail routing in the Exchange-to-Notes direction requires mail-enabled objects in the hosted AD, but Exchange-to-Notes free/busy queries will not work if the Notes user already has an Exchange mailbox. (See the Important note in the preceding section for more information about this.)
If your organization wants both capabilities, you must use Microsoft AD Sync tool to provision Office 365 by directory synchronization from a local AD since that is the only method that lets you create mail-enabled objects and hosted mailboxes at different times. Provisioning from a local AD lets you create mail-enabled objects for all users in the Pre-Migration Preparations and to create mailboxes later during the Batch Migration Process—per user collection, prior to their migration.