Chat now with support
Chat with Support

Migrator for Notes to Exchange 4.15.2 - 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

Implications of test and pilot migrations on statistics

Quest applications do collect migration statistics through any test or pilot migration, and will save the stats in the SQL Server database. These "test" statistics will be included with the real production stats if you let them remain in the database when the production migration runs begin.

In many cases the volume of these test statistics compared to the production stats will be so small as to be negligible. If, however, you want to reset your statistics to zero, the easiest way is to simply erase the entire migration server, including the SQL Server database (which contains the statistics), and reinstall the Quest software from scratch. But note that this approach will also erase all of your Quest application configuration settings, which you will then have to recreate after reinstallation.

1
In Notes Migration Manager: Select File menu option Edit Global Default Settings.

You can then reenter the Global Default Settings when you reinstall the Quest software.

Other strategic planning issues

Desktop considerations

If user workstations will need Outlook installed or upgraded, you must determine before the first users are migrated how you will accomplish the installations or upgrades. Users in most organizations will be using the native Notes client, and will therefore need Outlook installed, although some organizations may be using a MAPI service that permits the use of Outlook to access Domino. Remember that installing Outlook requires administrator privileges on end users' machines. A configuration management program can be used to distribute and install Outlook at sites where that is necessary. New profiles can be defined during or after the Outlook installation.

Batch vs. per-desktop migration

Quest's Data Migration Wizard and the Self-Service Desktop Migrator both can migrate the same types of data, so the overall migration will usually be more efficient if an administrator can use the Data Migration Wizard to migrate all or most users in batches, called user collections. A user collection typically numbers a hundred or so users, all migrated together in a single program run. Your Migration Plan should specify whether you will migrate users in batches, or one at a time, or by some combination of the two.

Consider that the Data Migration Wizard can migrate user archives only if they reside in a single centralized location, or if their locations can be specified per user in the SQL Server database. Batch migration may therefore require that users copy their archives to a central location if they are not currently stored on a network drive, or an admin may have to manually add the per-user archive locations to the Migrator for Notes to Exchange database prior to running the Migration Wizard.

Alternatively, the Self-Service Desktop Migrator can be used to migrate archives, one user at a time, after the Data Migration Wizard has migrated the server-based data for a user collection. If user archives are not centrally accessible, or if some other local circumstance or preference makes batch migration impractical or inadvisable, the Self-Service Desktop Migrator is simple and intuitive enough that most end users will be able to run it uneventfully.

Some administrators prefer to visit select desktops personally, running the Self-Service Desktop Migrator on behalf of end users, to ensure a smooth transition for executives, or for users who may be uncomfortable attempting the tasks themselves.

If you intend to migrate any user data by user collections, your Migration Plan should note your requirements and preferences for these aspects of user grouping:

Grouping Method: Determine how you will group your users for migration. It is often helpful to migrate users in logical groups, related by business function or administrative entity, or by physical proximity, so users can support one another through the transition.
Optimum Number of Users Per Collection: The optimum number of users for a migration collection depends on the per-user data volume on the source server, the data geography (physical distribution) and bandwidth, and the capacities and configuration of the destination servers. The number of users per collection should also correlate to the capacity of your organization's Help desk, since you can assume that the transition will stimulate increased demand for Help resources. Consider also that the wizards’ log files will likely bloat to unwieldy sizes for collections much greater than 100 users if you ever need to set the logging to verbose mode.
Migration Scheduling: Determine how you will schedule collections for migration. This is often just a matter of avoiding each collection's critical dates on the calendar. For example, finance and accounting staff should not be disrupted at the beginning of the month when they are trying to close the books. Likewise, sales staff would prefer no interruptions near the end of a quarter when they are attempting to meet their quotas. Many organizations migrate their IS or Help Desk staff first, since they are typically the most savvy users and will likely help to support other users as the migration proceeds.
Related Documents