Hello @Venkateswaran TR , This may be a long read. What you are describing may be a de-merger of companies when this kind of situations arise, but I am not sure so I will start with some assumptions as per what you have mentioned in your post. I am assuming you have appropriate M365 licenses as well associated with your azure AD tenant. You should go through the article Identity Model for M365 which will provide a lot of insights .
Azure AD is not a drop-in replacement for On-premise AD. So you do not need to migrate the users and computes to Azure, you can sync them though using the Azure AD connect tool between the new ADDS on-prem once you have created it and migrated the users to this domain .
Ideally your migration plan should look like something below.
- Plan which public domain name you are going to use to verify in azure AD which will act as a UPN suffix for your users whose accounts will be in Azure AD . If it is something that is already used in the current forest and the users in that original current forest have that UPN suffix as their email domain as well then you may need to buy a separate pulic domain for the users in the new domain to use it once you have migrated them from source AD forest to new AD domain on-premise.
- Create the new ADDS domain on-premise.
- Use AD Migration tool to migrate the users and configure security translation for machine accounts and Sid history for users while setting up ADMT so that you have the existing SID history . You will need to configure the ADMT properly for this .
- All the Servers and Applications which you have in the source forest and would like to de-merge and move to the New ADDS domain which you will created by migrating the Tree-root domain will need to be migrated to new domain carefully .
- If any of these applications are something that users in both the source domain and new ADDS domain will be using you will need to plan for either a federation between both the AD domains by setting up Federation services like ADFS on both sides if your applications support SAML/WsFed auth schemes or Domain trust if the applications only support legacy auth protocols like Kerberos/NTLM etc.
- If the applications and the servers that you decide to migrate to new on-prem AD domain are only used by the users in the tree domain then its quite simple and you can just use ADMT to migrate servers from Old forest to your new on-prem AD domain .
- Add the domain suffix that you are going to use as an email domain for the users in the new ADDS domain as a primary UPN suffix
- Once your users and machines are migrated properly you can setup a new server as a azure AD sync server where we will install Azure AD connect tool and sync the new users in the on-premise domains to the cloud Microsoft 365 instance. Then you can sync your users from new on-premise domain to Azure AD tenant you already have.
- you can setup password sync on azure AD connect and it can help you .
- If you already have Exchange on-premise environment and want to use it for emails then you can setup the Hybrid exchange mode while installing the azure AD connect .
- If you already have all the users accounts in the Azure AD and old forest users are also synced to the Microsoft 365 tenant you mentioned about then I think you would need to create a separate M365 tenant for the new AD domain which you setup on-premise.
- You also should plan for how to move the emails for these users unless starting with a completely new mail is ok for these users in the new domain .
When you say "migrate-while-maintaining-access" , it will be tough in your environment to maintain continuous access and there will be some downtimes for sure as far as my experience goes. I don't think without checking your environment anyone can make a proper suggestion in this regard. I would suggest you to engage an Azure AD / Microsoft 365 consultant for the same. The answer I have given is based on multiple assumptions because there are many thing which need to be taken care of in this case and I would strongly advice to engage an Azure AD consultant for this.
Now that you have some clarity on this, the following are a few questions I would start with your customer.
- Is the Microsoft 365 already in sync with any on-premise Active directory ?
- Are the email domains that the company uses already been verified in the Microsoft 365 (or Azure AD instance)?
- Are the users which are in the tree domain using the same work email address? Do they have same UPN as the rest of the forest or the users in that tree domain use a different UPN ?
- Are the users using the mails with a domain suffix which you have common for all the users ?
- Are all the users in the existing forest including the ones in the tree-root domain are already synced to the Microsoft 365 Tenant ? If yes then this will change your scenario and it would be complex.
Hope the above gives you some idea about the migration and the questions to discuss . If the information provided was helpful , do accept this post as answer which will help others with similar questions in the community . I would suggest you to read through the links I have added in this answers and strongly suggest to engage a seasoned Identity management consultant with experience in AD and Azure AD and I am sure you will be ale to complete this without an issue. However there may be some downtimes as per the environment but I am not sure. I am talking as per my experience of what I have seen in de-merger scenarios . In case you still have any further queries , feel free to let us know in comments and we will be happy to help .
Thank you.