Chatta subito con l'assistenza
Chat con il supporto

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

Coexistence with multiple AD domains

Server access rights, email routing, and calendar coexistence will need some special attention in a coexistence when the destination environment contains multiple AD domains. In this case, your Migration Plan should note:

•
Server rights must be set to allow the Notes Migration Manager and its wizards to access all of the various domain controllers.
•
The Provisioning Wizard and Groups Provisioning Wizard should be run against the primary AD domain controller, which is less likely to encounter latency errors (delays in directory updates among the various domain controllers and the Global Catalog).
•
Be sure to check the run logs for the AD Provisioning Wizard and Groups Provisioning Wizard. Errors in the log such as:
Unable to create group....
Unable to add group member....
... usually indicate latency problems, which can be resolved by simply waiting a few minutes and running the wizard again.

About Migrator for Notes to Exchange statistics

Migrator for Notes to Exchange’s Notes Migration Manager and several of the Migrator for Notes to Exchange wizards report data statistics: sizes of message stores, data volumes migrated, and so forth. This data can be valuable to migration admins in planning a migration, in monitoring the progress of a migration, and in assessing the performance of particular migration strategies and methods.

When reporting data volumes at various stages of the migration process, Migrator for Notes to Exchange qualifies these numbers by specifying reported values as Compressed or Uncompressed. Notes, Exchange and Migrator for Notes to Exchange all measure data volumes in different ways, and compress data in different ways, which makes meaningful comparisons and analysis difficult when the numbers are unqualified. For example, a 283 MB NSF file may become 2.3 GB as migrated by Migrator for Notes to Exchange, and then upon migration the target Exchange mailbox can be 439 MB. Some admins may suspect data losses, when actually the differences are entirely due to different methods of measuring data volumes at different stages of the migration process.

To eliminate much of that confusion, Migrator for Notes to Exchange notes whether its various reported values are Compressed or Uncompressed:

•
Compressed: Size of the raw data that Migrator for Notes to Exchange reads from Notes, consisting of the size of the original message and headers, and the compressed size of file attachments. (Notes compresses file attachments, but not the messages themselves.)
•
Uncompressed: Size of the data after Migrator for Notes to Exchange converts it to RTF, plus its headers, and also the uncompressed size of file attachments.

Migrator for Notes to Exchange logs the sizes of objects as they are exported with the Notes API, and the sizes of uncompressed file attachments. These qualified values provide a more meaningful measure of how much raw data Migrator for Notes to Exchange is reading and processing, and should help with migration time estimates. These reporting methods support good estimates derived by comparing the Compressed data rate to the size of the source NSF files.

Test and pilot migrations

Any full-scale production migration should be preceded by test and pilot migrations, to confirm that your Migration Plan and procedures will accommodate the organization's requirements. A test migration uses real users and real data in a segregated test environment, or dummy users and dummy data in your live production environment. A pilot migration uses a small portion of real users and real data in the live production environment.

In either case—a test or pilot migration—the data to be migrated should be a representative sample of the production data, and the test or pilot migration should be run with the Quest applications set for the same configuration and process options that you intend to use for the production migration. Select test or pilot users whose usage and data types make them representative of the total user population. Then run the migration for those users, just as you have defined the process in your Migration Plan. When the migration is complete, review the program's log file for any errors or warnings. (Quest's Log File Viewer application will help you view and interpret the program log file. See the Log File Viewer chapter of the Migrator for Notes to Exchange Administration Guide for more information.)

Quest recommends that you use both test and pilot migrations:

1
Perform one or more test migrations in a separate test environment, migrating test copies of real users and their real data. The separate test environment ensures that no test process will "touch" the data or configurations of your production environment. If a test exposes any problems with your Migration Plan, you can amend the plan and then repeat the test by simply "dumping" the test environment and recreating it from scratch.
2
When you are confident that your test migrations have sufficiently refined your Migration Plan, perform a pilot migration for 20 to 30 users in your production environment to verify that your plan is satisfactory for your "real world."

Implications of test and pilot migrations on license counts

Any test or pilot migration can be repeated as often as necessary at no "cost" to your production license key, since remigrations do not count in the metered use of a production license. That is, Quest applications recognize already-migrated users and do not count them toward your license limit, so you can repeat a test or pilot multiple times to refine your Migration Plan, and every user in the test will be counted only once.

Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione