Migration design to Azure Cloud from vmware VM on premises Domain controller of Web APP

LikelyThe choice of the most approach depends primarily on whether the web application uses modern authentication protocols such as OIDC, OAuth 2.0, or SAML, or legacy protocols such as Kerberos, LDAP, or NTLM. Because the environment also includes domain-joined workstations and users, I would treat the application migration and identity migration as related but separate workstreams. If the web application can authenticate directly with Microsoft Entra ID or Auth0 using OIDC, OAuth 2.0, or SAML, lifting and shifting the existing VMware domain controller into Azure is generally unnecessary. The preferred long-term architecture is to modernize the identity layer and remove the application's dependency on Active Directory.

For the modern cloud-native architecture, migrate the web application to an Azure managed hosting platform such as Azure App Service where the application is compatible with it, or to Azure Container Apps/AKS where containerization is appropriate. Configure the application to use the organization's existing Microsoft Entra ID tenant for authentication and SSO, preferably through OIDC/OAuth 2.0. SAML is also appropriate when required by the application. Users authenticate with their organizational Entra ID identities, while Microsoft Entra ID handles authentication, multifactor authentication, Conditional Access, and other tenant-level identity controls. Auth0 can also be used as the identity provider when there is an existing architectural requirement for Auth0, but using both Auth0 and Entra ID solely to provide SSO introduces another identity layer that needs to be administered and secured.

For workstations, the corresponding cloud-native design is to transition Windows devices from traditional Active Directory domain join to Microsoft Entra join and manage them through Microsoft Intune rather than relying on Group Policy. This is a separate migration from the web application itself. If users currently exist only in on-premises AD DS, Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync can synchronize the required identities and groups into the organization's existing Entra ID tenant. This allows the same organizational identities to be used for workstation sign-in and web-application SSO. The eventual end state can then be an Azure-hosted application, Microsoft Entra ID for identity and SSO, and Intune for workstation management, with no dependency on an on-premises domain controller.

If the web application or other workloads still require traditional AD DS capabilities such as Kerberos, LDAP, NTLM, Windows Integrated Authentication, domain joining, or Group Policy, then the architecture changes. In that case, extending AD DS into Azure is reasonable. I would use a hub-and-spoke network architecture, but the reason for the hub-and-spoke design is network and infrastructure separation rather than the mere presence of a domain controller. The Azure hub can contain shared connectivity and security services, while the application is placed in a spoke. Connectivity between the existing VMware environment and Azure would normally use Site-to-Site VPN or ExpressRoute. The Azure application spoke can communicate with the AD DS infrastructure through controlled network connectivity and DNS resolution.

For the AD DS migration itself, I would not treat the existing VMware domain controller as a VM that should simply be copied or converted into Azure. A cleaner approach is to deploy a new Windows Server VM in Azure, establish connectivity to the existing domain, join the new server to the domain, and promote it as an additional domain controller. AD DS replication then transfers the directory information to the Azure domain controller. After the Azure environment has been validated, domain-controller roles and, where appropriate, Flexible Single Master Operations (FSMO) roles can be transitioned in a controlled manner. The existing domain controllers should remain available until replication, DNS, authentication, application dependencies, and workstation operations have been validated. For production reliability, the Azure design should also account for multiple domain controllers and appropriate availability zones or separate fault domains where supported and appropriate.

Microsoft Entra ID should remain the cloud identity service even when AD DS is retained. AD DS and Entra ID have different roles: AD DS provides traditional domain services such as Kerberos, LDAP, computer authentication, and Group Policy, while Entra ID provides cloud authentication, SSO, Conditional Access, multifactor authentication, and application identity. Entra Connect Sync or Cloud Sync can synchronize identities between them. There is no requirement to move the organization's entire directory into a new Entra tenant simply because the application is being migrated. The application can be registered in the organization's existing Entra ID tenant and use that tenant for SSO.

There are some boundaries to consider. Entra ID does not natively provide traditional AD DS protocols such as LDAP or NTLM, so an application that depends on those protocols cannot simply be pointed at Entra ID. If the application uses Windows Integrated Authentication or another legacy authentication mechanism, the application needs to be modernized or an appropriate Azure architecture must be used to preserve the legacy authentication requirement. Microsoft Entra Application Proxy can support certain legacy application scenarios, including Kerberos-based applications through Kerberos Constrained Delegation, but that should be evaluated against the application's actual authentication flow rather than assumed to be a general replacement for AD DS.

For the workstations, if traditional AD DS must remain during the transition, Microsoft Entra hybrid join provides a transitional architecture in which devices remain associated with on-premises AD DS while also being represented in Entra ID. This allows cloud services and Entra-based SSO to be introduced without immediately removing the existing domain dependency. If the objective is ultimately to eliminate AD DS, the longer-term migration is from hybrid/domain-joined devices to Microsoft Entra-joined devices managed by Intune. Group Policy settings that are still required need to be mapped to Intune configuration policies, security baselines, compliance policies, or other cloud-management mechanisms before the corresponding AD DS dependencies are removed.

Likely the most important architectural decision is consequently not "should the domain controller be moved to an Azure VM?" but "does anything that remains require AD DS?" If the answer is no, I would target an architecture in which the web application uses Entra ID directly, workstations use Microsoft Entra join and Intune, and the existing AD DS environment is progressively retired. If the answer is yes, retain AD DS during the transition and deploy additional domain controllers in Azure rather than performing a simple lift-and-shift of the existing VMware DC. The hub-and-spoke architecture is appropriate for that hybrid scenario, with the hub providing shared connectivity and infrastructure and the spoke containing the application workload.

For reliability, I would implement this as a staged migration - so first establish Entra ID integration and synchronize the required identities; then establish modern SSO for the web application; migrate the application to Azure; migrate workstation management toward Intune and Microsoft Entra join; retain AD DS only for identified legacy dependencies; and finally remove those dependencies before decommissioning the remaining domain controllers. This avoids making the Azure web application dependent on AD DS when it does not need it, while still providing a controlled path for workloads that cannot yet use modern authentication.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin