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

Diagram before-and-after site configurations

Characterize the configuration of the organization servers, as they are now and as they will be after migration.

Draw a network map of the pre-migration Notes/Domino environment that shows the following information:

The network map is a graphic illustration to help migration planners visualize the relationships between the data volumes of the various servers and the inter-node bandwidths that connect them.

For each server show also (but not necessarily on the same network map):

NOTE: The MNE console includes a View Summaries feature that can report most of this information to help you assess the size and geography of your source environment.

Draw another network map to show your post-migration Exchange environment: the locations and domain names of all servers, and the data capacity of each server.

View the pre-migration and post-migration configurations side-by-side and determine which users from which Notes servers will migrate to which Exchange servers. Make a table to document these before-and-after server assignments for each group of users to be migrated.

Migration scale

The scale of a migration project is a critical planning factor because it determines whether an organization will require email, directory and calendar coexistence during the transition period. (Coexistence is explained in detail in a later section of this chapter.) The scale of a migration is determined primarily by the processing time required to move all of the data from Notes to Exchange. If the scale of your migration lets you move all of your users and their data from one environment to the other in a single weekend, you can probably get along without accommodations for coexistence. How do you assess your migration scale to determine whether you need coexistence?

The two most important factors that affect migration processing time are data volume, and the number of migration servers that will be used to migrate the data. Remember the Data Migration Wizard can be run on multiple migration servers running in parallel, applied to different user groups simultaneously. In this way, you might employ a half dozen migration servers to migrate a particular data volume in a single weekend, whereas you would need a half dozen weekends to migrate the same volume via a single workstation.

Data "geography" and bandwidth are the most significant factors affecting the rate of data migration, and migration server hardware (memory, number and speed of CPUs, and disk speed) is also important. Throughput rates for the Data Migration Wizard vary widely with the interplay of all relevant factors, but administrators typically report migration rates of 1 to 5 gigabytes per hour.

If the data to be migrated is distributed among servers in dispersed geographic locations and if the bandwidth among these servers is problematic, the throughput rate is likely to be at the lower end of the range. On the other hand, a migration rate of 5 GB per hour or faster is likely if the source data is centralized and the bandwidth is good. Much higher rates have been reported under optimal conditions with high-performance workstation hardware.

The chart that follows can help you estimate the throughput rate for your migration project. Remember that rates vary widely and you should not rely on these values as definitive. The chart does not account for hardware factors and your assessment of your own bandwidth is subjective and arbitrary. You cannot reliably predict your throughput rate without experimenting in your environment with your data.

NOTE: If migrating to Microsoft 365, the estimation method described is suitable for migration to a proprietary on-premises Exchange server, but migration to Microsoft 365 entails additional factors that warrant special consideration, as explained in the following section.

To estimate the total processing hours of a migration project, first determine the estimated throughput rate. The estimated throughput rates cited here assume that you are operating at an optimum number of migration threads (simultaneous processes), typically 8–12:

Estimated Throughput Rates (GB/hr)

... and enter that value into this formula:

This formula will help you estimate the number of processing hours required for Quest Data Migration Wizard to migrate a particular volume of data under particular conditions, but remember there is much more to a migration project than processing time. An administrator must also export directory data from Notes sources, provision users and distribution groups into Active Directory, define collections of users and groups, and so forth. You should also allow time to review the Quest wizards’ log files, to verify that the wizards’ run parameters are appropriate and efficient, and to catch and correct any minor problems before they become major problems.

Per-desktop tasks such as installation of the Outlook client, and sometimes the migration of archives (separately, per-user) also must be figured into the plan, and you should also expect an increased demand on the organization Help desk. You may find that a couple dozen instances of the Data Migration Wizard running on parallel workstations can migrate thousands of users over a weekend, but you’ll face a support nightmare on Monday morning if you haven’t ramped up your Help desk staff to accommodate all of the likely calls from freshly migrated users.

For a longer-term migration that will span more than a couple of weeks, you can expect that the other associated admin tasks will get easier and take less time as the project progresses. But these collateral admin tasks make it unwise to attempt a single-weekend migration if the estimated migration processing time exceeds 20 to 30 hours.

Throughput to Microsoft 365

Migration to Microsoft 365 uses the Internet to transport data which can result in less consistent and unreliable migration throughput. Also, Microsoft imposes data throttling in Microsoft 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 throttling 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 migration software and, to some extent, are inherent to a migration to Microsoft 365. But since Microsoft 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 Microsoft 365 admin accounts, to sidestep Microsoft 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 Microsoft 365 Account Pooling Utility is documented in chapter 15 of Migrator for Notes to Exchange Administration Guide.

Note in particular that optimum throughput is achieved with only 2–4 migration threads per Migrator for Notes to Exchange workstation (per Microsoft 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 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 Microsoft 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 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 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 document your strategy in your Migration Plan.