Lotus Notes Migration Preparation & Troubleshooting

The following information may be helpful preparation for Lotus migrations with special considerations including folders with large items, too many items in the folder, or multiple extractors. 

Migration Preparation

Too Many Items in Folder

If a folder contains more than 20,000 items, the GetFullItems or GetAllItems may fail to return anything within the timeout threshold. This will cause a "Too Many Items in Folder" error, which fails the migration.

To avoid this, create subfolders under the main folder for any folder over 20,000 items. Distribute the contents of the large folder equally into the subfolders. No subfolder should contain more than 15,000 items. Be sure to move the items, as copying them will not solve the problem. 

If this step is followed in source preparation, this error should not appear.

If this error has appeared during the migration, reset item statistics and run the migration again. 

Large Items in Folder

Too many large items (generally larger than 10MB) in a folder may also cause a GetFullItems failure. If this happens, it will trigger an error and the migration will fail. To solve this issue or prepare the source to avoid this issue:

1) Create subfolders under the Inbox folder.
2) Sort items in the Inbox folder by size in descending order
3) Move all items into the newly created subfolders in equal quantities. 
4) If this error has appeared during the migration, reset item statistics and run the migration again. 

Multiple Extractors & Large Concurrent Migrations

A large migration may cause multi-threading issues on the Lotus Extractor. This memory issue may be alleviated by creating multiple extractor clients on additional VMs and running 1-2 migrations per extractor. 

However, submitting too many migrations at once may overload the Domino servers, causing migration failure. The bulk of the migration is processed on the Domino server, including copying items, performing item conversion, cleaning up copied and converted items, and processing the next batch of items.

The number of concurrent migrations needs to be determined on a per-migration basis. Verify which server you are using, and how many migrations can be done concurrently. This can be a time-consuming process, but will save time in the long run. 

To verify:

  1. Run a single migration and wait for it to complete.
  2. Determine the performance of that migration.
  3. If the performance is good, increase the Maximum number of concurrent migrations of a MigrationWiz project from 1 to 2.
  4. Submit 2 migrations and let them complete, then follow steps 2 & 3, this time increasing the maximum number of concurrent migrations from 2 to 3.
  5. This process may be repeated until the performance begins to suffer.

Divide the highest number of migrations the server can successfully perform by the number of extractors you are using to find out how many migrations each extractor should run. For example, if you are able to do 6 concurrent migrations and are using 3 extractors, each extractor should have 2 migrations running on it at a time. 

A single Domino server should never have more than 3 extractors pointing to it, and a single extractor should never run more than 5 migrations at any given time. Any more load than this may overload the Domino server and exhaust the resources. However, some Domino servers will not be able to run more than 1 migration at a time, no matter how many extractors are running. 

If a particular migration is causing problems, run that migration by itself, without any migrations running on any other extractors pointing to that Domino server until that migration is complete.


Slow Throughput

If there are many Delivery Failure Report messages or calendar/meeting update items (i.e. meeting cancellation, meeting acceptance, meeting date/time update, etc.) in the Inbox folder, it may cause slow throughput, as these items are not migrated by MigrationWiz. This may also cause the GetFullItems or GetAllItems commands to fail to return anything within the timeout threshold, which will fail the migration. 

To solve this problem, we suggest either deleting all of the Delivery Failure Report items from the source mailbox. You may also create a new folder named Delivery Failure Report, and then move all the Delivery Failure Report items into the folder, and then filter out that folder by following the instructions in Folder Filtering & Mapping article.

The same steps should be followed for the Calendar/Meeting acceptance items. 

Corrupt Items

MigrationWiz will attempt to repair corrupt items as part of the migration, but it may not always be able to do so. These attempts will slow the migration, as they take time to assess and repair. If they are too corrupt to fix, MigrationWiz will move on to the next item, but this process may cause failure of the GetFullItems or GetAllItems commands, failing the migration. 

To fix this, have your Domino admin run an offline defrag of the NSF file, or a FixUp against the end-users NSF file on the source Domino server. Once one of these actions is completed, resubmit the migration.

If problems persist after running a FixUp, create a replica of the original NSF file and use that replica instead of the original file. This may solve the issue as severely corrupted items cannot be read and will generally not be created in the replica.

If migrating from the replica, problematic or corrupted items in the original NSF will not exist in the replica, and will not be migrated. 

Was this article helpful?
0 out of 0 found this helpful