As throughput rates can vary for multiple reasons, this document should not be used to plan migration times. Testing should be completed to see the throughput you are getting and used for your migration times.
Key factors that can significantly affect the rate of data migration are:
Actual throughput rates for the batch-migration program vary widely with the interplay of all relevant factors, but customers have reported migration rates of 1 to 3GB per hour.
In a Migration to On Premise Exchange, if the data to be migrated is distributed among servers in dispersed geographic locations, and if there are bandwidth constraints between these servers, then the throughput rate will likely be at the lower end of that range. On the other hand, a migration rate of 3 GB per hour or faster is likely if the source data is centralized and the bandwidth is very good. Rates as high as 20 GB per hour have been reported under optimal conditions with high-performance workstation hardware.
For migrations to Office 365, the throttling internal to Office 365 reduces the throughput and customers have reported seeing 200-500MB per hour, per machine. NOTE: these ranges are guides only of what we have seen from environment to environment. The numbers should not be taken as a guaranteed throughput for your environment. Once you begin migrating only then will you be able to determine what your expected throughput in your environment will be. If you follow the recommendations below these will be the best practice to ensure you are getting the best throughput that is possible in your environment.
For more information on how to determine the scale of a migration project and on the implications of scale, refer to the section titled Migration Scale and Duration of the Quest GroupWise Migrator for Exchange User Guide.
Additional Information:
Please note that GroupWise Migrator for Exchange makes use of the GroupWise client to open and copy mail content from the source GroupWise server. Once the GroupWise data is copied over to the migration console, MFG then utilizes Microsoft Outlook (via MAPI calls) to write mail content to the Exchange mailbox. Given this background, please take the following into consideration:
1- Have the GroupWise server as close as possible in terms of hops to the migration console. It takes longer to retrieve data from GroupWise than it does to get into Exchange (Outlook is better than GroupWise Client in terms of WAN connectivity)
2- If there are many servers globally, along with slow links, either replicate the data over to a central server or use the self-service desktop migrator (SSDM) for smaller remote sites.
3- Schedule migration during off-peak and out-of-office hours, and not during busy or data backup times.
4- Make sure there is no Active virus scanning software running on the GroupWise Server, migration machine, and on the Microsoft Exchange server for the duration of the migration.
Note: The word Active above implies that the virus scanning software intercepts the content prior to being written to the said hard-drive space. It is possible that the virus scanning software will intercept the data for a period of time (possibly milliseconds) which can cause the APIs (either GroupWise or Outlook) used to return errors - sometimes even inaccurate/bogus errors. Most software venders allow the Active scanning to be turned off, leaving the software in a Passive state which means the anti-virus software is still running but will not touch the content until the said content is viewed (opened). Please review the virus scanner vendor documentation for instructions on how to turn off the Active scanning for the duration of the migration. Once the migration is complete, please enable Active Scanning.
5- Corrupted GroupWise data can cause delays and migration errors. Run GroupWise Check (GWCheck) to remedy (as much as possible) corrupt data before the migration.
Note: For more information on GWCheck and its usage, please see the following Novell article titled GroupWise Check at the following link:
6- Re-creating the Groupwise QuickFinder index files can help with improving the migration performance. Please check with the Groupwise administrator prior to performing this.
7- Increase thread count one by one. Typically, optimum throughput rates are seen with 8 to 12 threads.
Note: One thread equals one mailbox migration. Please note that threads can be increased/decreased at will, but most times a threshold will be met on one of the computers (or network) in the migration (either the GroupWise server, migration console, or target Exchange server). Thresholds can be (as an example) related to network, CPU utilization, RAM, hard drive read/writes, etc. If a threshold is met and the thread count is continuously increased, the result could be a degradation of performance. Please perform a few test migrations to find a satisfactory baseline and optimal thread count for the existing environment.
8- When pointing GroupWise Migrator for Exchange to an Active Directory domain controller, please select this to be a Global Catalog server. If there are replication delays between domain controllers and the Global Catalog servers, certain GroupWise Migrator for Exchange actions may fail (in particular, related to Active Directory Object Merge Tool and Exchange Mailbox-enabling).
9- In certain circumstances, adding another migration console may enable the migration to move more data concurrently (where network bandwidth is not a factor).
10- When running actions for GroupWise Migrator for Exchange, ideally run them separately. For example, run and finish the mailbox-enabling process as a separate action with GroupWise Migrator for Exchange, prior to performing the actual data migration. Failure to do so may result in errors (mailbox-enabling may take time to finish or replicate, and running the subsequent mail migration concurrently/immediately may result in failure as the mailbox-enabling operation could still be incomplete or possibly not replicated).
11- GW servers are running on Windows instead of Netware, which can cause significant timeouts if the NIC on the migration servers is not configured correctly. In order to speed things up, you have to change the provider order using the following process:
12- For more information on throughput/speed when migrating to Office 365 please refer to Solution 75706 - Slow migration to Office 365.
