Pick a computer to do all the ADMT stuff from. Don't ever use a different computer. Easiest to use a target domain controller. This gives you the benefit of knowing where the changes happened (for replication questions).
Get an account that can do the migrations. Easiest thing to do is to add a source domain admin account to target\administrators.
Decide whether to migrate passwords or reset them.
Decide whether you can & want use altSecurityIdentities to hide the migration from users (this requires either all kerb services or sync'd passwords)
Pick a collision behavior: fail, rename with the prefix, overwrite. Rename with prefix makes most sense to us, followed by a post-migration task to search for this prefix.
Decide how to deal with global group memberships:
Migrate users and groups together
Elevate all global groups to universal, then migrate users, then migrate groups. See footnote 1.
Migrate users, then migrate groups. Ignore interim situation where destination user doesn't have access to a resource with source global group ACL.
Post migration:
Fix UPN if it's an intraforest user migration.
Fix LAG membership (and any other skewed attributes) if it's a delete destination user & recreate via migration scenario.
Reset altSecurityIdentities if used
Search for collision rename prefix if applicable.
Enumerate services with service accounts with the Service Account Migration wizard by feeding it all potential computers to check. Ensure that all the pre-migration steps under Computers below have happened prior to doing this.
Migrate the service account(s) with the User Migration wizard, and update the services that have been previously enumerated.
On failure:
Service account migrations can fail to update the services running on computers during the user migration. This is a known bug due to replication latency. If the computer with the service contacts a DC that doesn't have the newly migrated account yet, then it fails to update it's info. Via the service account migration wizard you can force this to update after the user migration by choosing the 'no, use the previously collected info' option, then selecting the services that need update, and clicking the 'update SCM now' button.
Pre-migration tasks:
No firewalls between the ADMT computer and the destination computer(s). This includes SP2 firewalls.
No IPSEC rules that prohibit SMB between ADMT computer and the destination computer(s).
File and printer sharing for MS networks must be enabled.
Server service must be running.
Netbios of TCP/IP must be enabled.
Either
The computer has a valid DNS name. This DNS name can be resolved by the ADMT computer. This DNS name is the value in the dnshostname attribute on the computer's account.
or
The ADMT computer and the computers to be migrated must either be on the same network or share a WINS server. The dnshostname attribute is deleted on the computer's account. Some actions on the computers can recreate the dnshostname attribute, so you want to delete the attribute reasonably close to the migration time. See footnote 2.
The relevant users and groups in ACLs on the computer(s) to be migrated have already been migrated (via the same ADMT computer).
The 'Change primary DNS suffix when domain membership changes' checkbox is set to the correct value (no reboot necessary).
Pick a collision behavior: fail, rename with the prefix, overwrite. We use fail—except for the cases where a computer just failed to migrate and we are re-trying the migration.
Post-migration tasks:
If ADMT reports any errors or has an unknown status, check the agent logs. For complete with errors, you can drill down to the logs from within ADMT as long as the computer is up. Otherwise, check %systemroot%\temp\dctlog.txt.
Footnote 1:
In the case of a multi-domain forest, with group memberships from multiple domains & use of groups on resources in multiple domains, it is safest to elevate all group types to Universal, then migrate. In other words, if you are collapsing several domains, then you probably need to temporarily move to universal groups to avoid problems for the interim period.
Footnote 2:
I found that using ldp.exe, with the modify operation, delete dnshostname attribute and just changing the DN of the target object was fairly quick for multiple computers in the same OU. But that was largely because the computer names only differed by a character or two. You might also use the AdsiEdit MMC snap-in to make this change. For a large migration, a script would be desirable. There's also a hotfix that changes this behavior. But it still tries DNS resolution first, which would introduce a substantial delay into the agent deployment process as you wait for DNS resolution to fail. So I think the best option is to kill the attribute.