Questions related to ADPW, resource process and sidhistory

Well, what you see as three questions is really eleven questions. The first 5 questions are product related and the other six of these questions are very basic and not product related. 

1. How does it process group membership? 
   ADPW uses a mapping file that contains the migrated objects. For each group processed, each member is checked if it is a member of the mapping data, if yes, it adds the mapped object to the group, if not it moves to the next member. 
2. Does it process source group membership only OR source & target groups both? 
   ADPW processes the groups you configured it to process. 
3. Do I need to process group membership only if it is applied on security descriptor of an AD object OR can it also process if it isn't applied on any security descriptors? 
   Depends on a number of factors. 
4. Does ADPW replace source groups and its source users with target groups with target users? 
   Depends on the setting of ADPW. It can append or replace.
5. Does this tool automatically determine on which security descriptors and groups should be processed or do I manually need to specify SD and groups?
   You select that needs to be processed based on what you did as part of your migration. Every migration is different. 

1. I need to know why resource process is required? 
   When you change the keys everyone has, you don't leave them with the old keys and leave the old locks in place do you? Each Sid is a key, each ACL is a lock. When you migrate a user from domain to domain, a new ObjectSID is assigned to the migrated users and groups. Why would you not update the ACLs on the resources to reflect the actual objects that have access to the resources?  You would not pass out new keys and NOT change the locks?
2. What will be impact if I don't do resource process? 
   Without sidhistory there would be no access to the resources until they were processed. 
3. What risk will this expose in future if I don't do resource process?
   Depends on a number of factors, but in short if you don't process, and you migrated with sid history, if someone cleans up sidhistory, access will be lost. If you don't process the resources while you have the tool and mapping data available, you will be stuck. if you get have a token bloat issue to resolve, It could be painful to resolve.  
4. I need to know why removal of sid history is required after migration? 
   Token Bloat https://support.microsoft.com/en-us/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou
5. What will be impact if I don't remove sidhistory after migration? 
   Token Bloat https://support.microsoft.com/en-us/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou
6. What risk will this expose in future if I don't remove sidhistory after migration?
   Token Bloat https://support.microsoft.com/en-us/help/327825/problems-with-kerberos-authentication-when-a-user-belongs-to-many-grou
   
   

Thanks for your reply Jeff

Q1) I need simple explanation on ADPW. What is the use/role of this and why do I even need to use this tool?

Q2) Is there any other impact or risk apart from token bloat if I don't remove sidhistory after migration?

1. I need simple explanation on ADPW. What is the use/role of this and why do I even need to use this tool?
   This depends on your migration and what other domains and forests exist. In a simple, Domain to Domain inter-forest migration where there was never a trust between the domains, AND you do not migrate the SecurityDescriptors. You only need it to clean up sid history at the end of the migration. If you have trusting domains of the source domain that you plan to maintain the trust with the target domain, you will need ADPW to update the trusting domain's groups that contain source domain objects. Sid History does not address this access type. 
2. Is there any other impact or risk apart from token bloat if I don't remove sidhistory after migration?
   If you migrate using sid history it is best practice to remove sid history at the end of the migration. Token bloat is not enough? It is more common then you would think, even without sidhistory in the mix. What are you looking for? Sid History is a crutch to same up front time and allow you to move task of processing the permissions on the resource out of band. What are you saving by leaving it in place?