Most enterprise environments I've worked in have the same identity architecture: on-premises Active Directory as the authoritative source of truth, Azure AD (now Entra ID) as a cloud extension, and Azure AD Connect synchronizing the two. It works. But it's a hybrid model designed for a transition period that, for many organizations, has quietly become permanent.
Microsoft's rebranding of Azure AD to Entra ID signals something more strategic than a name change. It's the beginning of a posture where cloud-native identity — not on-premises AD — is the primary model. Understanding this shift matters for any organization planning its identity roadmap over the next few years.
What Changed Beyond the Name
The Entra suite now encompasses a broader set of identity and access services that go well beyond the original Azure AD scope. Microsoft Entra ID is the core directory, but it's now positioned alongside Entra External ID (for customer/partner identities), Entra ID Governance (for access lifecycle management), and Entra Verified ID (for decentralized identity credentials).
The practical implication: Microsoft is pushing organizations toward a model where all identity decisions — authentication, authorization, access reviews, lifecycle — happen in the cloud, not on a domain controller in a server room.
The On-Premises AD Problem
On-premises Active Directory was designed in 1999 for a world where the perimeter was the network edge and users sat inside that perimeter. Every security model built on top of AD assumes this: that being on the network means being trusted, that a domain-joined machine is a controlled machine, and that Kerberos tickets are the primary authentication token.
None of those assumptions hold in a modern enterprise with remote workers, SaaS applications, and BYOD policies. And yet, most organizations still have tens of thousands of objects in on-premises AD because migrating away from it is genuinely difficult — Group Policy, legacy application authentication dependencies, and printer drivers don't migrate themselves.
"On-premises AD is often the last piece of legacy infrastructure to go, precisely because everything else still depends on it."
Practical Migration Path
Phase 1: Enforce MFA across all users
This should be done regardless of any migration plans. Microsoft's telemetry consistently shows that over 99% of compromised accounts don't use MFA. Conditional Access policies in Entra ID allow you to require MFA based on risk signals — user location, device compliance, sign-in risk — without enforcing it uniformly for every low-risk login. Start here.
Phase 2: Move authentication to Entra ID for cloud apps
Any SaaS application that supports SAML or OIDC should authenticate against Entra ID directly, not through an on-premises federation server. This removes ADFS from the critical path for cloud authentication, which is one of the more fragile dependencies in hybrid environments.
Phase 3: Device identity modernization
Hybrid Azure AD join (where devices are domain-joined on-premises and registered in Azure AD) is the current standard for most organizations. The end state Microsoft is pushing toward is Entra-joined devices only — no on-premises domain join. This is achievable for new devices and for organizations that can validate their application portfolio supports it. For legacy environments, hybrid join remains the pragmatic middle ground.
Phase 4: Application authentication migration
Legacy applications that use NTLM or Kerberos for authentication are the hardest part of any AD migration. These can't just be pointed at Entra ID. The options are: migrate the application to support modern auth, use Azure AD Application Proxy to broker authentication, or maintain on-premises AD indefinitely for that application. The third option is often the reality.
What Entra ID Does Better Than On-Premises AD
Identity Protection in Entra ID provides risk-based signals that on-premises AD simply cannot offer. Sign-in risk scores, user risk scores, and leaked credential detection feed into Conditional Access policies automatically. If a user's credentials appear in a dark web breach database, Entra ID can require a password reset before the next sign-in — no SIEM correlation rule required.
Access reviews in Entra ID Governance allow you to automate the periodic certification of group memberships and application assignments. In a typical on-premises environment, access reviews are a spreadsheet exercise done once a year before an audit. With Entra ID Governance, they can be continuous and automated.
What to Watch For
Entra ID's licensing model is tiered — many of the features that matter most (Conditional Access, Identity Protection, Privileged Identity Management) require Entra ID P2, which is included in Microsoft 365 E5 but not in lower SKUs. Before planning a migration, confirm what's actually licensed in your tenant.
Also: the Entra admin portal and PowerShell modules are still evolving. Some operations that were straightforward in on-premises AD require more steps in Entra ID, and documentation sometimes lags behind feature changes. Build time into any migration project for this.
Key Takeaways
- The Entra rename signals Microsoft's direction: cloud-native identity is the destination, not a supplement
- Enforce MFA via Conditional Access before anything else — it's the highest-impact single change
- Move SaaS app authentication to Entra ID directly; remove ADFS from the path where possible
- Legacy applications with NTLM/Kerberos dependencies are the real migration blocker — audit these early
- Confirm P2 licensing before planning features like Identity Protection and PIM