After an identity migration, migrated users have accounts in the target tenant but no passwords. ShareGate uses Microsoft Entra ID's Self-Service Password Reset (SSPR) as the onboarding mechanism — the secure step that lets each user claim their new account.
Before you migrate: confirm SSPR is ready
SSPR is not enabled by default in Microsoft Entra ID. Before running the migration, confirm the following in the target tenant:
SSPR is enabled for all users being migrated. This requires Entra ID P1, P2, or Microsoft 365 Business Premium licensing.
Conditional Access policies won't block the SSPR flow. Migrated users won't have MFA registered yet. If your Conditional Access policies require MFA to complete a password reset, those users will be locked out before they can claim their new account.
Source tenant mailboxes are still active when users go through the SSPR flow. If old mailboxes are decommissioned before users claim their new accounts, they won't be able to retrieve the verification code.
How to enable the SSPR flow during migration
When you run the identity migration, ShareGate gives you the option to set each user's old email address (for example, [email protected]) as an alternate authentication method on their newly created account in the target tenant. Enable this option — it's what makes the SSPR flow possible.
Note: ShareGate currently supports only the old email address as the alternate authentication method for SSPR. Phone number and other methods are not supported at this time.
If you turned the option off and want to enable it later, re-run the migration with the affected users selected and turn the toggle on.
How users claim their new account
Once migration is complete, use the post-migration report generated by ShareGate to identify which users need to complete the SSPR flow.
Open the post-migration report and identify which users need to complete the SSPR flow.
Notify those users that they need to reset their password to access their new account. Give them the Microsoft SSPR URL to type in themselves. See How to communicate the SSPR flow to users below for guidance on wording the notification safely.
Each user navigates to the Microsoft SSPR page and enters their new user principal name (UPN) — for example, [email protected].
Microsoft sends a verification code to their old email address — [email protected].
The user logs into their old mailbox using their source tenant credentials, retrieves the code, and enters it on the SSPR page.
The user sets a new password for the new account.
From there, they can register MFA methods and start working in the new tenant normally.
Why this flow is secure
The SSPR flow has a built-in second gate: to retrieve the verification code, the user must authenticate to the source tenant with their old credentials. That means even if an attacker knows a new account exists and knows the new UPN, they can't complete the flow without access to the old mailbox.
How to communicate the SSPR flow to users
Keep the notification email link-free. Tell users to navigate to the Microsoft SSPR page themselves and give them the URL to type in. Don't include a clickable link.
A message with a direct "click here to reset your password" link is identical in format to a phishing attack. Security-conscious users — especially in enterprise environments — are trained to distrust exactly that pattern. A plain-text URL they type themselves removes any ambiguity, and if the email is forwarded or intercepted, there's nothing actionable in it.