Migrate from Clerk to Ory

Migrate from Clerk to Ory: what the move involves

Teams usually start this move at a Clerk renewal, when retained-user pricing or a data residency or control requirement makes self-hosting worth evaluating. The short answer is that Ory Kratos can import your users and their password hashes, so people keep their existing passwords, but you must build the login, registration, recovery and account screens yourself, because Kratos is API-first and ships no prebuilt components like the ones Clerk provided. Kratos accepts a long list of existing hash formats, including BCrypt and Argon2, and for formats other than those two it verifies the hash at sign-in and then rehashes the password with your configured hasher. Formats it does not support can be handled through a password migration webhook, as the Ory import documentation describes. The work usually falls to a platform or security engineer who owns the identity service and the database, paired with a front-end developer who builds the login flows against Kratos's self-service APIs. The first thing to confirm is whether Clerk's export gives you hashes you can actually use. Clerk's export is covered on its own sibling page, but the hash algorithm it reports determines whether you need the webhook path, so check that before you plan the cutover. Clerk's hashing scheme and any password-less accounts (social or passkey only) must be mapped explicitly, and you should test sign-in for a sample of each type before any user is moved. Effort and risk sit mainly in the front end and the cutover, not in the data import itself. Plan for session handling, password reset emails, social provider callbacks and passkey enrollment to be rebuilt and tested, since these are the screens your users see every day. The main risk is a user population that cannot sign in on day one, so run both systems in parallel for a period, keep a rollback path to Clerk, and decide early which features need Ory's enterprise license, such as SAML and organization login, because those change the architecture rather than the import.

Which Clerk capabilities map cleanly to Ory

This table maps each Clerk capability you rely on to the Ory component that covers it, and marks whether the fit is clean, needs rework or is a gap. Read the status column first, then the notes, because several rows depend on Ory's enterprise license rather than the open-source servers. Most of the work sits in the login and account screens, which Clerk supplied as prebuilt components and Ory expects your team to build.

Clerk capability	Ory equivalent and fit	Status
Email and password sign-in and sign-up	Ory Kratos password method. Existing hashes import in supported formats and are verified at first sign-in.	Clean
Prebuilt sign-in and sign-up components	No equivalent. Kratos is API-first, so your team builds login, registration, recovery and account screens against its flows.	Needs rework
Social login	Kratos supports social sign-in. Confirm the providers you use and the configuration in your Kratos version.	Clean
Passkeys	Kratos supports passkeys. Test browser and device coverage in your own login screens before cutover.	Clean
Multi-factor authentication (TOTP)	Kratos supports TOTP. Confirm other second factors you use with Clerk, since they are not listed in the researched Ory facts.	Needs rework
User metadata and custom attributes	Kratos identity traits are defined in your own JSON schema. Map Clerk public and private metadata to traits during export.	Needs rework
Sessions	Kratos manages sessions for its own flows. Token issuance for your apps runs through Ory Hydra, so session handling must be designed and tested.	Needs rework
Organizations (B2B)	Organization login and multi-tenancy are enterprise features under the Ory Enterprise License. Open-source Kratos does not cover this.	Gap
Enterprise SAML connections	Kratos lists SAML as an enterprise feature. Ory Polis handles SAML and OIDC single sign-on, so confirm its licensing and fit with your plan.	Gap
SCIM directory sync	Kratos lists SCIM as an enterprise feature. Ory Polis provides SCIM directory sync, and its fit should be confirmed against your customers' directories.	Gap
Backend user API	Kratos Admin API and Hydra APIs cover user and client management. Your backend calls must be rewritten to the Ory endpoints.	Needs rework

Which user data and credentials move, and by what path

Four paths carry a Clerk application onto Ory: the user export, the Kratos identity import, the password hash handling, and the application code that calls Clerk at runtime. Each one needs its own check, because a user who imports cleanly can still fail to sign in if the session, webhook or OAuth layer was not rebuilt.

Clerk user export as the source

Start with the CSV export from the Clerk dashboard, which carries user records and hashed passwords. Organizations, public and private metadata, and verified contact details sit outside that file, so pull them through the Clerk API as a second export. Confirm which fields your own export contains before you write any import code, and check a sample of records against the Clerk dashboard. The sibling export guidance covers who can run the export and how to validate it.

Kratos identity import with hash formats

Kratos imports identities with existing password hashes, including BCrypt, Argon2, PBKDF2 and SCrypt, so users keep their current passwords. For formats other than BCrypt and Argon2, Kratos verifies the imported hash at sign-in and then moves the user to the configured hasher. Confirm the hash algorithm and parameters in your own export before you map fields, since a mismatch will fail at first login rather than at import.

Password migration webhook for unsupported hashes

If your Clerk export uses a hash format Kratos does not support, plan a password migration webhook before cutover. The webhook receives a login attempt for an imported user and checks the password against the legacy hash, which keeps those users signing in without a reset. Decide early whether the webhook service stays in place after the migration window, and test it with real hash samples from the export.

Frontend SDK calls rebuilt on Kratos flows

Clerk's frontend SDK and prebuilt components handle sign-in, sign-up, profile and MFA screens in the browser. In Ory these become calls to Kratos self-service flows, so your team builds each login, registration, recovery and account screen against the Kratos API. Inventory every Clerk component in use, such as <SignIn /> and <UserProfile />, and assign each one to a Kratos flow before estimating the frontend work.

Backend session verification and Clerk webhooks

Backend services that call Clerk to verify session tokens must switch to Kratos session checks, and any handler that reads Clerk's user or session data needs a replacement. Clerk webhooks that notify your app about user creation or deletion also need a new source, either Kratos events or your own sync job. Confirm every service that depends on a Clerk webhook, because a missed one causes silent drift in your user records.

OAuth clients on Hydra

Any application that uses Clerk as an OAuth or OpenID Connect provider needs its clients re-registered in Ory Hydra, which handles the protocol while Kratos handles the user login. Hydra integrates with your login and consent screens through headless APIs, so those screens must exist before Hydra can issue tokens. Confirm redirect URIs, scopes and token lifetimes for each client, and test sign-in against each one before cutover.

Migration sequence from inventory to decommission

This sequence moves Clerk users, sign-in flows and account screens to self-hosted Ory Kratos in controlled stages, so each stage produces evidence before the next one starts. It ends with Clerk retired and its keys revoked.

Inventory Clerk features in use
Your team lists every Clerk feature the application depends on: sign-in methods, social connections, passkeys, MFA, organizations, enterprise SSO connections, webhooks, session settings and the prebuilt components in the frontend. Each item gets an owner and a target: Kratos flow, Hydra for OAuth2 and OIDC, or a feature that needs confirmation from Ory. The output is a feature inventory with a gap list, including any SAML, SCIM or organization login needs that Ory reserves for its Enterprise License. Confirm those licensing boundaries with Ory before the pilot starts, using its Enterprise License documentation.
Export users and check the export
Export users, metadata and organizations from Clerk using the dashboard and the API, then compare record counts and a sample of accounts against the live Clerk dashboard. Confirm whether the export includes password hashes and in which format, since the hash format decides the import path. Store the export in an encrypted location with restricted access, because it contains personal data. The output is a verified export manifest with counts, field definitions and a note on which hash formats you hold.
Pilot with a copy of users and one flow
Import a copy of the exported users into a non-production Kratos instance backed by PostgreSQL, then map Clerk fields to a Kratos identity schema with the traits you need. Test one login flow end to end, including password sign-in and the account screen your team builds to replace Clerk's components. For BCrypt and Argon2 hashes, Kratos keeps the hash as is. For other supported formats, it verifies the hash at sign-in and moves the user to the configured hasher. The output is a field mapping document, a hash verification test log with pass and fail cases, and a sign-off on the pilot flow.
Run a parallel period with a password path
Run Kratos alongside Clerk for a defined set of test users while sign-in continues on Clerk for everyone else. Where a hash format is unsupported, plan the password migration webhook that Ory's import documentation describes, so users can move over on their next successful sign-in. Track failed logins, lockouts, session behavior and social or passkey enrollment in both systems. The output is a parallel run report with error categories, a list of open defects and a written rollback plan that names who can reverse the routing change and what state must be preserved.
Cut over application sign-in
Switch the application's authentication routing from Clerk to Kratos and Hydra for a planned group, then extend the cutover in stages. Keep the Clerk export and rollback plan available until the final group has signed in successfully. Monitor authentication errors, support tickets and session issues against the baseline from the parallel run. The output is a cutover log showing the date of each stage, the user groups moved, and the monitoring results, with an explicit go or no-go decision recorded for each stage.
Decommission Clerk and revoke keys
After the cutover is stable, disable Clerk sign-in, remove Clerk SDKs and components from the code, and revoke Clerk API keys, webhook secrets and any frontend publishable keys. Confirm with your billing contact how Clerk subscription and retained-user charges stop, and whether any data retention obligations require you to keep an archive of the export. Delete working copies of the export that are no longer needed, keeping only what your records and compliance obligations require. The output is a decommission checklist signed by the application owner and the security lead, showing revoked keys and removed components.

How the move differs by starting point

A consumer application that uses email and password, one-time codes and social sign-in is the simplest starting point. The main work is moving identities into Kratos, rebuilding the sign-up, sign-in, recovery and account screens that Clerk's prebuilt components used to supply, and wiring social providers and passkeys into the Kratos flows. Most of this is standard Kratos configuration and front-end work, and it runs on the open-source server.

Identities: Export users from Clerk and import them into Kratos, keeping email addresses as the stable identifier.
Password hashes: If Clerk's export includes hashes in a format Kratos supports, users keep their passwords and do not need a reset.
Login screens: Build the flows yourself against Kratos's self-service APIs, since Clerk's components will not carry over.
Social and passkeys: Kratos supports social sign-in, passkeys and TOTP in the open-source edition, so these do not require a license.
Licensing: No Enterprise License is needed for this profile.

Before cutover, confirm with Ory and in a test environment that each social provider and passkey flow behaves as your users expect.

What drives the cost and duration of the move

This table lists the factors that move the cost and effort of leaving Clerk for self-hosted Ory, with the reason each one matters and how to keep it down. Read it before requesting a quote, because the same scope can cost very different amounts depending on how many screens, hash formats and Clerk features are involved. The main takeaway is that the Enterprise License decision and the number of custom login and account screens usually shape the plan more than the user count does.

Driver	Why it changes cost or effort	How to keep it down
Login, sign-up and account screens	Clerk supplies prebuilt components for sign-in, sign-up, profile and MFA setup. Ory Kratos is API-first, so each screen your users see must be built and tested by your team or a partner.	Inventory every Clerk component in use, reuse one design system across screens, and cut screens your product does not need before build starts.
Password hash format	Ory imports BCrypt and Argon2 directly and verifies other supported formats at sign-in before rehashing. Hash formats outside that list need a password migration webhook, which adds build and test work.	Confirm the hash format from the Clerk export early. Ask Ory's import documentation whether your format is supported natively before designing the migration.
Clerk features in use	Organizations, enterprise SSO connections, passkeys, MFA and user metadata each need a matching Ory design, and some map to features Ory reserves for its enterprise license.	List which Clerk features are live and used by customers. Drop unused features from scope and phase the rest.
Organizations and multi-tenancy	Clerk organizations and roles must be recreated as Ory identity structures and permissions. Multi-tenant organization login is an Ory Enterprise License feature, so the design depends on that decision.	Map each Clerk organization role to the permission model you need, and confirm early which tenancy features your edition includes.
SAML and enterprise SSO	SAML, SCIM and organization login are enterprise features in Ory's self-hosted open-source edition according to the Kratos README. Customer SSO connections therefore need either the Enterprise License or another broker, such as Keycloak or Ory Polis.	Count active SSO connections and their protocols. Ask Ory which features are included in the license tier you are quoting.
Integration count	Each application, API, webhook and session check that calls Clerk must move to Ory's APIs or to Ory Hydra for OAuth2 and OpenID Connect. Every integration needs its own token and session changes.	Build a list of every service that validates Clerk sessions or tokens and group them by how they authenticate.
Testing and security review	Login flows, account recovery, MFA enrollment and token handling need functional, negative and security testing before cutover. Your security team may also need evidence for the new login path.	Write test cases from the current Clerk behavior, run them against a staging environment, and schedule security review before the cutover date is set.
Enterprise License decision	Ory Open Source suits evaluation and deployments that accept occasional upgrade downtime without guaranteed CVE patching. The Enterprise License adds support SLAs, timely CVE patches and enterprise features, which is a recurring cost.	Decide the support and patching requirement first, then ask for a license quote alongside the implementation quote so the two can be compared.
Infrastructure and database	Kratos runs on SQLite, PostgreSQL, MySQL or CockroachDB. Production hosting, backups, high availability and monitoring are recurring costs in your own cloud or data center.	Choose a database your team already operates, and ask for the expected hosting topology to be written into the quote.

What usually goes wrong and how to prevent it

Most failed Clerk to Ory moves fail at the seams: password hashes, sessions, social and passkey logins, and the features that sit behind Ory's enterprise license. Each card below names one risk and the check that catches it before users notice. Run them in a staging copy of the identity store first.

Password hash verification failures

Clerk's standard export does not give you a clean path for every stored hash, so some users may not match what Ory expects. Ory verifies non-BCrypt and non-Argon2 hashes at sign-in and then rehashes them, which means a wrong format string fails silently until a user tries to log in. Test a sample of accounts from each hash type you receive, and confirm with Clerk which algorithm and parameters each hash uses. If a format is unsupported, plan a password migration webhook rather than forcing resets.

Users locked out at cutover

A cutover that switches the login endpoint before every account has imported leaves some users with no working credential. Run the import in a dry run, count imported identities against the Clerk export, and keep Clerk active until the counts and sample logins match. Decide in advance whether unmatched accounts get a reset link or a support path, and publish that path before the switch.

Session and token invalidation

Active Clerk sessions and tokens do not carry over to Ory. Every signed-in user will be asked to log in again once the front end points at Ory, and any service that validates Clerk JWTs will reject tokens it no longer recognizes. Inventory every service that verifies tokens, move each one to Ory's issuer and keys, and schedule the cutover for a low-traffic window with the expected re-login impact communicated to users.

Missing social and passkey re-enrollment

Social sign-in links and registered passkeys are tied to the original provider, so they are not automatically recreated in Ory. Users who only ever signed in with Google or Apple may find no working method after the switch. Configure each social provider in Kratos, confirm passkey enrollment works on your own domain, and send re-enrollment instructions to users who relied on those methods.

SAML and organization features assumed open source

The Ory Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features that are not in the open-source version. If your Clerk setup uses enterprise SSO connections or organizations, the open-source build will not cover them. Before you commit to a timeline, map each Clerk feature you use to Ory's open-source or Enterprise License tier, and get the license terms in writing from Ory.

OAuth client redirect mismatches

Each application registered with Hydra or a login flow expects exact redirect URIs, and a single trailing slash or changed subdomain produces a failed login. Clerk's allowed origins and redirect settings rarely match the new Ory configuration one for one. Export your current Clerk redirect list, recreate each client in Hydra, and test the full sign-in and sign-out loop on every domain, including mobile and staging environments.

Unplanned CVE patch exposure

Ory states that open-source deployments may have upgrade downtime and do not carry guaranteed CVE patching, while the Enterprise License includes timely CVE patches and support SLAs. Running an open-source identity stack that handles production logins means your team owns vulnerability monitoring, patch testing and emergency upgrades. Before go-live, agree who watches the Ory release notes, how fast a critical patch must be applied, and whether that effort or an enterprise license covers it.

Questions teams ask before moving from Clerk to Ory

How much effort does a move from Clerk to Ory take?

Effort depends mostly on how much login UI you must rebuild, how many user records and password hashes you migrate, and how many social, passkey and enterprise features your app depends on. Ory Kratos is API-first, so you build the login, registration, recovery and account screens yourself, which is the largest item because Clerk supplied those as prebuilt components. Migration work usually covers:

Exporting users and checking hash formats
Importing identities into Kratos and testing sign-in
Rebuilding the flows and wiring Hydra if you issue OAuth2 or OIDC tokens

Ask any implementation partner for a written scope that lists each of these items, and confirm with Ory which of your features are open source and which need the Enterprise License.

How long does the migration take, and what sets the timeline?

The timeline is set by the size of the UI rebuild, the number of features in use, and how much testing your users and security reviews require. No duration is supplied for this migration, so treat any figure you hear as a question to confirm in writing. Factors that lengthen the schedule include custom organization logic, enterprise SSO connections that need Enterprise License features, and a requirement to run both providers in parallel during cutover. A fixed-scope agreement lets you agree deliverables and dates before work starts.

What does the migration need from our internal team?

Your internal team needs to own the decisions that depend on your business: which login methods you keep, how accounts map to your data model, and what users see during recovery and account changes. Engineers must handle the frontend integration, database operations for Kratos (SQLite, PostgreSQL, MySQL or CockroachDB), and deployment in your infrastructure. Security and compliance staff should review the hash handling, session settings and audit evidence. Ask a provider to name the roles it expects from your side before you sign.

Can our own team do the Clerk to Ory move without outside help?

Yes, if your team already runs self-hosted services and has engineers comfortable building authentication UI from APIs. Ory Kratos and Hydra are Apache-2.0 licensed, so there is no license cost for the open-source path. The risk lies in the security-sensitive parts: password hash import, session handling, account recovery and OAuth2 configuration. Ory states that open source suits evaluation, development and deployments that accept occasional upgrade downtime and do not require guaranteed CVE patching. Weigh those terms against your own patching and uptime needs before deciding.

Do SAML and organization login require the Ory Enterprise License?

Yes, according to the Kratos README, SCIM, SAML, organization login (SSO) and CAPTCHAs are enterprise features not available in the open-source version. The Ory Enterprise License also covers Kratos multi-tenancy and organizations and the Hydra ROPC grant, plus support SLAs and timely CVE patches. If your Clerk setup uses enterprise SSO connections or organizations, confirm the exact feature list and pricing with Ory before you plan the move. Also check the Ory pricing page for current plan terms.

Can our users keep their passwords when we move from Clerk?

Often yes, but it depends on the hash format Clerk exports. Ory Kratos can import existing hashes in BCrypt, Argon2, MD5, SHA, SSHA, PBKDF2, SCrypt and several other formats. For formats other than BCrypt and Argon2, Kratos verifies the imported hash at sign-in and then moves the user to its configured hasher, so users do not reset passwords. If Clerk's export uses a format Ory does not support, Ory's documentation points to a password migration webhook as the alternative. Confirm the hash format in your export file before you commit to a plan.

What social and passkey login does Ory Kratos cover?

Ory Kratos supports passwords, passwordless codes, passkeys, social sign-in and multi-factor authentication such as TOTP, and it lets your team build the login UI. Social providers and passkey flows must be configured and tested against your own app domains and identity provider registrations. Confirm with Ory's documentation which social providers and passkey settings your target version supports, and test each login method with migrated accounts before cutover.

How DeployOpen scopes and runs the Clerk to Ory migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Ory inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a Clerk to Ory move, the written scope usually has to settle a few decisions before any code changes: which Ory components are in use (Kratos for identities, Hydra if you need OAuth 2.0 and OpenID Connect for your APIs or partners), which database Kratos will run on, where the export files are stored, and which login and account screens your app needs to rebuild. Most engagements are fixed-scope, so these items, the deliverables and the timeline are agreed in writing before work starts. Ongoing upgrades, CVE monitoring and continuous testing can be added as a retainer once the migration is live.

The scope should also name the features your team relies on that sit behind the Ory Enterprise License, such as SAML, organization login and multi-tenancy, because those decide whether the project runs on open source components alone or needs a commercial license. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for line items that separate license fees, infrastructure, data migration, frontend work, testing and support, and state which of them recur. Pricing will also depend on how many users, password hash formats and enterprise connections you need to carry across.

DeployOpen prepares systems, controls and evidence for compliance assessments, including configuration records, access reviews and test results, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Before you sign, confirm with your compliance lead which evidence the assessor will expect from the identity platform, and agree in the scope which of those artifacts DeployOpen will produce and in what form.

Migrate from Clerk to Ory