Considerations during migration of Active Directory Domain services objects across forests via tool or cloud service for Active Directory Migration 

Upgrade and migration are two distinct but popular and mainstream operations for working with Active Directory objects and Organizational Units. Migration is usually to a new forest from say domain A to domain B. There are many considerations to migration. 

1.       Migration is about users not machines. It must be focused on users and groups. Machines come along with the users. 

2.       It is not easy to move all the things pertaining to a user all at once. This must be done one after another.  

3.       When organizations want to migrate, they envision something but what turns out at the end is usually different because when the migration is long, the landscape of objects changes from such things as acquisitions and mergers.  

4.       IT is wide and complex spread out across time-zone and geography so migration must scale to many objects 

5.       Migration pattern always involves a scale up and scale down as needed.  The drawing board for migration planning might project a best-case scenario as one where the pilot takes a constant time to build, and the business has no ups or downs but this is never uniform. There may be early adopters, if at all the pilot goes as planned, then there might be blackouts, followed by intense sprints and then the dwindling in terms of stragglers. These varying migration patterns can all be accommodated by self-service which is critical to enable many customers. 

6.       It is best to require users to self-serve themselves because their situation might vary from one to another.  

7.       There must not be any damages caused due to migration. Before and after the migration they must remain working and especially after migration, there must not be any more fixes to be made. 

8.       Prerequisite checking is important towards this purpose. Flights and dry runs are part of the migration process. The migration process is successful only when it has been carefully planned out. 

Expectations must be softened for Active Directory migrated objects. The security identifier for a user, for example, is not going to be the same. That is generated by a domain controller and a new domain has its own controller. The process of issuing a security identifier involves a Relative Identifier Master or RID master which has a Flexible Single Master Operations role. This is a domain scoped role. Each RID master role can allocate active and stand-by Relative identifiers.  The RID master can move multiple objects across domains within the same forest. Since it is a single master, when it is down, no new objects can be created. This might seem severe but in established organizations, creation of new objects is low so the brief downtime can be tolerated. If the role is seized and the original domain controller is brought back online, duplicate RIDs may be introduced. 

The following PowerShell commands can help: 

Get-ADForest <domain> | Format-Table SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster 

If the source and target DC are not the RID master, the error is  
move-adobject : The requested operation could not be performed because the directory service is not the master for that type of operation