Most teams pick an identity platform the wrong way: they compare feature grids, tick off SAML, OIDC, MFA, and conditional access, and pick whatever checks the most boxes. That is how you end up self-hosting an identity provider your team is not staffed to run at high availability, or choosing a lighter tool that cannot express the governance your compliance regime demands. Identity gates every login, so the wrong choice is expensive to unwind. The better approach is to score your real environment against the factors that genuinely decide the answer, then look at products. This guide gives you that rubric.
Map your identity estate first
Before you shortlist anything, write down four things. First, how many applications you federate and which protocols they speak: SAML, OIDC, or legacy LDAP, because the protocol mix and the count decide the migration’s shape more than any feature does. Second, where your directory actually lives, on-premises Active Directory, a cloud directory, or the vendor’s own store, since that determines whether you can federate against your existing directory and skip password migration entirely. Third, your MFA and adaptive or conditional-access requirements, expressed as the policies you must enforce rather than the ones a product happens to offer. Fourth, an honest read of your tolerance for self-hosting, because moving to an open provider shifts real operational ownership onto your team.
What actually moves the needle
- Application count and protocols. A handful of modern OIDC apps is a very different project from dozens of applications, some on legacy LDAP. Inventory the protocols, because each app is re-registered by hand.
- Where your directory lives. If identities and credentials sit in AD or LDAP, you can often federate against that same directory and avoid password migration. If they live in the vendor’s store, plan for a custom hash provider or a forced reset.
- MFA and adaptive policy. Simple step-up rules translate cleanly; bespoke or scripted conditional-access logic is a re-implementation of intent, not an import, and it drives the timeline.
- Self-hosting tolerance. An open provider removes per-user licensing but hands you an HA deployment, an external database, backups, and a patch cadence. Be honest about whether you will actually run that well.
- Lifecycle and governance. If you depend on SCIM provisioning, access reviews, or formal governance, confirm the target covers it. Not every lighter option carries the full governance surface.
- In-house identity skills. The platform your team can operate and troubleshoot is cheaper than a technically richer one they have never run under load.
Which provider suits which estate
Score your estate against the criteria above, then treat these as starting points. A team with a substantial application count, real governance needs, and the staffing to run a distributed system usually looks first at Keycloak: it is open, mature, and broad in protocol and federation support, in exchange for genuine operational ownership. A smaller estate that wants a lighter, more opinionated deployment and a gentler operational load often considers Authentik or Zitadel as the more approachable options. Coming off Okta, Microsoft Entra ID, Ping Identity, or ForgeRock does not settle the answer by itself; your app count, directory location, policy complexity, and appetite for self-hosting do. The honest trade across all of these is the same: removing per-user licensing moves the cost to your operations and support, and that trade favors teams that can staff it.
Where identity choices go wrong
A few errors recur. The first is choosing on feature checkboxes while ignoring day-two operations, which for a self-hosted IdP is where the real cost and risk live. The second is underestimating policy translation, assuming adaptive rules import when they must be rebuilt, and discovering the gap mid-project. The third is planning a flag-day cutover instead of an app-by-app migration with the source IdP kept live, which for a system that gates every login is how you cause a lockout storm. A quieter fourth: not diffing a real token or assertion per app before moving it, so a claim-parity mismatch breaks an application only after cutover.
Confirm it app by app before you commit
Turn your top candidate into a pilot with written acceptance criteria. Stand up the new provider, configure directory sync, and migrate one representative, low-risk application end to end: exercise SSO for its protocol, MFA, the policies it depends on, and SCIM provisioning and deprovisioning. Diff a real assertion or token against the source per app so claim parity is proven, not assumed. Run dual-auth where you can, keep the source IdP live until the last relying party validates, and treat the vendor decommission as a separate, later decision from the technical cutover. Model the saving qualitatively and treat any figures as illustrative until quoted; run your own user count through the calculator. Then weigh the removed per-user licensing against the operational load you are taking on, and choose the platform you can actually run at the availability identity demands, not simply the cheapest per-user line.