Migrate identity providers by preserving the link between credentials, application accounts and access decisions. Rehearse the cutover with synthetic accounts. Define rollback before changing production routing.

A standards-based login interface reduces application changes. It does not automatically transfer passwords, MFA, passkeys, social identities or active sessions. This runbook helps a SaaS team identify those dependencies before choosing a migration date.

Assign one owner to each migration boundary

Boundary	Evidence to collect	Responsible owner
Account	Stable application identifier and duplicate policy	Application team
Credential	Supported export, import and verification behavior	Identity team
Federation	Provider issuer, subject and account-linking policy	Identity team
Authorization	Roles, memberships and resource permissions	Application owner
Session	Old cookies, refresh tokens and expiry rules	Application and identity teams
Operations	Rehearsal results, stop conditions and rollback	Release owner

Keep the application account identifier stable where possible. Store the old and new identity references in an explicit mapping. A successful login to the destination should resolve to the intended account and tenant.

Classify accounts by the credential you can move

Start with actual export capability. Separate compatible password hashes, unsupported hashes, social-only identities, passkeys, enrolled MFA and suspended accounts. A source may export account metadata while withholding the credential material you need.

Firebase documents a specific export and modified-scrypt format. That is one example of why algorithm names and parameters need exact compatibility checks. Its export does not establish destination support. Firebase export documentation.

Use the Firebase migration guide for that vendor-specific route. Keep a separate strategy for accounts that need recovery or new credential enrolment.

OpenID Connect identifies an account within an issuer through its subject. Use the documented issuer and subject semantics when designing the mapping. Email can change and should not become an automatic cross-provider account-merging rule. OpenID Connect subject guidance.

For a synthetic rehearsal, create two source accounts with the same displayed email but different provider identities. Confirm that the destination does not silently merge them. Then test an explicitly authorized linking journey.

Record how the application resolves an ambiguous mapping. A support agent needs an approved review route that does not expose credential exports.

Treat sessions as a separate cutover

An imported account does not prove that an old application cookie or refresh token remains valid. Identify which issuer each client trusts and which service owns each session.

Source identity -> mapping -> application account
Destination identity -------^        |
                                    v
                         Tenant and resource policy

During a transition, define exactly which issuer and audience combinations each service accepts. Use explicit validation rules for each token profile. Do not accept a token simply because either provider signed it. JWT validation guide.

An old session can outlive credential migration. An old refresh token can also remain usable until the responsible system rejects it. Include those cases in the logout and revocation review.

Rehearse the failure cases

Download the migration rehearsal worksheet. Give each case an expected result before running it.

Test one account from each credential group.
Verify the destination account and tenant mapping.
Test a rejected password and an expired challenge.
Test a suspended account and a removed membership.
Test social identity collisions and changed email addresses.
Test MFA, recovery and passkey enrolment.
Test old sessions after the routing change.
Rehearse a provider outage during cutover.
Record the rollback result for newly changed accounts.

Use test identities and synthetic data. A local fixture proves the behavior of that fixture. Record approved provider-environment tests separately.

Set a measurable stop condition

Before release, agree on a sign-in failure threshold and an account-mapping error response. Assign the person who can halt traffic migration. Use values appropriate to your baseline and customer impact rather than a generic percentage from another team.

Rollback becomes harder when the destination creates users, changes passwords or alters memberships. Keep a protected change register and a reconciliation procedure. An old database snapshot is not a complete plan for those later changes.

Retire the source with evidence

Confirm the treatment of dormant accounts, old refresh tokens, federation connections, exports and signing-key trust. Assign retention and deletion owners. Preserve only the migration evidence the organization needs under its policy.

Use the provider evaluation scorecard to compare remaining operational responsibilities before closing the project.

Plan your migration with NamoID

NamoID engineers can help review issuer configuration, account mapping and application sessions. Confirm source-hash, factor and import support for your actual migration before promising users an unchanged journey.

Share your current provider, stack and credential groups in Slack for an early response. Contact the NamoID team

Related posts