Moving from Active Directory to Microsoft Entra ID rarely means switching off your domain controllers and shifting every identity function to the cloud at once. Users and groups may be ready for cloud-based management while an older business application still depends on Kerberos or Lightweight Directory Access Protocol (LDAP). New devices may be suitable for Entra join while existing endpoints continue to rely on Group Policy.
Microsoft’s cloud transformation model reflects this reality. User and group identities can move toward Entra ID on their own track. Applications follow a separate track, and devices follow another, each progressing at whatever pace its readiness allows.
This means an organization does not need to eliminate every Active Directory dependency before it starts moving. It needs to understand which dependencies remain and whether each one still has a reason to exist.
The more useful question is therefore how much of your identity environment is ready for Entra ID today, and what would prevent the rest from following. This article examines those readiness decisions and shows how to sequence a migration without forcing an organization into a cloud-only model before its environment can support it.
What Does Migrating From Active Directory to Entra ID Actually Mean?
Migrating from Active Directory to Entra ID does not mean copying an on-premises directory into an equivalent cloud directory. The two platforms handle identity differently, so several traditional AD capabilities have no direct Entra ID equivalent.
A migration instead moves specific identity workloads away from their dependence on Active Directory, whether that means shifting application authentication to Entra ID, managing new devices through Entra ID and Intune, or making Entra ID authoritative for selected users and groups.
These changes can happen independently because Microsoft treats users and groups, applications, and devices as separate cloud-transformation tracks, each able to progress at its own pace rather than converging on a single cutover date.
Active Directory can remain in place for applications or infrastructure that still require it, while Entra ID becomes the default for workloads that are ready to move. The eventual destination may be cloud-only, though it does not have to be. An AD-minimized environment can serve as an intentional target instead, provided the remaining dependencies have a genuine reason to exist.
When Does Moving to Entra ID Make Sense?
Moving more identity management to Entra ID makes sense when the organization’s technology environment is already becoming cloud-first while its identity model remains tied to Active Directory.
Microsoft 365 is a strong indicator. Organizations already running services such as Exchange Online and Teams operate an Entra tenant by default, so migration can extend an identity platform already in place rather than introduce another. The case becomes stronger when new SaaS applications can authenticate directly through Entra ID and new endpoints can use Entra join with Intune for cloud-based management.
A broader Microsoft-first strategy is often the deciding factor. When an organization has already committed to Microsoft across its productivity, security, and infrastructure stack, that existing Microsoft investment can strengthen the business case for consolidating more identity functions in Entra ID. Licensing also plays a supporting role here. Consolidating identity and security tooling under Entra ID reduces the overhead of running a separate identity platform alongside a Microsoft-native one, and that consolidation compounds with the operational gain of managing conditional access, provisioning, and device policy from a single platform rather than coordinating across two.
Existing AD dependencies should still be examined individually rather than treated as a single blocker. A production application that requires Kerberos justifies retaining the supporting AD capability. A process that creates every new employee in AD simply because that is how it has always been done does not carry the same justification.
The goal is to stop making AD the default the moment Entra ID can already support the workload, not to remove Active Directory for its own sake.
How Do You Know Whether You Are Ready to Migrate to Entra ID?
An Entra ID readiness assessment should identify where Active Directory remains necessary, not just catalog the environment. Four areas usually provide a useful starting point.
Identity readiness: Determine where users and groups are created and which systems still treat AD as their source of authority. Review provisioning processes and attribute dependencies to identify what would break if an identity were managed directly from Entra ID.
Application readiness: Identify applications that still rely on Lightweight Directory Access Protocol (LDAP), Kerberos, NT LAN Manager (NTLM), or other AD-dependent authentication. Applications already using Security Assertion Markup Language (SAML), OpenID Connect, or Open Authorization (OAuth) tend to have a more direct path to Entra ID.
Device readiness: Establish which endpoints still depend on domain join, Group Policy, or other domain services, then determine which policies and management functions can move to Entra ID and Intune before the device identity model itself changes.
Operational readiness: Assess whether the IT team can operate the target environment after migration, with defined owners for conditional access, privileged role administration, emergency access, and joiner-leaver processes. This is also where most of the real migration risk sits. What causes problems is the process around it: how you handle dependencies on the previous authentication model, how you sequence the cutover, and whether users are prepared for an authentication experience that differs from what they are used to. Taking operational readiness as seriously as the technical assessment keeps a migration from stalling mid-cutover.
Does Everything Need to Be Ready Before You Migrate?
Your entire environment does not need to be ready before you begin moving workloads to Entra ID.
Microsoft treats users and groups, applications, and devices as separate transformation areas, each able to progress toward cloud management at a different rate. An organization might move new devices to Entra join while existing devices remain domain joined. SaaS applications can authenticate through Entra ID while a line-of-business application continues using Kerberos against Active Directory.
The readiness assessment should determine which workloads can move safely now and isolate those that require additional work. A legacy application that needs remediation should change the migration sequence rather than stop it outright.
This phased approach also prevents the organization from forcing unnecessary changes merely to reach an arbitrary cloud-only deadline. The migration can continue while the organization addresses known AD dependencies separately.
When Does a Hybrid Entra ID and Active Directory Model Still Make Sense?
A hybrid identity model still makes sense when specific workloads have a documented requirement for Active Directory. An application may depend on Kerberos or LDAP, or an infrastructure workload may still require traditional domain services. In these cases, keeping the necessary AD capability can be preferable to forcing a migration that adds complexity without solving a business problem.
The important distinction is whether the hybrid architecture is intentional. IT should be able to identify which workloads still depend on AD and explain why each dependency remains, rather than defaulting to hybrid because no one has revisited the question.
This also changes Active Directory’s role within the environment. Rather than remaining the default identity platform for every new user, application, or device, AD can support defined exceptions while Entra ID becomes the default for workloads that no longer require traditional domain services.
For some organizations, an AD-minimized environment is therefore the appropriate target state rather than complete retirement.
How to Approach Entra ID Migration
A structured approach makes the difference between a migration that stalls halfway and one that steadily shrinks Active Directory’s footprint on its own terms. The steps below build on each other, starting with defining what the migration is actually meant to achieve.
1) Define the Target State
Start by defining the target identity state using the dependencies identified during the readiness assessment. This determines whether the immediate objective is a more controlled hybrid environment, an AD-minimized model, or eventual cloud-only identity.
2) Stop Creating New AD Dependencies
Stop creating unnecessary AD dependencies while the assessment is underway. New applications and devices that can operate directly with Entra ID should not automatically inherit the legacy identity model simply because that has been the default path.
3) Start With a Pilot
Begin migration with workloads whose dependencies are understood and whose access requirements can be reproduced in Entra ID. A limited pilot group works well here, validating authentication, application access, and the administrative processes that support those users before scaling further.
4) Expand in Controlled Waves
Expand once the pilot behaves as expected, keeping workloads that require remediation in Active Directory while addressing their dependencies separately.
5) Validate Before Decommissioning
Validate each migration wave before removing the corresponding legacy configuration. Users should still receive the correct access, provisioning should continue to work, and administrators should be able to recover from authentication failures through the intended Entra ID processes rather than falling back on undocumented workarounds.
Active Directory should shrink as those dependencies disappear, rather than being switched off according to a predetermined migration date.
How to Know When the Entra ID Migration Is Complete
Migration is complete when the workloads included in the agreed scope can operate through Entra ID without relying on the Active Directory processes they were intended to replace.
Successful sign-in alone does not establish that. Users should receive the correct application access, identity provisioning and deprovisioning should work as intended, and administrators should manage access without falling back on undocumented legacy processes.
The same test applies to applications and devices. Once a workload no longer depends on AD for the identity function being migrated, the corresponding legacy configuration can be removed.
Complete Active Directory retirement is a separate decision. An organization targeting an AD-minimized environment may retain domain controllers for a small number of documented dependencies while Entra ID handles the rest of the identity environment.
The migration should finish against defined acceptance criteria, not simply when the last planned wave is complete.
Conclusion
The complexity of an Entra ID migration depends less on how many employees an organization has than on how many business processes still depend on Active Directory. A 2,000-user organization running Microsoft 365, modern SaaS applications, and Intune-managed endpoints may have a relatively direct path toward Entra ID. A smaller environment with custom authentication, domain-dependent applications, and extensive Group Policy can require considerably more preparation.
Planning a migration should begin by establishing where those dependencies exist and which ones still have a reason to remain. This should give you a clear view of which Active Directory dependencies are safe to move now and which require more work first, and help you build a migration sequence that matches your actual environment.
To get started, review our Active Directory to Entra ID migration guide, or complete this quick form to have one of our migration specialists reach out.
