Discovery.exe is a pre-migration discovery tool that collects mailbox and archive information. This valuable information is reported in a CSV file, and can be used to plan a migration. Command-line switches for Discovery.exe let you specify the types of information you want to capture, where you want it to be saved, and other program run options.
See the Discovery.Exe chapter of Migrator for GroupWise’s Administration Guide for full instructions and application notes.
One aspect of migration scale is the processing time required to migrate data from GroupWise to Exchange. Important factors that affect migration processing time are data volume, network bandwidth, and the hardware available to migrate the data. The Admin-Driven Batch Migrator can be run on multiple migration servers running in parallel, to migrate multiple user groups simultaneously. In this way, you might employ six migration workstations to migrate a particular data volume in a single weekend, whereas you may need six weekends to migrate the same volume via a single workstation.
Data "geography" and bandwidth are commonly significant factors affecting the rate of data migration and, as noted above, migration workstation hardware (memory, number and speed of CPUs, and disk speed) is also important. Actual throughput rates for the batch migrator program vary with the interplay of these relevant factors, but administrators typically report migration rates of 1 to 5 gigabytes per hour running 8–12 migration threads on a migration machine.
If the data to be migrated is distributed among servers in dispersed geographic locations, and if the bandwidth among these servers is not adequate, then the throughput rate will likely be at the lower end of that range. On the other hand, migration rates of 5 GB per hour and faster are common if the source data is centralized and the bandwidth is sufficient. Much higher rates have been reported under optimal conditions with high-performance workstation hardware.
The chart below can help estimate the throughput rate for your migration project, but remember that actual rates vary and you should not rely on these values as definitive. This 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 below.
To estimate the total processing hours of a migration project, determine the estimated throughput rate. The estimated throughput rates in this table assume migration to a local, proprietary Exchange, at an optimum number of migration threads (simultaneous processes, configurable in Migrator for GroupWise), typically 8–12:
This formula will estimate the number of processing hours required for Migrator for GroupWise’s batch migrator 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 GroupWise sources, provision users and distribution groups into Active Directory, define subset batches of users, and so forth. You should also allow time to review the Migrator for GroupWise programs’ log files, and make any necessary adjustments to the configuration or process.
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 batch-migration program 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 administrative tasks make it unwise to attempt a single-weekend migration if the estimated migration processing time exceeds 20 to 30 hours.
Migration to Office 365 uses the Internet to transport data, which can result in less consistent and less reliable data throughput. In addition, Microsoft imposed new 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 GroupWise counts as one data stream, so Microsoft's throttle dramatically impacts performance when using more than 2 or 3 parallel migration threads. Quest migration apps ordinarily use 8 to 12 concurrent threads for standard migration machines, and even more threads for higher-end hardware.
Internet bandwidth and Microsoft throttling are independent of Quest 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, and define a separate Microsoft admin account for each migration machine, to mitigate the throttling limitations.
Migrator for GroupWise 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. See the Account Pooling Utility chapter in Migrator for GroupWise’s Administration Guide.
Note in particular that optimum throughput to Office 365 is achieved with only 2 to 4 migration threads per Migrator for GroupWise admin workstation (per Office 365 account), whereas the Estimated Throughput Rates table above assumes 8–12 threads per machine to a local Exchange target. Migrator for GroupWise’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 setting will require local testing.
Migrator for GroupWise 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 Office 365 target. Use Migrator for GroupWise’s "retry" features to minimize timeouts when data transmissions encounter network delays. In the Migrator for GroupWise Program Parameters Reference, see the entries for:
Keep these factors in mind as you estimate the scale and timing of an Office 365 migration. The throttling within Office 365 will impact the per-machine throughput rates and should be considered during migration planning.
As noted above, Migrator for GroupWise programs can be run on multiple migration workstations running in parallel. This approach opens several strategic options that you should consider and document in your Migration Plan. One simple option for the batch-migration program is simply to assign different user batches to different migration workstations, and have each program run include all necessary admin and migration functions for the users in the batch.
The tasks performed by different Migrator for GroupWise components require access privileges for different servers: GroupWise vs. Exchange vs. Active Directory. Likewise, the different functions available within the batch-migration program require different access privileges, depending on the scope of their activities. For example, admin access to Exchange and AD would not be necessary to set mail-forwarding rules in GroupWise, but of course admin access rights in GroupWise 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.
Consider how you might define and distribute various tasks to an array of differently configured migration workstations to maximize the efficiency of your overall process, and then document your strategy in your Migration Plan.