Migrating Legacy Apps to Azure: When to Choose Microsoft Entra Domain Services vs IaaS Domain Controllers

When lifting and shifting legacy Windows applications to Azure, architects face a critical identity dilemma: should you deploy traditional Active Directory domain controller virtual machines or use managed cloud services? This guide explores the architectural trade-offs, operational overhead, and cost implications of choosing Microsoft Entra Domain Services over custom IaaS domain controllers for legacy Azure workloads.

The Legacy Azure Migration Dilemma

Moving a legacy business application from an on-premises server room to an Azure virtual machine does not automatically make that application cloud-native. Many established Windows applications—such as legacy enterprise resource planning systems, financial platforms, and custom .NET applications—were architected around traditional Active Directory. When these workloads arrive in the cloud, they still expect to query directory services via LDAP, authenticate using Kerberos tickets, or apply settings through Group Policy.

Cloud architects are immediately forced to make a strategic decision. You can connect your Azure Virtual Network back to your on-premises domain controllers using a hybrid VPN tunnel, but this introduces latency and creates a dangerous single point of failure if the network link drops. Alternatively, you can spin up brand-new Windows Server virtual machines inside Azure, promote them to domain controllers, and build a brand-new forest or replica domain.

While building your own domain controller VMs in Azure gives you total control, it also turns your cloud infrastructure team into active directory administrators. You become entirely responsible for operating system patching, directory replication monitoring, disaster recovery planning, and securing high-privilege accounts against credential theft. For organizations looking to minimize operational overhead while keeping legacy applications running, this is often an unnecessary burden.

Entra Domain Services vs. IaaS Domain Controllers: Core Architectural Differences

Understanding the architectural distinction between using Microsoft Entra Domain Services and building custom IaaS domain controllers is essential for designing resilient Azure cloud environments. Entra Domain Services acts as a managed compatibility layer. Microsoft runs and maintains the underlying domain controller infrastructure behind the scenes, ensuring high availability, automatic backups, and background synchronization with Entra ID.

When you consume Entra Domain Services, your Azure virtual machines can join the domain, execute LDAP queries, and handle Kerberos or NTLM sign-ins without your engineers ever needing to remote desktop into a domain controller. However, this managed service trade-off means you surrender direct administrative control. You cannot access the underlying operating system, you cannot modify the Active Directory schema, and you do not receive Domain Admin or Enterprise Admin privileges.

Conversely, deploying IaaS domain controllers gives you absolute power over the directory architecture. You can extend your schema, configure custom trust relationships, add arbitrary organizational units, and implement specialized group policy objects without restriction. The penalty for this flexibility is maintenance. Your team must manage the entire domain lifecycle, including proactive health checks, database defragmentation, and emergency restoration procedures if a domain controller crashes.

Operational Trade-offs and Administrative Guardrails

Before committing to a managed domain approach in Azure, cloud administrators must carefully evaluate how day-to-day operations change. With custom IaaS domain controllers, your team has granular control over every aspect of the directory. You can write custom PowerShell scripts to automate administrative tasks, install third-party security agents directly on the domain controllers, and troubleshoot replication errors using native utilities like repadmin.

Microsoft Entra Domain Services replaces this hands-on approach with managed guardrails. Administration is performed via a dedicated group called Entra Domain Services Administrators, using management utilities installed on a separate, domain-joined Windows virtual machine. While you can create custom organizational units, manage DNS records, and apply supported Group Policy settings, you are strictly fenced off from the core infrastructure.

Furthermore, identity management follows a strict one-way synchronization model. User and group identities flow from your authoritative source—either cloud-only users in Entra ID or synchronized identities from an on-premises Active Directory—down into the managed domain. You must never attempt to treat Entra Domain Services as a primary directory for modifying user attributes, because those changes will not synchronize back upstream and will eventually be overwritten.

Decision Framework: Making the Right Architectural Choice

Selecting the correct approach requires evaluating your organization's specific technical requirements and long-term cloud strategy. If your primary goal is to migrate legacy workloads to Azure while eliminating the operational tax of running Windows Server virtual machines as domain controllers, a managed service is nearly always the preferred route.

Use Microsoft Entra Domain Services when:

• You are migrating legacy applications to Azure that require LDAP read lookups, Kerberos, NTLM, or domain join capabilities.
• Your organization wants to avoid the overhead of patching, monitoring, and recovering custom domain controller virtual machines in Azure.
• You operate a cloud-first or cloud-only organization and need traditional domain services for a small subset of Azure workloads without building an on-premises footprint.
• Applications require standard group policy application or service account management within a secure virtual network.

Choose custom IaaS domain controllers when:

• Your legacy applications require LDAP write access or demand modifications to the Active Directory schema.
• Your enterprise architecture requires complex multi-domain forests, custom trust configurations, or direct access to domain controller operating systems.
• Your security team mandates full administrative control, including Enterprise Admin privileges and direct deployment of specialized directory auditing tools.

Conclusion and Next Steps

Designing a robust identity architecture in Azure requires matching each workload with the exact authentication model it needs. While modern cloud applications leverage Microsoft Entra ID for secure, token-based single sign-on and multi-factor authentication, legacy workloads often require traditional Windows domain services. Deciding whether to deploy managed cloud services or build your own IaaS infrastructure dictates your team's ongoing operational workload.

To explore this topic further and hear expert insights on modern workplace security, cloud architecture, and Microsoft 365 strategies, listen to the complete discussion on the podcast. Listen to the full episode to dive deeper into Microsoft identity management.