This post examines whether an organization running Active Directory on-premises can retire it and move to cloud-only identity in Microsoft Entra ID. It covers the three end states the question usually means, why Microsoft 365 adoption places an organization at the start of Microsoft’s transformation model rather than the end of it, the dependency categories that keep Active Directory running, which workloads have a documented cloud alternative and which do not, and an honest assessment of who can complete full retirement and who cannot. Account and privilege cleanup in a hybrid environment is covered in a separate post.
What retiring Active Directory actually means
Three different end states are described with the same phrase, and projects are frequently budgeted against one while arriving at another.
The first is cloud-only identity with no on-premises directory, which Microsoft describes as its fifth transformation state. The second is replacing self-managed Active Directory with Microsoft Entra Domain Services for workloads that still require directory protocols. The third is a reduced Active Directory that continues to serve exceptions while user authentication moves to Entra ID, which Microsoft describes as its fourth state.
In the environments we assess, projects scoped as full retirement commonly arrive at the reduced state instead. The cost is an unplanned second phase and a delivery date that moves after the budget is set.
Microsoft’s documentation states that transformation from Active Directory to Microsoft Entra ID is typically a multi-year effort with multiple states in enterprise-sized organizations, and that the Active Directory minimized state is more difficult to achieve for larger organizations with significant on-premises technical debt.
Microsoft also states that organizations might decide not to migrate some capability to Microsoft Entra ID and leave it in place. Full retirement is presented as one possible outcome rather than the expected one.
Microsoft Entra Domain Services is worth understanding correctly, because it is sometimes mistaken for cloud-only identity. Microsoft’s documentation describes it as providing a smaller subset of traditional Active Directory features. Domain and Enterprise Admin rights are not available, schema extensions are not supported, and constrained delegation is resource-based only. It is a managed domain rather than the absence of one.
Have the organization choose a target state in writing before any work is scoped, and treat full retirement as conditional on what the dependency assessment finds.
Why Microsoft 365 adoption is the starting point, not the finish line
A common position is that moving email to Microsoft 365 removes the need for Active Directory. Microsoft’s own model places that organization at the first of five states rather than near the last.
An organization that treats Microsoft 365 adoption as readiness skips the dependency inventory. The dependencies then surface during cutover, which is the most expensive point at which to find them.
Microsoft’s documentation describes State 1 as cloud attached, meaning the organization has created a Microsoft Entra tenant to enable productivity and collaboration tools. In that same state, devices are joined to Active Directory and managed through Group Policy, and apps are authenticated to Active Directory and to federation servers.
Microsoft also states that most companies using Microsoft products are already in or beyond this state, and that Active Directory and Microsoft Entra ID are separate products without like-for-like features. The example Microsoft gives is that Microsoft Entra ID does not have the notion of Active Directory domain and forest trusts.
What Microsoft 365 establishes is a tenant, cloud sign-in for Exchange Online, SharePoint, OneDrive, and Teams, and usually synchronized identities. What it does not establish is a cloud source of authority for users and groups, a cloud identity for existing PCs, Kerberos or LDAP services for line-of-business applications, computer accounts for servers, a replacement for Group Policy, or certificates for servers.
Several of Microsoft’s own bridging technologies also keep Active Directory running underneath them. Application Proxy single sign-on to Kerberos applications requires that both the connector server and the application server are domain joined. Cloud Kerberos trust requires an adequate number of read-write domain controllers in each Active Directory site.
Begin with an application inventory. Microsoft’s guidance states that an application inventory should always come before transferring the source of authority for users.
Dependencies are cheapest to find before cutover, not during it.
We can run the application and dependency inventory for you and tell you which target state your environment can realistically reach.
The dependencies that keep Active Directory running
The blockers are specific and documented rather than general. They fall into categories, and each category has a different answer.
Servers determine whether Active Directory can be retired at all. Devices determine when. In the assessments we deliver, the dependencies clients most often overlook are network appliances and line-of-business applications that bind over LDAP, and print services, both of which are noticed by users immediately when they break.
Applications using Kerberos or NTLM. Microsoft’s bridge is Application Proxy or Private Access with Kerberos constrained delegation, which requires an Active Directory account for each user and domain-joined servers. The authentication front end modernizes while Active Directory remains. Application Proxy requires Microsoft Entra ID P1 or P2.
Applications using LDAP. Microsoft Entra ID is not an LDAP directory. Microsoft’s recommended solution is Entra Domain Services, which provides LDAP, Kerberos, and NTLM endpoints and mainly supports read and authentication for LDAP clients. Applications that write over LDAP or depend on schema extensions are described by Microsoft as out of scope, and might have to remain on Active Directory until they are retired.
File services. Microsoft lists SharePoint, OneDrive, and Azure Files as the replacements. Azure Files with Entra Kerberos for cloud-only identities reached general availability on 19 May 2026, and Microsoft states that for cloud-only users Azure file shares no longer need a domain controller for authorization or authentication. The documented conditions matter: Azure Public cloud only, specific Windows 11 or Windows Server 2025 builds, one identity source per storage account, and permission management for cloud-only identities is not currently supported through File Explorer.
Group Policy. Settings migrate individually rather than as a block. Group Policy analytics reports an MDM support percentage, and Microsoft states that a setting marked not supported has no matching Intune setting. Microsoft also states the tool supports non-ADMX settings in English only, so the percentage is inaccurate for other languages.
Certificates. Microsoft Cloud PKI issues to Intune-enrolled devices supporting the SCEP profile and requires a subscription in addition to Intune Plan 1 or Plan 2. Certificates for domain controllers and servers fall outside that scope, so a certificate authority is still required for them.
Devices. Microsoft states that existing devices joined to an on-premises domain, including hybrid joined devices, must be reset to become Microsoft Entra joined, and that Microsoft does not have a migration utility for the conversion. Windows Autopilot Reset does not support hybrid joined devices.
Service accounts. Group managed service accounts rely on Active Directory for automatic password management. Domain Services supports them, and the cloud alternative for re-platformed workloads is managed identities, which carry no additional licensing requirement. A managed identity replaces a group managed service account only once the workload has been changed to call Entra-protected resources.
NTLM-dependent applications. Microsoft has stated that network NTLM will be disabled by default in the next major Windows Server release, with re-enablement possible by policy. This makes NTLM-only applications a priority rather than a later item.
Classify every application as modernize, bridge, host on Domain Services, or retire. Record the fate of each server, each certificate template by consumer, and each group managed service account by the resource it authenticates to. Put NTLM-only applications first.
What moves cleanly, and what does not
Each workload has either a documented cloud alternative with stated conditions, or no clean path. Treating the two the same is what produces the mid-project discovery.
The right column below is what determines whether a target state is achievable and what the project will cost. It is also the part most commonly left out of a business case.
| Moves cleanly, with conditions stated | Needs a rebuild, a replacement product, or a decision to keep Active Directory |
| Sign-in to Exchange Online, SharePoint, OneDrive, and Teams | Recipient and group management while on-premises Exchange remains, which blocks transferring user source of authority |
| SAML and OIDC applications, including those moved off AD FS | Kerberos and NTLM web applications, where the bridge requires domain-joined servers and an Active Directory account per user |
| New Windows PCs through Entra join, Intune, and Autopilot | Existing domain-joined and hybrid-joined PCs, which must be reset, with no Microsoft migration utility |
| Group Policy settings marked as MDM supported, rebuilt in the settings catalog | Settings marked not supported, drive and printer mappings, and machine-account based access |
| Files in SharePoint and OneDrive, or Azure Files with Entra Kerberos on supported builds in the Azure Public cloud | On-premises file servers, sovereign cloud tenants, and File Explorer permission management for cloud-only identities |
| Printing through Universal Print, with the connector for printers that are not ready | Print features outside Universal Print, where parity is not documented |
| Certificates for Intune-enrolled devices through Cloud PKI | Domain controller, server, and network device certificates, which require another certificate authority |
| Azure-hosted and Arc-enabled service authentication through managed identities | Group managed service accounts supporting on-premises services |
| Users with no Active Directory application dependencies, through user source of authority transfer | Password-dependent and AD FS-federated users, where Microsoft states source of authority transfer is not supported |
| Not applicable | Forest and domain trusts, applications that write over LDAP or need schema extensions, and disconnected environments that Microsoft states need to stay on-premises |
On a phone, scroll the table sideways to see both columns.
Build the business case from the right column rather than the left. The left column is largely a configuration exercise. The right column is where the budget and the timeline are decided.
An honest answer to the question
The question in the title has a real answer, and for most established organizations it is a qualified one.
A project sold as full retirement that delivers a reduced Active Directory is a credibility problem as well as a budget problem. Setting the expected outcome at the start is cheaper than revising it mid-delivery.
Full retirement is achievable where the assessment clears every blocker. In practice that means no on-premises Exchange, no password-dependent or federated users, Kerberos applications that can be modernized, no applications writing over LDAP or requiring schema extensions, files that fit within the Azure Files conditions, printers compatible with Universal Print, certificates needed only for Intune-managed devices, and a device estate that can be reset within a refresh cycle.
Microsoft’s guidance distinguishes two starting points. For organizations formed in Microsoft Entra rather than in Active Directory, a fully cloud state can happen as the new IT environment is established. For organizations with an established on-premises capability, Microsoft states that the transformation introduces complexity requiring careful planning.
Microsoft’s own description of the reduced state is that Microsoft Entra ID provides most identity capability while edge cases and exceptions continue to use on-premises Active Directory. Microsoft states that organizations typically spend the most time in the cloud-first state, which sits before that one.
No reliable published figure exists for how many organizations complete full retirement, so any percentage would be invented.
Run the dependency assessment first and choose the target state from what it returns. Stop adding new dependencies in the meantime. Microsoft recommends updating change approval to evaluate whether a proposed change would add new dependencies on Active Directory, requiring Entra join for new devices, and requiring modern authentication protocols for new applications.
WME runs Active Directory dependency assessments covering applications, devices, file and print services, certificates, Group Policy, servers, and service accounts, with a written target state and a phased plan.
Choose the target state from what the assessment returns, not from the budget.
WME runs Active Directory dependency assessments with a written target state and a phased plan.
