Migrator for Notes to Exchange 4.15.2 - Pre-Migration Planning Guide

Throughput to Microsoft's Office 365

Migration to Office 365 uses the Internet to transport data, which can result in less consistent and unreliable migration throughput. Also, Microsoft imposes data throttles in Office 365, which take effect when any account (including migration admin accounts) initiates more than two concurrent data streams.

Each migration thread in Migrator for Notes to Exchange counts as one data stream, so Microsoft's throttle dramatically impacts performance when using more than 2 or 3 parallel migration threads in a single account. Quest migration apps ordinarily use 8 to 12 concurrent threads for migration to local targets, and even more threads for higher-end hardware.

Internet bandwidth and Microsoft throttling are independent of Quest's migration software and therefore, to some extent, are inherent to a migration to Office 365. But since Microsoft’s throttling is applied per admin account, you can run multiple admin accounts simultaneously, on separate machines, to mitigate the throttling limitations.

Migrator for Notes to Exchange includes an Account Pooling Utility that helps a migration administrator manage a pooled collection of Office 365 admin accounts, to sidestep Microsoft’s throttling limits. This utility makes it much easier to coordinate multiple admin accounts to run simultaneously, to multiply the throttled throughput rate by the number of accounts in the pool. The Office 365 Account Pooling Utility is documented in chapter 15 of Migrator for Notes to Exchange’s Administration Guide.

Note in particular that optimum throughput is achieved with only 2–4 migration threads per Migrator for Notes to Exchange workstation (per Office 365 admin account), whereas the Estimated Throughput Rates table above assumes 8–12 threads per machine to a local Exchange target. Migrator for Notes to Exchange’s Account Pooling Utility will likely help you recover much of the throughput lost to throttling, but a more accurate prediction of net throughput in your own scenario will require local testing.

Migrator for Notes to Exchange also offers several features to help you minimize timeouts when data transmission delays are encountered during a migration, which is more common when migrating to a remote, hosted target.

Keep these factors in mind as you estimate the scale and timing of an Office 365 migration.

Multi-workstation considerations

As noted above, the wizards of Migrator for Notes to Exchange can be run on multiple migration servers running in parallel. This approach opens several strategic options that you should consider and document in your Migration Plan. One simple option for the Data Migration Wizard is simply to assign different user collections to different migration servers, and define each task to include all necessary admin and migration functions for a collection.

The tasks defined by different wizards require access privileges for different servers—Domino and Active Directory and Exchange—depending on the scope of their functions. Likewise, different admin operations in the Data Migration Wizard require different access privileges—for example, admin access to Exchange and AD would not be necessary to set mail-forwarding rules in Notes, but of course admin access rights in Notes would be required for that function. You might therefore consider setting up multiple workstations with different access privileges to different environments, and then define tasks and assign them to various workstations accordingly.

The Set Task Schedule screen in some wizards lets you schedule a task to run on a particular workstation, or to run on any workstation. This workstation affinity option is offered for tasks created by:

Consider how you might define and distribute various tasks to an array of differently configured migration servers to maximize the efficiency of your overall process, and then document your strategy in your Migration Plan.

Phased migration strategy

Some administrators opt for a "phased" migration strategy, where users remain on the Domino server(s) throughout most of the transition period, while their oldest data (perhaps 90-95% or even more of the total) is migrated to the new Exchange environment. After the older data has been migrated, the proportionately smaller volumes of data remaining can be migrated relatively quickly, so that larger numbers of users can be migrated together within a shorter window. A phased-migration approach may save enough time in the final cutover phase to eliminate the need for coexistence (see next section below), where the migration scale would otherwise put a single-weekend migration just out of reach.

A phased migration is a variation of the more typical scenario, requiring some extra considerations and a few extra steps, as explained in the Phased Migration topic in chapter 1 of the Migrator for Notes to Exchange Scenarios Guide.

Coexistence during the transition

Coexistence is the state of two or more independent servers when both are serving the same organization at the same time—for example, when some users have already been migrated to a new server while others remain on the old server, awaiting migration. Coexistence introduces more complexity to a migration, and additional steps to the process. But for many organizations, some level of coexistence is essential for the continuity of critical business operations through the transition period of a migration.

An organization should therefore determine at the outset whether the scale of its migration project will permit a single-weekend or "phased" approach (as described above), or will require coexistence. Where coexistence is required, your written Migration Plan should specify the coexistence methods that best suit your needs.

For a Notes–Exchange coexistence, you likely will want to accommodate some combination (or all) of these primary issues:

NOTE: Quest’s Migrator for Notes to Exchange does not physically route email between Notes and Exchange. Migrator for Notes to Exchange can update mail-forwarding rules in Notes/Domino and AD/Exchange as users migrate from one environment to the other, to ensure proper routing throughout the migration. But the actual flow of mail is facilitated by some other mechanism, not by Migrator for Notes to Exchange.

While it is possible to route mail via SMTP addressing alone, this method offers no remediation for calendar data, or Notes "active mail," or for other email attributes, attachments and so forth. Most organizations will therefore want some tool to facilitate good coexistence between the Notes and Exchange environments. Migrator for Notes to Exchange is designed to complement the coexistence features of other tools, especially Quest’s own Coexistence Manager for Notes (CMN).

Several coexistence topics appear over the next few pages, including an overview of Quest’s CMN. Your written Migration Plan should include a thorough description of your organization’s coexistence strategy: mail-routing method and configuration, planned accommodations for directory updates and email remediation and calendar free/busy lookups, and the software tool(s) you will use to implement your coexistence strategy.

IMPORTANT: If you will configure free/busy coexistence between Domino and either a local proprietary Exchange or Office 365, the timing of your target provisioning (within the overall migration process) will be affected by this known Exchange limitation: Exchange cannot send a free/busy query to Domino for any user who has an Exchange mailbox. Exchange can direct such queries only to its own mailboxes. This is true with or without Quest’s CMN. The significance and implications of this limitation depend on whether you are migrating to a proprietary AD or to Office 365. For more information see Provisioning Office 365 earlier in this chapter.