Provisioning Office 365
Your organization may already have a local Active Directory running for login and security purposes and, if so, the Microsoft AD sync tool can copy objects from local Active Directory to Office 365. But even where no local AD is already in place, many administrators find it easiest to first configure and provision local "staging" AD, so they can provision Office 365 from the local AD with the Microsoft AD sync tool.
Provisioning Office 365 from local Active Directory makes single sign-on, and identity federation possible so your users can access Office 365 services with the same corporate credentials (user name and password) they use for 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), 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 Office 365 online admin tools to provision manually—usually with some scripting to automate portions of the work.
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.)
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 with out mailboxes, before the first users are migrated. |
|
• |
Do not create user mailboxes until immediately before their migration (per user collection). |
The Microsoft AD sync tool can provision mail-enabled objects from local Active Directory to 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.
The Exchange free/busy restriction is irrelevant if you do not intend to configure free/busy coexistence. In that case, you can provision all users in all collections to the hosted AD in the Pre-Migration Preparations, to preserve Exchange-to-Notes mail-forwarding.
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 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):
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.
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 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 throttling 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 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 Office 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 Office 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 Office 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 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 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.
