An Active Directory to Entra ID migration moves the source of authority for users, groups, devices and applications from on-premises domain controllers to Microsoft Entra ID, one workload at a time. Microsoft's own road to the cloud guidance describes three states on the way: cloud-first, Active Directory minimization and cloud-only. Most organizations spend a year or more in the middle state, and the plan works best when each workload has a named target and a test before it moves.
At a glance
- Starting point: on-premises Active Directory as the source of truth, synced to Entra ID with Entra Connect Sync or Entra Cloud Sync
- Cloud-first: new users, groups, devices and apps start in Entra ID
- AD minimization: existing groups and users convert to cloud-managed through source of authority conversion; devices move to Entra join and Intune
- Cloud-only: domain controllers retired, or kept only for workloads that cannot move
- What usually holds AD in place: Kerberos and LDAP applications, Group Policy, file servers, servers joined to the domain and the HR provisioning flow
- Audit value: one identity record per person, with provisioning and sign-in logs for SOC 2 CC6.1 and CC6.2 and ISO 27001 A.5.16
Why organizations move identity from Active Directory to Entra ID
Organizations retire on-premises Active Directory to remove domain controllers they must patch, back up and defend, and to put every sign-in behind the same Conditional Access policies. Domain controllers are a high-value target in ransomware incidents, and every one that is retired removes a system that needs tier 0 protection.
The trigger varies. Some organizations reach a hardware or Windows Server refresh and prefer to spend the money on the move. Some are replacing Microsoft Identity Manager before its January 9, 2029 end of support, covered in the MIM end of life guide. We also see organizations that run Google Workspace for email and collaboration and keep an on-premises Active Directory for Windows sign-in and older applications. For them, Entra ID becomes the central identity platform and the identity provider for Google Workspace, and the on-premises directory is retired.
The three states of an Active Directory to Entra ID migration
Microsoft describes the migration as a progression through three states. Each state has a clear test for when it is complete.
| State | What changes | Complete when |
| Cloud-first | New users, groups, devices and applications are created in Entra ID. Active Directory keeps serving what already depends on it | No new object is created in Active Directory unless a documented workload requires it |
| AD minimization | Existing groups and users convert to cloud-managed objects. Windows devices move to Entra join and Intune. Applications move to modern authentication | Active Directory serves only a short, named list of workloads |
| Cloud-only | Domain controllers retired. Remaining legacy workloads use Entra Domain Services or are replaced | No domain controller is left in production |
The cloud-first state is a policy decision and costs little. The AD minimization state holds most of the work, since each application, device group and file share has to be moved and tested.
Source of authority conversion for users and groups
Source of authority decides whether an object is managed in Active Directory or in Entra ID. A synced user or group is mastered on-premises, and changes made in Entra ID are overwritten on the next sync cycle. Converting the source of authority makes the object cloud-managed while keeping its identity, group memberships and application assignments.
Microsoft's guidance for IT architects on source of authority recommends starting with groups: security groups and the applications that depend on them, then users. Groups that are still needed in Active Directory for an on-premises application can be provisioned back to Active Directory from Entra ID, so the application keeps working while the group is managed in the cloud.
The order we follow in identity engagements:
- Groups used only by cloud applications. Convert these first, since no on-premises system reads them.
- Groups used by on-premises applications. Convert and provision back to Active Directory, then confirm the application still resolves membership.
- Users whose access is fully cloud. Staff who sign in to Entra-joined devices and use cloud applications only.
- Remaining users, after the applications and devices they depend on have moved.
The HR provisioning flow moves at the same time. When Workday, SAP SuccessFactors or another HR system provisions directly to Entra ID, new hires are cloud-managed from the first day. The guide to HR-driven provisioning in Entra ID covers the connectors and the joiner, mover and leaver design.
Applications that depend on Active Directory
Applications decide how long Active Directory stays in production. An inventory of every application that authenticates against a domain controller, by protocol, is the first deliverable of an AD retirement plan.
| Application type | Typical target in Entra ID |
| SaaS applications federated through AD FS | SAML or OpenID Connect single sign-on in Entra ID, then retire AD FS |
| Internal web applications using Kerberos or header-based authentication | Entra application proxy or Entra Private Access, with Kerberos constrained delegation during the transition |
| Applications that bind to LDAP | Modern authentication where the vendor supports it; Entra Domain Services or a replacement where it does not |
| Google Workspace | Entra ID as the identity provider through SAML single sign-on, with user provisioning from Entra ID to Google |
| Line-of-business apps with hard-coded domain accounts | Rebuild, replace, or keep in a small residual domain with a retirement date |
Microsoft Entra Domain Services offers a managed domain with Kerberos, NTLM and LDAP for workloads that cannot move to modern authentication. It suits a short list of legacy applications and servers, and it needs its own design for network placement and administrator access.
Windows devices, Group Policy and file servers
Windows devices move from domain join to Entra join, with Intune replacing Group Policy for configuration. Hybrid join is a common intermediate step, and it keeps devices tied to the domain, so the end state for each device group is Entra join.
Three pieces of work recur in this phase:
- Group Policy to Intune. Export the Group Policy objects, map each setting to an Intune configuration profile or settings catalog entry, and retire the settings no one needs. Many estates carry policies for software and settings that are long gone.
- Windows Hello for Business with cloud Kerberos trust. Entra-joined devices can still reach on-premises file shares and applications that use Kerberos while those resources remain, which lets device migration go ahead of server migration.
- File servers. Move team shares to SharePoint and OneDrive, or to Azure Files with identity-based access, and keep a read-only archive with a retention date for the rest.
Servers joined to the domain take the longest. Each one needs an owner, a decision (rebuild, replace, move to Entra Domain Services or retire) and a date.
Entra Connect Sync or Entra Cloud Sync during the migration
Most organizations keep a sync engine running throughout the AD minimization state. Microsoft's Cloud Sync overview compares the two: Entra Cloud Sync uses lightweight agents managed from the cloud and supports multiple disconnected forests, while Entra Connect Sync is a full server installation with more customization options.
For a migration whose goal is to retire Active Directory, Cloud Sync tends to suit better, since the agents are simple to remove when the last domain controller goes. Estates that rely on Connect Sync features Cloud Sync lacks, such as some custom sync rules or device writeback scenarios, stay on Connect Sync until those features are no longer needed. Either way, the sync server or agent host is a tier 0 system and needs the same protection as a domain controller.
Key insight
Inventory the protocols before moving the people.
Users and groups move quickly once the applications and devices they depend on are ready. A sign-in log review of every Kerberos, NTLM and LDAP dependency, taken over a full business cycle, sets the real timeline for retiring Active Directory.
Security controls to put in place before Active Directory is retired
Moving the source of truth to Entra ID moves the attack surface with it. Four controls belong in the plan before the AD minimization state begins:
- Conditional Access as the single access policy. Every sign-in, including Google Workspace and on-premises applications published through application proxy, goes through the same policies.
- Phishing-resistant MFA. Passkeys or Windows Hello for Business for staff, and for administrators first. The guide to phishing-resistant MFA in Entra ID covers the rollout.
- Privileged Identity Management. Administrator roles granted just in time, with approval and expiry, and two emergency access accounts excluded from Conditional Access and monitored.
- Log retention. Sign-in, audit and provisioning logs forwarded to the central log store for the full audit period.
How the migration supports SOC 2 and ISO 27001
A single identity platform gives auditors one place to test logical access. SOC 2 CC6.1 covers logical access security, described in the SOC 2 CC6.1 guide, and CC6.2 covers provisioning and removal. ISO 27001 A.5.16 covers identity management, described in the ISO 27001 A.5.16 guide, and A.8.5 covers secure authentication.
During the migration, two directories hold identity records, and the audit sample has to cover both. Keeping a reconciliation report of Active Directory accounts against Entra ID and HR records, run monthly, gives the auditor a clean population and shows that accounts without an owner are found and removed.
Practical steps to start an Active Directory to Entra ID migration
- Declare cloud-first. New users, groups and applications are created in Entra ID from a set date.
- Inventory dependencies. Applications by authentication protocol, Group Policy objects, file shares and servers joined to the domain, each with an owner.
- Choose the sync engine for the migration period and protect its host as tier 0.
- Set the security baseline: Conditional Access, phishing-resistant MFA for administrators, Privileged Identity Management and log forwarding.
- Convert groups, then users, starting with those used only by cloud applications.
- Move devices to Entra join and Intune by department, with cloud Kerberos trust for remaining on-premises resources.
- Retire domain controllers once the residual workload list is empty or moved to Entra Domain Services.
The guide to centralizing identity in hybrid estates covers the design decisions before the migration starts, such as which directory is the source of truth for each population.
Retiring Active Directory works best one workload at a time
An Active Directory to Entra ID migration moves through cloud-first, AD minimization and cloud-only states, and the applications and devices that depend on domain controllers set the pace. Organizations that inventory every protocol dependency, convert groups before users and put Conditional Access and phishing-resistant MFA in place first can retire their domain controllers on a planned date.
Planning to retire on-premises Active Directory? Truvo's identity architects inventory the applications, devices and groups that depend on it, design the Entra ID target and move each workload with a tested rollback. See Microsoft Entra ID consulting or book a strategy call.
Retire Active Directory on schedule
We move each workload to Entra ID as part of an effective security program, with a tested rollback.
Frequently asked questions
Can on-premises Active Directory be fully replaced by Microsoft Entra ID?
For many organizations, yes. Users, groups, Windows devices and modern applications can all be managed in Entra ID with Intune. Applications that need Kerberos, NTLM or LDAP either move to modern authentication, use Microsoft Entra Domain Services, or stay in a small residual domain until they are replaced.
How long does an Active Directory to Entra ID migration take?
The timeline depends on the number of applications and servers that depend on domain controllers. Users and groups can move in weeks once their applications are ready. Device migration and legacy applications usually take months, and many organizations plan for a year or more in the AD minimization state.
What is source of authority conversion in Entra ID?
Source of authority conversion changes a user or group synced from Active Directory into a cloud-managed object in Entra ID, keeping its identity, memberships and application assignments. After conversion, changes are made in Entra ID, and the object can be provisioned back to Active Directory if an on-premises application still needs it.
Should we use Entra Connect Sync or Entra Cloud Sync?
Entra Cloud Sync uses lightweight agents managed from the cloud and is simpler to remove when Active Directory is retired. Entra Connect Sync offers more customization. Organizations that rely on Connect Sync features Cloud Sync lacks stay on Connect Sync until those features are no longer needed.
Can Entra ID be the identity provider for Google Workspace?
Yes. Entra ID supports SAML single sign-on to Google Workspace and automatic user provisioning from Entra ID to Google. Users sign in with their Entra ID account, and Conditional Access applies to Google Workspace sign-ins the same way it applies to Microsoft 365.
Sources
- Microsoft Learn, Road to the cloud: Introduction (cloud-first, AD minimization and cloud-only states)
- Microsoft Learn, Guidance for IT architects on shifting the source of authority for users and groups
- Microsoft Learn, Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync comparison
- Microsoft Learn, Microsoft Entra Domain Services overview
- Microsoft Learn, Tutorial: Microsoft Entra SSO and user provisioning for Google Cloud / Google Workspace
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
Contact Us
Sample SOC 2 Control List
Input your email to download the list.
About the Author
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.