Attempts to use an import file to merge into an existing account fail with a conflict error - con (4352580)

target objects already exist, goal is to migrate and merge into existing account
import file syntax is:
samaccountname samaccountname
userold usernew

migration session fails with a conflict reporting conflicting value is samaccountname (already exists)

tried to select and unselect the matching by Name under domain pair properties
there is no sync in place, sync is not even configured

Migration session fails with an error: conflict by attribute, by samaccountname
DSA log contains entries like this:

04/07/08 13:28:34 (GMT-05:00) Target JobID:0 -> going to resolve conflict by: sAMAccountName value: msb77766
04/07/08 13:28:34 (GMT-05:00) Target JobID:0 -> unresolved conflict found: LDAP://dc1.source.com/CN= User Name,OU=EFG,DC=789,DC=qwert,DC=source,DC=com ws LDAP://dc1.quest.com/CN=User Name,OU=Users,OU=ABC,DC=123,DC=quest,DC=com by sAMAccountName value msb77766

Cause 1:

Users were migrated with the option match by Account name not being selected under domain pair properties so this incorrect migration created new accounts. Those new accounts are not visible in AD because they don't have display names. QMM created new accounts but could not populate the samAccountName attribute because such a value already exists in AD.

So QMM created a new object.  But AD does not allow creation of an object with empty samAccountName (MS, by design) so AD populates the samAccountName attribute with a random value, eg:

sAMAccountName = $TPL400-ESL5KIUF7VVC
This account is matched with the source account so all later attempts to migrate and merge are failing.

Cause 2:

If the matching attribute (extensionattribute15 by default) in the source is populated with a GUID that exists in the target domain, the DSA will automatically merge into that account regardless of what is entered into the second SAMAccountname column in the import file.  It will then attempt to change this account's SAMAccountname value to what is specified, and fail if that value already exists in the domain (which is likely why the import file was used - conflicting samaccountnames)

Cause 1:

In ADUC click on the users container.
Then add the DisplayName column and the Email Address column to the view and find all the accounts that have a blank DisplayName.
Delete those accounts and then migrate using import file and merge, it should work as expected.

Cause 2:

Undo the previous migration session, then clear the Matching and Auxiliary attributes from the source object, and try the session again.  Please note that in this scenario you may need to add userprincipalname to the import file in order to keep it unique, or skip it all together in the migration session options.

Knowing all this it makes perfect sense: you try to merge into an existing account but tool already matched into another existing account so tool thinks it needs to go to this already matched account and rename (change the samAccountName) but since there is already an account with this samaccountname it fails and reports a conflict. This can be also seen in the DSA log file.