How to migrate from AD FS to Microsoft Entra ID

List all relying party trusts, including disabled ones, with their identifiers. Add an owner, protocol and business criticality for each in your app inventory.

Get-AdfsRelyingPartyTrust | Select-Object Name,Enabled,@{n="Identifier";e={$_.Identifier -join ";"}},WSFedEndpoint,ProtocolProfile | Export-Csv C:\migration\adfs-rps.csv -NoTypeInformation

Connect Health usage data needs AD FS audit logs, which are not fully enabled by default. Check the AD FS service account has Generate security audits in Local Security Policy (Security Settings > Local Policies > User Rights Assignment), then run the commands below. In AD FS Management, under Edit Federation Service Properties > Events, check Success audits and Failure audits are ticked. Make sure no Group Policy disables AD FS auditing.

auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
Set-AdfsProperties -AuditLevel Verbose
Get-AdfsProperties | Select-Object AuditLevel

Download the agent from https://www.microsoft.com/en-us/download/details.aspx?id=108777, run it, select Install and sign in with an account allowed to register agents when prompted. Install it on the WAP servers too.

Test-MicrosoftEntraConnectHealthConnectivity -Role ADFS

Record the federation configuration of each federated domain. Look for customised PreferredAuthenticationProtocol, federatedIdpMfaBehavior, SupportsMfa and PromptLoginBehavior.

Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain | Select-Object Id,AuthenticationType
Get-MgDomainFederationConfiguration -DomainId contoso.com | Format-List * | Out-File C:\migration\contoso-federation.txt

Take a backup with the AD FS Rapid Restore Tool (download and usage on Microsoft's Rapid Restore Tool page), and export the Microsoft 365 relying party trust with its claim rules.

(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"

Sign in, step through to Optional features, tick Password hash synchronization, and complete the wizard with Configure. This does not change how federated users sign in yet.

Download the agent from https://aka.ms/getauthagent and install it, signing in when prompted. Microsoft recommends at least three agents in production and allows up to 40 per tenant. Agents need outbound 443 and 80, and access to login.windows.net and login.microsoftonline.com for registration. Treat these servers as Tier 0.

Import the modules, sign in as Hybrid Identity Administrator when the window opens, then enable the forest with domain administrator credentials. Deploy the seamless SSO URLs to the intranet zone by Group Policy as Microsoft's quickstart describes.

Import-Module "$env:ProgramFiles\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1"
Import-Module .\AzureADSSO.psd1
New-AzureADSSOAuthenticationContext
$creds = Get-Credential
Enable-AzureADSSOForest -OnPremCredentials $creds
Get-AzureADSSOStatus | ConvertFrom-Json

Microsoft says the synchronizeUpnForManagedUsersEnabled setting must be true after moving to cloud authentication, or UPN changes for licensed users will not sync. Check it now.

Connect-MgGraph -Scopes "OnPremDirectorySynchronization.Read.All"
(Get-MgDirectoryOnPremiseSynchronization).Features | Format-List SynchronizeUpnForManagedUsersEnabled

For each trust, note who is permitted, from which networks, and whether MFA is required. Build matching Conditional Access policies scoped to a pilot group and set to Report-only. Add a policy to block legacy authentication, as Microsoft recommends.

Create cloud-only security groups with assigned membership for each wave. Staged rollout does not support nested or dynamic groups, and limits a new group to 200 users when you first add it.

Configure company branding so users recognise the new sign-in page. Enable the methods you want (Microsoft Authenticator, passkeys, Temporary Access Pass) and ask pilot users to register at https://aka.ms/mysecurityinfo.

Slide Password Hash Sync (or Pass-through authentication) to On, and Seamless single sign-on if you use it. Do not combine PHS and PTA. Add the pilot group to each feature. Users in a new group switch straight away; edits to an existing group can take up to 24 hours.

A user newly added to staged rollout needs one more AD FS sign-in before managed authentication applies. Microsoft's workaround is a TAP straight after adding them, so they sign in to Entra ID and register their methods without going to AD FS.

Off the corporate network, enter a pilot user's UPN: they should see the Entra sign-in page, not AD FS. On the network with seamless SSO, they should see "Trying to sign you in" and sign in silently. Filter the sign-in logs by the user and check the result. Check the AD FS event logs for any pilot users still reaching AD FS.

The dashboard lists relying parties with sign-ins in the last 1, 7 or 30 days. Use All apps to see usage, and select the Migration status link for each app to see which configuration and claim rule tests passed. Status is Ready to migrate, Needs review or Additional steps required.

On Basics keep or change the app name and optionally pick a gallery template. Review the read-only User & groups (taken from the trust's access control policy; groups must be synced), SAML configurations (identifier and reply URL) and Claims tabs, read Next steps, then select Create on Review + create.

On the SAML-based Sign-on page, add any claims the wizard could not move and download the Federation Metadata XML or certificate: the wizard does not migrate the AD FS signing certificate. Add Conditional Access for the app. Follow Microsoft's stages: point a test instance of the app at Entra ID first, then production, by replacing the AD FS metadata or URLs in the app.

Register OAuth 2.0, OpenID Connect and WS-Federation line-of-business apps as app registrations, and custom SAML or WS-Fed apps as non-gallery enterprise apps. Publish apps that use Kerberos or header-based authentication through Microsoft Entra application proxy or a Secure Hybrid Access partner.

When an app is live on Entra ID, disable its trust first so you can re-enable it quickly if something was missed. Remove it after the app owner signs off.

Disable-AdfsRelyingPartyTrust -TargetName "Contoso Payroll"
# after sign-off
Remove-AdfsRelyingPartyTrust -TargetName "Contoso Payroll"

If the AD FS farm is listed, Entra Connect set it up and you can use Option A below. If not, use Option B with PowerShell.

Sign in with a Global Administrator. On User sign-in choose Password hash synchronization and tick Do not convert user accounts, or choose Pass-through authentication; tick Enable single sign-on if you need seamless SSO. Enter domain administrator credentials on Enable single sign-on, keep Start the synchronization process when configuration completes ticked and select Configure. This converts all federated domains at once.

For PTA, first confirm every agent shows Active, or you risk an outage. Convert one domain at a time, starting with a test domain or the smallest. Allow up to 60 minutes for the change to take effect. If you used PTA, update the sign-in method in Entra Connect afterwards so it recognises PTA as enabled.

Connect-MgGraph -Scopes "Domain.ReadWrite.All","Directory.AccessAsUser.All"
Update-MgDomain -DomainId contoso.com -AuthenticationType "Managed"
Get-MgDomain -DomainId contoso.com | Select-Object Id,AuthenticationType

Microsoft says staged rollout is not a permanent state. Once all domains are managed, slide each feature back to Off.

Run dsregcmd /status and check the device still gets a Primary Refresh Token. Microsoft notes Windows 10 earlier than 1903, and users with non-routable UPNs, fell back to AD FS WS-Trust during staged rollout and need attention now. If your hybrid join SCP pointed at AD FS, re-run Configure device options in Entra Connect for a managed domain.

dsregcmd /status

Wait at least one week after moving authentication. Check Connect Health usage and the AD FS event logs for any successful or failed sign-ins. Any traffic means a trust or client still depends on AD FS. When there is none, remove the Microsoft 365 trust.

Remove-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform"

Optionally take a final Rapid Restore Tool backup. Note the CertificateSharingContainer DN; you delete it at the end. If the AD FS configuration database is on SQL Server, delete that database before uninstalling.

Get-AdfsProperties | Select-Object CertificateSharingContainer

Remove AD FS entries from internal and external load balancers, and delete the DNS records for the farm name (for example sts.contoso.com).

Remove any published web applications for AD FS, then uninstall the role.

Uninstall-WindowsFeature Web-Application-Proxy,CMAK,RSAT-RemoteAccess

Uninstall AD FS and the Windows Internal Database, then delete the database files.

Uninstall-WindowsFeature ADFS-Federation,Windows-Internal-Database
del C:\Windows\WID\data\adfs*

Delete the AD FS SSL certificates from each server, then re-image the servers with full disk formatting. Delete the AD FS service account. In ADSI Edit, remove the contents of the CertificateSharingContainer DN you recorded.