CopyRight2 fully supports sidHistory style migrations, where the target accounts (users or groups) get additional old SIDs added to grant access to resources referencing those SIDs the accounts had in the source domain. Using the sidHistory feature allows you to separate the account from the resource migration at the expense of higher complexity. After the user and group accounts have been migrated, you would have to peform a sidHistory cleanup, replacing the old SIDs the accounts had in the source domain, with the SIDs the accounts got in the target domain. Once all SIDs have been replaced, usually in NTFS and share level permissions, the sidHistory Active Directory field can be cleared and the migration is completed. There are several requirements to meet if you want to perform a sidHistory migration. Please check the CopyRight2 user's manual for more information on those requirements.
This example does not make use of sidHistory, to simplify the process. You can either run a subsequent data migration, automaticallty replacing the SIDs on-the-fly while the data and permissions are copied to the target, or in case the data should not get moved, you can use a "Security & Attributes" type of job to perform a search & replace operation for the accounts. This method has no additional requirements and much less complexity than a migration using sidHistory.
This example shows an interforest migration. CopyRight2 supports intraforest (source and target domain in the same forest) migrations as well. This case requires sidHistory to be used. In this scenario, the accounts get moved between the two domains and not copied. After the account was moved, it automatically gets the SID of the original source account added to its sidHistory field allowing access to the resource originally accessible.In case of an intraforest migration, it is not possible to copy the account using the original samAccountName, because the samAccountName has to be unique within the forest.