Chat now with support
Chat with Support

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

About the Migrator for Notes to Exchange documentation Introduction Critical considerations Other strategic planning issues Appendix A: Known limitations of the migration process

Provisioning Office 365

Your organization may already have a local Active Directory running for login and security purposes, and if so Microsoft’s AD sync tool can copy objects from the local AD up to Office 365. But even where no local AD is already in place, many admins find it easiest to first configure and provision a local "staging" AD, so they can provision Office 365 from the local AD with Microsoft’s AD sync tool.

Provisioning Office 365 from a local AD makes possible what Microsoft calls single sign-on, and identity federation, so your users can access Office 365 services with the same corporate credentials (user name and password) they use for the local Active Directory.

The local AD is provisioned the same way whether your ultimate destination is the local AD (see Provisioning a local proprietary Active Directory above), or Office 365 to be provisioned from the local AD.

If you prefer, you could use Migrator for Notes to Exchange tools to provision Office 365 directly from the Domino source, or you could use Microsoft’s Office 365 online admin tools to provision manually—usually with some scripting to automate portions of the work. Note however:

Exchange-to-Notes mail forwarding requires mail-enabled objects in Office 365. But 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.)

Therefore, to have both Exchange-to-Notes mail routing and Exchange-to-Notes free/busy queries during the transition period, you must:

Provision all Notes users into Office 365 as mail-enabled objects, but without mailboxes, before the first users are migrated, and
Do not create users’ mailboxes until just prior to their migration (per user collection).

Microsoft's AD sync tool can provision mail-enabled objects from a 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.

Of course this Exchange free/busy restriction is irrelevant if you do not intend to configure any free/busy coexistence. In that case, simply provision all users (in all collections) into the hosted AD in the Pre-Migration Preparations, to preserve Exchange-to-Notes mail-forwarding.

Be sure to carefully consider these options before you begin the pre-migration preparations, and note your choices and methods in your Migration Plan.

Diagram before-and-after site configurations

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

Draw a network map of the pre-migration Notes/Domino environment, showing:

The network map should be a graphical 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, note also (but not necessarily on the same network map):

NOTE: Migrator for Notes to Exchange’s Notes Migration Manager includes a View Summaries feature that can report much of this info to help you assess the size and geography of your source environment.

Next, 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. Then 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, then you can probably get along without any accommodations for coexistence. So how do you assess your migration scale, to determine whether you will 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. Actual 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, then the throughput rate will likely be at the lower end of that 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 very good. Much higher rates have been reported under optimal conditions with high-performance workstation hardware.

The chart below can help you estimate the throughput rate for your migration project, but remember that actual 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 own throughput rate without experimenting in your own environment with your own data.

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

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)

 

Data Distribution
(percent of total data volume that is centralized)

Bandwidth is ...

0-25%

25-50%

50-75%

75-100%

Very Good

3.3

4.2

5.1

6.0

Good

2.4

3.3

4.2

5.1

Fair

1.5

2.4

3.3

4.2

Poor

0.6

1.5

2.4

3.3

... and then plug that value into this formula:

This formula will help you estimate the number of processing hours required for Quest’s Data Migration Wizard to migrate a particular volume of data under particular conditions, but remember there is much more to a migration project than just 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’s 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 just a couple of weeks, you can expect that these 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'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.

Related Documents