The best time to plan your exit from an identity provider is before you sign with one. The checklist is short: confirm you can export users including password hashes, export your full configuration in a standard format, take complete backups out of the platform, and get a written data retention window for after termination. A vendor that answers those four questions in writing is safe to grow with. A vendor that stalls on any of them is quoting you the price of admission without mentioning the price of the door.
This post is the full version of that checklist, built from the exit questions we now hear in almost every enterprise evaluation, including our own. If you have not chosen a provider yet, the cost of leaving is one of the criteria in our guide to choosing between the cloud IAM delivery models, and it is cheaper to weigh it now than to discover it later.
Why the exit question became standard
Two shifts made lock-in a first-call topic. First, per-user pricing means the bill grows with your success, so teams model “what does leaving cost” the same way they model “what does staying cost.” Second, enough companies have lived through a painful IdP migration that procurement now asks about the exit the way they ask about SOC 2.
We see it from both sides. Prospects leaving a large cloud identity service consistently name the same two reasons: cost that scales with users, and the feeling that their data was designed to be hard to take out. And in our own sales calls, the sharpest buyers ask us directly: if we sign, how do we leave? We consider that a good question, and we answer it in writing.
The exit checklist
1. User export, including password hashes
This is the single biggest lock-in lever, and the one most buyers forget to check. If you can export users but not their password hashes, every user must reset their password when you migrate. For a B2B product that is an annoyance; for a consumer product with millions of accounts it is a churn event.
Ask the vendor: which hashing algorithms do you use, can we export the hashes, and in what format? Then check the receiving side: Keycloak, for example, can import common hash formats or federate against a legacy user store and migrate credentials gradually on first login. That second pattern also rescues migrations where the old provider will not release hashes at all.
2. Configuration export in a standard format
Users are half your IdP. The other half is configuration: clients, roles, groups, identity provider connections, authentication flows, mappers. If that only exists as clicks in a vendor dashboard, your exit includes rebuilding it from screenshots.
What good looks like: a machine-readable export you can run yourself (Keycloak’s realm export and import is the reference example), or better, configuration that already lives in code via Terraform or an equivalent, so the export question never arises.
3. Full backups that leave the platform
Distinct from exports: can you take a complete, restorable backup of your identity data out of the vendor’s platform, on your schedule? Exportable backups turn a vendor relationship into something closer to hosting: the data is yours, running elsewhere is a project rather than a hostage negotiation. This is a standard ask in the enterprise evaluations we participate in, and it should be in yours.
4. A written retention window after termination
When the contract ends, how long does your data live, and what happens then? You want two things in writing: enough time to complete a migration after termination (7 to 30 days is typical), and certified deletion afterward for your own compliance story. If the vendor cannot answer, your GDPR and SOC 2 narratives both have a hole.
5. Standard protocols end to end
If your applications integrate through OIDC and SAML, moving providers is re-pointing issuers. If they integrate through vendor-proprietary SDKs, session formats, or custom rule engines, every application becomes a migration line item. Audit this honestly: count the places you used a vendor-specific feature where a standard flow existed. Each one is exit debt.
6. A rehearsed migration mechanic
Finally, the exit needs a mechanical plan, even a rough one: how traffic moves without downtime. The boring, proven pattern is a dual-run migration: stand up the new IdP alongside the old, broker or federate between them, migrate users gradually, then cut over DNS with short TTLs. If your candidate vendor can describe this plan for leaving THEM, you have found an unusually honest vendor.
How the checklist maps to Keycloak
Since most teams reading this are evaluating Keycloak as the destination (or the escape route), here is the checklist against it specifically:
| Exit checklist item | Keycloak answer |
|---|---|
| User export with password hashes | Yes. Users and credentials live in your database; realm export includes users, and federation can migrate hashes on first login for providers that withhold them |
| Configuration export | Yes. kc.sh export produces full realm JSON you can re-import anywhere, including partial exports via the Admin API |
| Full backups out of the platform | Self-hosted: it is your database. Managed: depends on the provider; Skycloak provides full exportable backups and self-serve realm import and export |
| Standard protocols | OIDC, OAuth 2.0, and SAML 2.0 natively; no proprietary session format |
| Migration mechanics | Brokering and user federation support gradual, zero-downtime migrations, like the Auth0 to Keycloak path |
This is the structural argument for building on open source: the exit plan is a property of the software, not a favor from the vendor.
Questions to ask in your next eval
Use these verbatim:
- Can we export all users with password hashes? In what format?
- Can we export the full configuration ourselves, without a support ticket?
- Can we take complete backups out of the platform on our own schedule?
- What is the data retention window after termination, in the contract?
- Which parts of your product only work through proprietary SDKs or rules?
- Describe how a customer migrates away from you with zero downtime.
The content of the answers matters, but so does the texture. A vendor with a documented exit path answers in one email. A vendor whose retention model depends on walls will schedule a call about it.
The counterintuitive part
Vendors are not harmed by good exit answers. We publish ours on purpose: full exportable backups, standard realm export, defined retention. It wins evaluations rather than losing them, because the buyer’s real fear is not this year’s bill; it is being trapped when the pricing, the product, or the ownership changes in year three. Removing that fear is worth more than any feature comparison.
Choose the vendor you could leave. Then, ideally, never need to.
FAQ
What is IdP vendor lock-in?
Vendor lock-in with an identity provider is any property of the platform that makes migrating away disproportionately expensive: unexportable password hashes, proprietary integration SDKs, configuration that cannot be exported, or contractual data retention gaps.
Can you export password hashes from major identity providers?
It varies widely. Some providers export hashes on request or on specific plans, some never do. Providers built on open source, including managed Keycloak, give you the database, so credentials leave with you. Always confirm in writing before signing.
How do you migrate identity providers without forcing password resets?
Two ways: import password hashes directly if the old provider releases them and formats are compatible, or run gradual migration where the new IdP validates each user’s first login against the old system and re-hashes the credential locally. Keycloak supports both patterns.
Does using open-source-based hosting eliminate lock-in?
It eliminates data and protocol lock-in, since the underlying software runs anywhere and the data model is open. Operational convenience is still a switching cost, but that is the healthy kind of stickiness: it has to be re-earned every renewal.
If you want authentication with the exit plan built in: Skycloak runs upstream Keycloak with full exportable backups, standard realm export, and flat pricing. See pricing.
