SSO Migration Checklist

When to Use This Checklist

Use this checklist when consolidating fragmented application logins onto a centralized single sign-on system, or when migrating from one identity provider to another. SSO reduces password sprawl, centralizes access control and MFA, and gives a single audit point for authentication. The trade-off is that the identity provider becomes critical infrastructure, so the migration must be careful and reversible.

How to Use This Checklist

Begin by inventorying every application and how it currently authenticates, because the migration approach differs per app. Choose the protocol per application: OpenID Connect for modern apps, SAML 2.0 for legacy ones that require it. Carefully map identities and attributes from existing directories into the identity provider, and plan automated provisioning with SCIM so account lifecycle stays in sync.

Migrate in waves, not all at once. Start with a pilot group on a low-risk application, validate the full login and logout lifecycle, then expand. Always plan a break-glass fallback so an IdP outage cannot lock everyone out.

What Good Looks Like

Users authenticate once through the identity provider, with MFA enforced centrally, and reach all their applications without re-entering credentials. Identities and group memberships flow automatically into apps, and group-to-role mappings drive least-privilege authorization. Single logout works, sessions expire sensibly, and every authentication event is logged centrally for audit. A break-glass path exists for IdP outages, and legacy local credentials are removed only after SSO has proven stable, eliminating the parallel login paths attackers love.

Common Pitfalls

A frequent and serious mistake is leaving legacy local logins enabled after SSO is live, creating a bypass around MFA and central control. Big-bang cutovers without a pilot expose every user to undiscovered issues at once. Teams often overlook deprovisioning, so departed users retain access. Forgetting a break-glass path means an IdP outage becomes a total lockout. Finally, sloppy attribute and group mapping leads to broken authorization, where users get too much or too little access.

Related Resources

Base the design on OAuth 2.0 and OpenID Connect, enforce least privilege through group-to-role mappings, and align with zero-trust architecture where identity is the primary control plane.