IAM platforms price per user and per feature, so costs scale directly with headcount and capability. The commercial suites, Okta, Microsoft Entra ID, Ping Identity, and ForgeRock (now part of Ping), each meter per user and then gate the capabilities you actually rely on, MFA, lifecycle, governance, adaptive policy, behind separate SKUs or modules, often with annual uplifts. Open identity providers, Keycloak, Authentik, Zitadel, remove per-user licensing for self-hosted deployments. What you take on in exchange is the operational ownership: an HA deployment, an external database, backups, and a real patch cadence. IAM is high-stakes, though: it gates every login, so the migration is methodical and app-by-app, never a flag day.
What the timeline actually hinges on
Catalog users and groups, every application’s federation (SAML/OIDC/LDAP) with its metadata, MFA enrollment, conditional-access/policy rules, and SCIM/directory provisioning. Identify application owners, you’ll coordinate per-app cutovers with them. Two items on that inventory tend to decide the timeline more than the app count: how your policies are expressed (simple step-up rules map cleanly, bespoke or scripted logic does not) and where your passwords live. Where identities and credentials sit in an LDAP or Active Directory, you can often federate against that same directory and skip password migration entirely; where they live in the vendor’s own store, plan for either a custom hash provider or a forced reset.
Stand up the new IdP
Create realms/tenants, configure directory sync (LDAP/AD federation or SCIM import), and recreate each app as an OIDC or SAML client with the right redirect URIs, scopes, and claim mappers. Rebuild MFA (OTP/WebAuthn) and translate conditional-access or adaptive policies into the new platform’s authentication flows, which is a re-implementation of each policy’s intent, not an import. Set up break-glass admin access before cutting anything over. Re-registering apps is coordinated work: for SAML you exchange metadata and signing certificates so the relying party trusts the new IdP, and for OIDC you match scopes and claims. The quiet failure mode is claim parity, so diff a real assertion or token from each side per app before you move it.
Cut over app-by-app
Switch each application’s federation to the new IdP, group by group, running dual-auth (both IdPs valid) during transition where possible. Migrate or re-enroll MFA and verify SCIM provisioning/deprovisioning. Monitor sign-in logs for failures after each app. Sequence the waves by risk: move a low-risk, low-traffic app first to shake out theming, email flows, and claim mapping, then work up to the apps that would hurt most if login broke. Session and logout behavior differs between platforms, so test single logout and token refresh, not just the initial sign-in.
Testing every app before the source goes dark
Test SSO per app (both SAML and OIDC), MFA and policy enforcement, and provisioning/deprovisioning. Keep the source IdP live until every app validates; rollback is re-pointing the affected app’s federation back. Token-refresh and IdP-failover tests round it out.
Sparing users a lockout storm
Pilot one representative app end-to-end before the broad rollout, and communicate MFA re-enrollment to users in advance to avoid lockout support storms. Because MFA enrollments rarely transfer between platforms, users re-enroll their OTP or passkey regardless of how you handle passwords, so stage that re-enrollment per app group rather than all at once. Keep both IdPs live until the last relying party validates, and treat the vendor decommission as a separate, later decision from the technical cutover.
Open a source→target page for IdP-specific steps and a per-user TCO model.