We came across an interesting support case with one of our best customers.  On one particular server, even the simplest migrations (no big attachments or images, no OLE objects, no workflows kicking off) were taking forever - several  minutes per document.

It turns out that while User Mapping* was turned on for the individual migration jobs, it was not configured for the SharePoint site we were migrating to.  The default configuration is to take the Notes name and try to use it "as is" in SharePoint (a configuration that rarely works out in real life).  So what was happening is that when SharePoint tried to validate the supplied user names in Active Directory, it took forever to get a negative response.  It turns out that in this very large enterprise's directory, looking up "good" user names is very quick but looking up "bad" user names is very slow.  My guess is that the directory is configured to try a lot of alternate directories if the requested user is not found in the main directory.

Once we understood this, the fix was obvious: configure our tool's user mapping process correctly.  Now when a particular Notes name can not be translated to a current Active Directory account, we will either substitute a generic identity or skip the record (depending on the job settings) and we never ask Active Directory to validate a bad name.

* For reference, User Mapping and Group mapping comes into play in three cases: (1) mapping the Created By and Modified By meta-data (2) mapping the access control list permissions and (3) mapping a user name field, such as "Next Approver".