Eight questions before a relying party cutover

Before you move a relying party from AD FS to Entra ID, answer eight questions about it. Moving about 30 of them worked because each one got the same questions before anything changed. This note takes the questions one at a time: what the answer tells you, where to find it, and what it changes in the plan.

1. Who signs in to it, and when was the last sign-in?

No sign-ins in 30 days starts a decommission conversation instead of a migration. For apps in use, the migration report shows how many unique users signed in over the last 1, 7, or 30 days, which ranks them by impact.

An app missing from the report either hasn't had a sign-in in 30 days or is a Microsoft relying party such as Office 365, which the report doesn't list.

2. What identifier and reply URLs does it use?

These are the two required settings for a SAML app in Entra, and the only two the migration wizard copies from AD FS into the app's basic SAML configuration. Entra sends tokens only to reply URLs registered for the app, so the list should match what the app actually uses.

Identifiers must be unique across the tenant. If another Entra app already uses the same one, the wizard shows a validation error that an application with the same identifier already exists. The fix is to change one of the two identifiers, and a change on the AD FS side takes 24 hours to show up in the report.

3. What claims does it need, and do any rules transform values?

Questions 3 and 4 decide the effort. A trust that only needs a UPN is a rebuild. Rules that match or rewrite values with regular expressions, add claims with ADD, or aggregate several values into one are the ones the migration report flags. Each has an Entra equivalent that has to be configured by hand, such as the Extract(), Trim(), and ToLower() transformations.

For the name identifier, the wizard keeps an AD FS nameidentifier rule when Entra supports it and falls back to user.userprincipalname otherwise. Check that against what the app expects before cutover day.

4. Does any rule pull from an external attribute store?

This one can stop a migration outright. Entra doesn't source claims from any store other than Active Directory or Entra ID, so a rule that reads from another attribute store gets the EXTERNAL_ATTRIBUTE_STORE finding. That puts the app in Additional steps required, which means it can't move in its current state. It needs a redesign first.

5. Which MFA or access rules live in AD FS today, and which Conditional Access policy replaces each one?

The migration report checks for each of these, and each one moves to Conditional Access or to app assignment:

• Additional authentication rules that prompt for MFA become Conditional Access policies.
• Issuance authorization rules become Conditional Access, or user and group assignment on the enterprise app.
• A required authentication type, set with AllowedAuthenticationClassReferences, becomes Conditional Access.
• Always prompting for authentication, and a custom token lifetime, become Conditional Access session controls. The AD FS default token lifetime is one hour.

The wizard doesn't create any of those policies. It does assign the groups from the trust's access control policy, but only groups that sync to Entra ID. A group that doesn't sync is skipped, so check the assignments by hand.

6. Who owns it on the business side, and who can test it on cutover day?

Every cutover needs a named person who can sign in and say the app works. The cutovers in this migration were planned around business hours, with application owners and user communication coordinated ahead of time.

If you use the migration wizard, it adds the admin who ran it as an owner of the new enterprise app. Add the business owner as well, so someone accountable owns the app after the migration ends.

7. How will it get the new signing certificate, metadata URL or manual upload?

Skip this one and you find out on cutover day, when the app rejects tokens signed with a certificate it has never seen. The AD FS signing certificate doesn't move with the app. Entra signs for each SAML app with a certificate of its own, valid for three years by default.

An app that reads federation metadata can pick up the new certificate from its metadata URL in Entra. Anything else needs the certificate uploaded, in the format its setup instructions name. Sheet 02 covers what happens to that certificate over the next three years.

8. What's the rollback, and how long does the AD FS trust stay in place afterward?

Until an app's sign-in traffic moves to Entra, the new enterprise app sits unused, and rolling back means deleting it. The wizard doesn't clean up after itself, so that deletion is manual, and both the app registration and the enterprise app have to go.

After cutover, rolling back means pointing the app at AD FS again, which only works while the trust still exists. In this migration each trust came out only after its owner confirmed the app was stable and AD FS traffic for it had stopped.

Where the migration report fits

The AD FS application migration report in the Entra admin center runs the claim-rule checks for you and sorts apps into three statuses.

• Ready to migrate means the configuration is fully supported and can move as is.
• Needs review means some settings can't move as is, though none of them block the migration.
• Additional steps required means Entra doesn't support some settings, and the app can't move in its current state.

It needs Microsoft Entra Connect with the Connect Health agent for AD FS, plus an Entra ID P1 or P2 license. It only lists apps with sign-ins in the last 30 days, and it only handles SAML apps, so WS-Fed and OIDC trusts need a manual plan. It also recomputes each app's status once a day, around 00:00 UTC, so a fix made in AD FS shows up after the next daily run.

The report checks the rules. It can't tell you who tests the app, how the certificate reaches it, or how to undo the change, and those answers decide whether cutover day is quiet.