Identity Provider Migration. @identity-provider-migration

Changing identity providers is open-heart surgery: every user, session, and integration flows through the thing you are replacing. This sprint moves authentication from one platform to another — Auth0, Cognito, Firebase, Keycloak, homegrown, or others — while users keep signing in throughout.

Credentials migrate by the safest available path — bulk export, lazy migration on first login, or both — with a dual-run period where the platforms operate side by side before cutover. The finish state: authentication fully on the new platform, migration metrics reconciled, and the old platform ready to retire.

Migration strategy & mapping

Flows, token formats, sessions, and integrations mapped, with a credential-migration strategy — bulk, lazy on first login, or both — chosen for your constraints.

User & credential migration

Users, credentials, and identities moved by the safest available path, with the metrics to prove completeness.

Dual-run cutover

The platforms run side by side while traffic shifts, so sign-in keeps working for every user throughout.

Rollback & verification

A reconciliation report, verified behavior parity, and a rollback path that stays open until cutover is confirmed.

1. Scope. Map the flows, tokens, and integrations; choose the migration and cutover strategy.
2. Build. Implement the new platform, migrate users, and dual-run with verification.
3. Handover. Final cutover with rollback, reconciliation report, and an old-platform retirement plan.

The Identity Provider Migration is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

Will users have to reset their passwords?

Usually not. Where hashes can be exported, they migrate directly; where they cannot, lazy migration re-hashes each password transparently at first login. Forced resets are the last resort, not the plan.

Can we add SSO or MFA during the migration?

The migration itself targets like-for-like behavior — that is what makes it verifiable. New capabilities ride along as explicitly scoped additions, or follow as the Enterprise SSO Implementation and Multi-Factor Authentication Rollout items.

What do we need to provide?

Admin access to both platforms, whatever export the current one allows, and an inventory of every application and integration that authenticates against it.