1. SharePoint USER migration
Rishabh Y Mathur

2. Script
Assumption: AD user migration is migrating users based on OU and is not migrating all user objects at once.
We will have to migrate users in batches by getting the user mapping from your AD team for every iteration.
We could then use the below/attached reference script to migrate users
Sample script
============
Function MigrateUsers($inputUserFile) {
    foreach($SPSite in (Get-SPSite -Limit all))
    {
        foreach($SPWeb in (Get-SPWeb -Site $SPSite))
        {
            foreach($SPUser in $inputUserFile)
            {
                if($UserObject = (Get-SPUser -Identity $SPUser.UserAlias -Web ($SPWeb.url) -ea 0))
                {
                    Move-SPUser -Identity $UserObject -NewAlias $SPUser.NewUserAlias -IgnoreSID -confirm:$False
                    if($UserObject)
                    {
                        Remove-Variable -Name UserObject
                    }
                }
            }
        }
    } }
You can run by the below option with your AD team if this would make sense for you or not.
I have attached a full script that you could potentially leverage in full or parts. Please note that I highly recommend braking the script in parts and testing it first before applying any changes in production.
THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

3. Risk Mitigation
- The blog lists some side effects of move-spuser cmdlet, but the sample script I have attached takes care of it.
- In flight workflow will be affected with the move-spuser cmdlet as well. You will have to write some custom code to possibly associate those workflows to the migrated user identity.
Note: above issue was identified with earlier build of SP2010 (pre SP1, need to check exact build), SP 2013 you should not see this issue.
- Ensure you are disabling the mysite cleanup job during the migration process.
- Disable the “<UPA Name> - User Profile to SharePoint Full Synchronization” (ProfSync) timer job while user are being migrated.
Some other potential issues #1
SharePoint Designer 2007 workflows that have not been upgraded to SharePoint Designer 2010 workflows will fail to start if 'Move-SPUser' command is used to change the users or if IMigrateUserCallback is used to write object model that performs a similar task.
The following error will be displayed in ULS:
RunWorkflow: Microsoft.SharePoint.SPException: User cannot be found.

4. contd
RunWorkflow: Microsoft.SharePoint.SPException: User cannot be found.
at Microsoft.SharePoint.SPUserCollection.get_Item(String loginName)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.LoadWorkflowBytesElevated(SPFile file, Int32 fileVer, Int32& userid, DateTime& lastModified)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.LoadWorkflowBytesElevated(SPWeb web, Guid docLibID, Int32 fileID, Int32 fileVer, Int32& userid, DateTime& lastModified)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.<>c__DisplayClass1.b__0(SPSite elevatedSite, SPWeb elevatedWeb)
at Microsoft.SharePoint.Workflow.SPWorkflowNoCodeSupport.LoadWorkflowBytes(SPWeb web, Guid docLibID, Int32 fileID, Int32 fileVer, Int32& userid)
at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association)
at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow)
at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection`1 events, TimeSpan timeOut)
at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection`1 events, SPWorkflowRunOptionsInternal runOptions)

6. Contd #2
 Newsfeed posts that were created before the migration still reference the old account.  
 This is a known product behavior
 Move-SPUser command doesn't affect the Microfeed list, but is limited to UserInfo table.
The following list of columns from the Microfeed list may contain references to the old account name:
 PostAuthor - Refering the author of the current post
RefRoot – Whena user replies on a conversation that was initiated by another user.
RefReply – when the users replies don a conversation that was initiated by another user. The account may be URL encoded
PeopleList – the list of users that have replied to a conversation
Subscribers – the list of users that have subscribed to the conversation by replying or clicking the LIKE button
LikedBy – the users that have clicked on the LIKE button
ContentData – if a user is mentioned (by in a post or a comment). The account may be URL encoded
Ref:  
 SharePoint, MySites and AD domain migrations. How to make it happen smoothly

7. Lab testing - SEtup Performed below tasks in my lab environment
- Setup 2 forests : fabrikam and contoso
- Setup SP2013 in contoso domain
- Created a two way transitive trusts between the two forests
- setup people picker property as below
fabrikam domain users were searchable in people picker post execution of below query
stsadm.exe -o setapppassword -password ABCDEFG
Operation completed successfully.
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:fabrikam.com,fabrikam\administrator,access" -url
 Operation completed successfully.
Note: if password for fabrikam admin changes, peoplepicker will stop working. Need to run above cmdlet with updated password
Ref:

8. Lab Testing - state - Before Migration State
UserInfo table in content db
Logging in with fabrikam account

9. Lab testing – migration cmdlets
- User claim
Get-SPUser -Identity "i:0#.w|contoso\test1" -Web
 UserLogin DisplayName
i:0#.w|contoso\test1 test1
- Tested migration for one account successfully
$olduser = Get-SPUser -Identity "i:0#.w|contoso\test1" -Web
$newuser = "i:0#.w|fabrikam\test1"
Move-SPUser -Identity $olduser -NewAlias $newuser -IgnoreSID -Confirm:$false

10. Lab testing - state - Post migration state
Userinfo table in content database

11. Lab testing – wrap up
- Experience logging on to the site

12. Migrating users between domains Gotchas
- move-spuser gets applied across all web apps in the farm for specified user.
- SPD 2007 workflows that have not been upgraded to SPD 2010 will fail to start if 'Move-SPUser' command is used to change the user identity
- The migrate user cmdlet does the following in order:
 #Marks the “new login id” for deletion (if the “new login id” already has some permissions set)
#Replaces the “old login id” to the “new login id” (when the “old login id” already has some permissions set)
 More details: users-in-sharepoint-users-having-access-issues-after-migration/

13. People picker issue with old domain being active
Symptoms
Consider the following scenario:
The SharePoint farm exists in DomainB.
You have users in DomainA. 
You migrate users to DomainB, including SID history, and disable them in DomainB.
You use People Picker in your SharePoint farm to find a user in DomainA.
In this case, People Picker shows the active users in DomainA, but also shows the disabled users in DomainB.
If you choose the active user in DomainA, it may resolve to the disabled user in DomainB.
Another scenario here is that when you use people picker, it only shows the active user in DomainA, but when you select the user, it resolves to the account in DomainB.  For example, you find Contoso\User1.  However, when you select that user, it then resolves to Fabrikam\User1.
Notes: 
I’ve seen some customers leave both users active.  This same problem occurs, and the same resolution applies.
This is common in situations where the customer is using Exchange linked mailboxes to provide to users in DomainA.

14. Cont’d
Cause
People Picker calls a Windows API (LsarLookupSids3) to resolve the user name by SID.  This goes to the local DC first (in DomainB) which returns accounts matching that SID even though they are disabled.
This is a known issue, see the description here:
“Consider the following scenario: You add a user account in a domain (domain A) to a SharePoint site in another domain (domain B). You migrate the user account from domain A to domain B. You disable the user account in domain B. You use the People Picker control to search for the user account on the SharePoint site. In this scenario, both the active user account and the disabled user account are displayed”
Resolution
This is fixed in the August 2012 Cumulative Update (build ) for SharePoint 2010.  It is also fixed in the RTM version of SharePoint 2013.  You would also need to enable it for SharePoint 2013 RTM and above.
To enable the fix, run this stsadm command:
stsadm -o setproperty -propertyname "HideInactiveProfiles" -propertyvalue "true"
Notes:
Both the strings "HideInactiveProfiles" and "true" are case sensitive and must be entered exactly as shown.
After making this change, you may also need to temporarily disable / clear the LSA cache on the WFEs to clear out any “bad” SID to name mappings in the cache.  Failure to do so may result in the appearance that setting HideInactiveProfiles did not work. Example: In one case, the customer was hitting scenario #2 above.  After setting HideInactiveProfiles to True, Contoso\User1 was still resolving to Fabrikam\User1, even though other users we tested were resolving correctly.  This is because we had been testing with Contoso\User1 the whole time, and the SID was cached on the local WFE as resolving to Fabrikam\User1. Just follow the steps here to disable LSA cache on the WFEs:  
Important: Once you've disabled LSA cache and done at least one PP search, you should re-enable the cache by deleting the LsaLookupCacheMaxSize key.  Failure to re-enable the LSA cache can result in SIDs being resolved to the wrong accounts.  For example, entering "Contoso\User1" and hitting "check names" may resolve the account to Fabrikam\User1.