Entra ID migration means moving identity and application authentication from Active Directory and AD FS into Microsoft Entra ID, done in phases rather than all at once. The first move is simple: start an automated app inventory and pull together a cross-functional team, with sponsors from IT, security, and app owners, before you touch a single config. Phasing the work, discover, classify and pilot, plan and test, manage and decommission, cuts risk because you catch problems on a handful of apps instead of all of them at once.
TL;DR:
- Automated discovery tools and manual checks should be used together to identify all applications dependent on Active Directory Federation Services.
- The four key migration phases—discover and scope, classify and pilot, plan and test, manage and insights—must be completed sequentially with formal sign-offs at each stage.
- Password Hash Sync is recommended over Pass-Through Authentication unless organizational policies prohibit syncing password hashes to the cloud.
- Pilot testing should include a small, representative group of apps with clear success criteria, and thorough rollback plans must be prepared before cutover.
- Post-migration, organizations should verify all apps function correctly, monitor for failures, and update Conditional Access policies to align with the new environment.
Table of Contents
- Migration phases: a practical four-phase roadmap
- Discover and classify applications: inventory methods and prioritization
- Authentication and synchronization options: choosing the right combination
- Pilot, test and cutover: staged rollouts done safely
- Migrating Entra Connect to Cloud Sync: when and how
- Project governance, communications, and runbooks
- Decommissioning AD FS and post-migration verification
- Practical runbook snippets and lessons learned
- Security considerations and compliance impacts during migration
- User training and communication strategies during migration
- Performance monitoring and optimization after migration
- Why identity-first migrations pay off
- How Total Cyber Solutions supports your Entra ID migration
- Key Microsoft Learn documentation and Total Cyber resources
- Sources
- FAQ
Migration phases: a practical four-phase roadmap
Microsoft frames this as a four-phase migration process, and it holds up well in practice. Each phase has a job to do, and each one ends with something concrete you can point to, not just a feeling that things went fine.
Discover and scope is where you find every app that touches AD FS or legacy authentication. You are not migrating yet. You are building a list you can trust.
Classify and pilot sorts that list by protocol, business criticality, and complexity, then picks a small, low-risk group to move first.
Plan migration and test is the phase where you build the actual cutover steps for each app, test them against a non-production Entra tenant, and confirm sign-in, MFA, and Conditional Access all behave the way you expect.
Manage and insights covers what happens after cutover: monitoring, cleanup, and using what you learned to speed up the next wave of apps.
Moving from one phase to the next should require a real sign-off, not a verbal nod in a meeting.
- Discover: a complete, deduplicated app inventory with an owner assigned to each entry.
- Classify and pilot: a pilot group selected and success criteria written down before testing starts.
- Plan and test: test results showing SSO, MFA, and Conditional Access work as expected in a test tenant.
- Manage and insights: production apps confirmed working post-cutover, with monitoring in place.
Breaking the project into these stages does two things. It limits the blast radius when something goes wrong, and it gives sponsors and app owners a reason to trust the process, since they can see progress in discrete, testable steps instead of waiting months for a single cutover weekend.
Discover and classify applications: inventory methods and prioritization
You cannot migrate what you have not found. Most organizations underestimate how many applications quietly depend on AD FS or legacy Active Directory authentication, so pull from more than one source.
Automated discovery does the heavy lifting: AD FS activity reports, Entra’s own app discovery tooling, PowerShell scripts against your relying party trusts, proxy or CASB logs, and Microsoft Defender for Cloud Apps all surface apps that IT may not even know are still active. Microsoft’s discovery and scoping guidance includes tooling that flags which relying party apps are eligible for migration and which need extra work.
Manual discovery fills the gaps automation misses: talk to business owners, check portal access logs, and track down service accounts tied to apps still in development or on a roadmap. Those in-flight projects are easy to forget and painful to find later.
Once you have the list, classify each app using a simple rubric:
- Protocol type: SAML or OIDC apps are generally easier to move than Kerberos or NTLM-dependent apps.
- Business criticality: a finance system and an internal wiki do not belong in the same pilot wave.
- Owner and dependencies: know who to call and what else breaks if this app changes.
- Modernization cost versus deprecation: some apps are cheaper to retire than to migrate.
A workable pilot order starts with modern, low-risk SAML or OIDC apps, then moves to more complex legacy apps once you have a mitigation plan for their quirks.
Pro Tip: Include apps still in development in your inventory, since they will hit the same authentication requirements the day they launch.
Authentication and synchronization options: choosing the right combination
Picking an authentication method is less about preference and more about what your policies and licensing allow. Microsoft’s migration best practices lay out four main paths.
- Password Hash Sync (PHS): hashes sync to the cloud, sign-in works even if on-premises systems go down, and Microsoft recommends it over Pass-Through Authentication when policy allows.
- Pass-Through Authentication (PTA): validates credentials against on-premises Active Directory directly, useful when hash sync is not permitted.
- Certificate-based authentication (CBA): fits organizations with existing PKI investments and specific compliance requirements.
- Passwordless options, including FIDO2 security keys and Windows Hello for Business, remove passwords from the sign-in flow entirely.
Statistic Callout: Microsoft recommends Password Hash Sync over Pass-Through Authentication for most organizations unless policy specifically prevents syncing password hashes to the cloud. That guidance alone settles the decision for a large share of migrations before you even get to the harder edge cases.
On the sync side, Entra Connect remains the established tool, but Cloud Sync is Microsoft’s direction for new deployments, with lighter infrastructure and multi-forest support, though it currently has gaps around device sync and some group writeback scenarios.
Licensing shapes what is even on the table. Passwordless and advanced Conditional Access features often require Entra ID P1 or P2, so confirm licensing early rather than discovering a feature gap mid-pilot.
Pilot, test and cutover: staged rollouts done safely
A pilot only tells you something useful if it is designed to fail loudly in a controlled setting rather than quietly in production. Pick a small group, somewhere between a single team and a full department, and a handful of representative apps that span your protocol types.
- Define success criteria before you start: SSO works, MFA prompts appear correctly, and Conditional Access policies apply as intended.
- Stand up a test Entra tenant and route modern-auth apps to it, comparing behavior against the current AD FS setup, as Microsoft’s phased approach recommends.
- Capture SSO traffic with a tool like Fiddler and compare tokens and claims between the old and new flows to catch mapping issues early.
- Use Staged Rollout to test new sign-in methods with select groups, but Microsoft is clear that it should not be used for incremental, ongoing migration rather than testing.
Before cutting over any app to production, back up its current configuration, export your Entra Connect settings, and schedule the promotion for an off-peak window. Watch key event logs during and after the change, and know in advance what conditions trigger a rollback.
Pro Tip: Write your rollback trigger down before the cutover window opens, not while you are staring at an error log at 11 p.m.
Migrating Entra Connect to Cloud Sync: when and how
Cloud Sync makes sense when you need multi-forest support, want agent-level failover instead of a single sync server, or are building new identity infrastructure rather than maintaining an old one. It is not yet a full replacement for Connect in every scenario: device sync and some group writeback behaviors still have limits worth checking against your environment.
Before migrating, run through a readiness checklist:
- Object scale under roughly 150,000 and group sizes under 50,000, per Microsoft’s decision guide.
- Device management dependencies that might rely on Connect-specific behavior.
- Your current filtering approach and whether Cloud Sync supports an equivalent.
The stepwise process starts small: pick a pilot organizational unit, apply cloudNoFlow or joinNoFlow rules to prevent duplicate processing, install the provisioning agent, and verify objects sync correctly. Only then do you stop Connect for that scoped set of objects, verify again, and move to the next OU. Keep Connect running in parallel until every scoped group is confirmed, which gives you a clean rollback path if something in Cloud Sync behaves unexpectedly.
Project governance, communications, and runbooks
Technical work fails less often than organizational work does. Microsoft’s own guidance points to unclear ownership and weak communication as recurring causes of migration trouble, more so than any specific technical misstep.
Assign roles before the project starts: a project manager to track schedule and exit criteria, an identity architect to own technical decisions, app owners accountable for their own systems, and pilot users willing to report friction honestly.
A shared dashboard keeps everyone honest about where things actually stand. Track app status, pilot results, current phase, open blockers, and the next action for each item, so status meetings become five minutes instead of forty.
Communications do not need to be elaborate, but they do need to happen at each phase:
- Kickoff message to affected teams explaining what is changing and when.
- Pilot invitation to selected users with clear instructions on what to test and how to report issues.
- Cutover notice sent ahead of the change window, with a rollback contact listed.
- Post-migration summary confirming the change is complete and who to contact with problems.
Your runbook should capture configuration exports, the specific checks you run to confirm success, verification steps for each app, and an escalation contact list. Total Cyber’s tenant to tenant migration resources cover role definitions and templates that fit directly into this structure.
Pro Tip: Bake phase exit sign-offs into the project schedule itself, not as an afterthought once the technical work is done.
Decommissioning AD FS and post-migration verification
Retiring AD FS is safe only once every in-scope app is confirmed migrated and verified, not just moved.
- Confirm every relying party app has been migrated and tested, with no lingering dependencies on AD FS claims.
- Take AD FS offline in a soft, reversible way first, watching for any unexpected authentication failures during a short verification window.
- Once that window passes clean, proceed with a full uninstall.
- Tighten Conditional Access policies, complete any remaining MFA rollout, and turn on identity protection monitoring.
- Validate the end user experience directly, not just backend logs, since a working token exchange does not always mean a smooth sign-in for the person at the keyboard.
Common pitfalls include forgotten service accounts still pointed at AD FS and app owners who assumed migration was complete when only part of an integration moved.
Practical runbook snippets and lessons learned
A staging promotion runbook entry should read something like: confirm staging server sync is current, disable the old primary sync server, promote staging to active, monitor Event IDs 654 and 656 for password sync backlog, then confirm object counts match expectations. Microsoft’s guidance on Connect server upgrades recommends this swing migration pattern specifically to avoid accidental exports during an in-place upgrade.
A pilot validation checklist should confirm SSO succeeds, MFA prompts correctly, Conditional Access applies, and token claims match expectations across at least two representative apps.
The operational failure modes we see most often are not technical: stakeholder alignment slipping mid-project, apps with no clear owner sitting untested until the last minute, and testing that stops the moment SSO technically works without checking the full user journey. Each of those gets fixed the same way: name an owner, write the exit criteria down, and test past the happy path.
Security considerations and compliance impacts during migration
Migration is a window of change, and change is exactly when security gaps tend to open. Every app you move should keep its existing Conditional Access protections intact through the transition, not weakened temporarily to make testing easier.
Compliance frameworks like HIPAA, CMMC, or NIST often require documented access controls and audit trails. A migration that changes how authentication works needs its own record: what changed, when, who approved it, and how you verified it did not weaken existing controls. Total Cyber’s policy compliance work often starts exactly here, aligning a technical change like this with what an auditor will expect to see later.
Pay particular attention to service accounts and legacy protocols during the transition. NTLM and older Kerberos configurations sometimes get quietly re-enabled as a troubleshooting shortcut and never turned back off. Treat every temporary exception as something that needs an expiration date and a name attached to it.
Monitoring should not go dark during cutover either. If your Conditional Access policies or sign-in logs go unmonitored for even a few days around a migration event, that is the exact window an attacker would pick to test for weaknesses. Keep detection running through every phase, not just before and after.
User training and communication strategies during migration
People adapt to a new sign-in experience faster when they know it is coming and know what normal looks like. A short heads-up before pilot testing, explaining what will change and what to do if something looks off, prevents a flood of help desk tickets on day one.
Keep the message specific. Telling someone “you may see a new sign-in screen” is more useful than a general announcement about “IT changes happening soon.” Include a screenshot of the new experience where you can, and give a direct contact for problems rather than a generic ticket queue.
Timing matters as much as content. Send the pilot notice close enough to the actual change that people remember it, and follow up right after cutover to confirm things worked. Silence after a migration reads as either “nothing happened” or “something broke and nobody is telling us.” Neither is good.
For apps used across departments, loop in a point of contact from each affected team rather than broadcasting only through IT channels. That person can translate the technical change into what it means for their team’s actual workflow, which lands better than a generic company-wide email.
Performance monitoring and optimization after migration
Cutover is not the finish line. Sign-in latency, MFA prompt frequency, and Conditional Access policy behavior all deserve a few weeks of close attention after go-live, since some issues only surface under normal daily load rather than pilot conditions.
Watch sign-in logs for unexpected failure patterns, particularly around legacy apps that were harder to test fully before migration. A spike in failed authentications for one specific app usually points to a claim mapping issue or a stale configuration that pilot testing did not catch.
Once things stabilize, revisit your Conditional Access policies with fresh eyes. Migrations often carry over rules built for the old environment that no longer fit the new one, and cleaning those up reduces both risk and user friction. This is also the point to confirm monitoring and identity protection alerts are tuned correctly rather than generating noise nobody reads.
Why identity-first migrations pay off
Most migration guidance treats authentication as a technical checkbox to clear on the way to a bigger goal. I think that gets the priority backwards. Identity is the front door to everything else in your environment, so a migration that treats it as an afterthought tends to leave gaps that show up as security incidents months later, not migration failures.
The organizations that come out of an Entra ID migration in better shape are the ones that build runbook discipline into every phase, not just the cutover weekend. That discipline is what turns into measurable uptime and fewer surprise access issues down the road.
If you are weighing whether your organization is ready for this, a proper migration assessment is worth the time before you touch a single sync setting.
— Alden
How Total Cyber Solutions supports your Entra ID migration
Planning, piloting, staging, and cutover each take real time and attention that most internal IT teams are already stretched thin on. Total Cyber Solutions handles the full migration process, from initial app discovery through post-migration hardening, so your team is not learning Cloud Sync decision criteria in the middle of a production change window.
That means less downtime during cutover, a tested rollback plan instead of a hope, and a migration record that lines up with whatever compliance framework you answer to. Our managed IT services cover the migration itself and the ongoing operational support after it, and our managed cybersecurity services keep monitoring and identity protection running through the transition and beyond.
If you want a second set of eyes on your migration plan or a full-service engagement, request a discovery call and we will walk through where your environment stands today.
Key Microsoft Learn documentation and Total Cyber resources
Start with Microsoft’s migration phases guide and Cloud Sync decision guide, then review Total Cyber’s Microsoft 365 migration runbook for governance templates.
FAQ
How do you migrate from Active Directory to Entra ID?
Migration follows a phased process: discover and inventory apps, classify and pilot a small group, plan and test each app against a test tenant, then manage and monitor after cutover. Microsoft’s migration phases documentation outlines this four-phase structure in detail.
Is Microsoft moving away from Active Directory?
Microsoft has positioned Entra ID as its strategic direction for identity and access management, with Cloud Sync recommended over older sync tools for new deployments. Active Directory and AD FS remain supported, but Microsoft’s best practices guidance points organizations toward Entra ID for ongoing investment.
How do you migrate Entra Connect to a new server?
Set up a new server in staging mode, import your existing configuration, and run a full sync cycle to confirm everything matches before promoting it to active. Microsoft’s server upgrade guidance recommends this swing migration pattern instead of an in-place upgrade, and warns to promote during an off-peak window to avoid a password sync backlog.
What is the difference between Entra Connect and Cloud Sync?
Entra Connect is the established, server-based sync tool, while Cloud Sync uses lightweight agents and supports multi-forest scenarios with easier failover. Cloud Sync is Microsoft’s recommended path for new deployments, though it currently has some limits around device sync and certain group writeback scenarios, as detailed in the Cloud Sync decision guide.
How long does a typical Entra ID migration take?
Timelines vary widely based on app count and complexity, since each phase requires its own testing and sign-off before moving forward. Organizations working with a structured partner like Total Cyber Solutions can request a managed migration assessment to get a timeline scoped to their specific environment.