How to export your users from Clerk

How to export your users from Clerk before you move the login

Most teams start this work because of a renewal, a pricing change, a data residency requirement or a plan to avoid lock-in, and the first task is getting user records out of Clerk. What you can export depends on the export paths Clerk offers today, the file formats each path produces, whether password hashes are included, and your account's plan. Confirm all four in Clerk's current documentation and with Clerk before you plan a migration. This page does not assume export capabilities beyond what you verify, so treat each export path described below as a checklist item to confirm, not a settled fact.

Start by listing what you need to carry over. Users are the obvious part, but a working login also depends on organizations and memberships, custom metadata, and any enterprise SSO connections your customers rely on. Ask Clerk which of these the dashboard export covers, which ones require the Backend API, and whether the API returns them with pagination or rate limits that affect a large user base. Ask separately who on your team can run an export, which roles on the Clerk account have that permission, and whether an export is logged. For password hashes, request the hashing algorithm, the stored format and the conditions for inclusion in writing. If hashes are not available on your plan, plan now for a different path, such as password reset on first login.

Before you switch providers, check the export itself. Compare record counts in the file with the totals shown in the Clerk dashboard, and sample a set of accounts across different sign-in methods, including social, passkey and multi-factor users. Store the export in an encrypted location with access limited to the migration team, because password hashes are credentials even when they are not in plain text. Keep a dated copy of Clerk's documentation and your confirmed answers for the project record. The sibling pages on migrating to ZITADEL or Ory cover how to import these files and rebuild the login screens, and this page covers how to confirm that what you exported is complete enough to import.

Which Clerk data to export and what to confirm for each

This table lists each category of Clerk data a migration usually needs, the method that appears to cover it, the format to expect, and what to confirm with Clerk before you plan the switch. Use it as a checklist: the rows marked to confirm are where export gaps tend to surface, so verify them against your own plan tier and the current API reference before you start.

Data type	Export method to check	Expected format and what to confirm
User profiles	Dashboard export for the user list; API for full profile fields	Confirm which profile fields the dashboard file includes and whether the API returns the rest in a structured format.
Email and phone identifiers	Dashboard export; API for every identifier on each user	Confirm whether a user with several email addresses or phone numbers exports all of them, and which one is marked primary.
Password hashes	Dashboard export only if the file includes the hash column; otherwise ask Clerk support	Confirm whether hashes are included for your instance, the hashing algorithm used, and any plan or account conditions. Without hashes, users must reset passwords.
MFA and passkey enrollment	API or support request; the dashboard list may not show enrollment	Confirm whether TOTP secrets, backup codes and passkey credentials can leave Clerk at all. Most likely you will need users to re-enroll, so plan for that.
Sessions	Generally not exported; treat as non-portable	Confirm with Clerk that active sessions are not transferable. Plan for all users signing in again on the new provider.
Organizations and memberships	API (organizations and memberships endpoints in the API reference)	Confirm the endpoints, pagination behavior and the roles and membership fields returned. Map them to your target tenancy model before export.
Public and private metadata	API; dashboard may show only a subset	Confirm that both public and private metadata are returned for each user and organization, and whether large or nested values are truncated.
Enterprise SSO connections	Dashboard and API configuration views; export format to confirm	Confirm whether connection settings, certificates and metadata URLs can be exported. Most teams re-create these with the customer's identity provider admin.

Run the full export in sequence and verify each file

This sequence turns a set of ad hoc downloads into a complete, dated export set that you can count, check and reuse. Each file has a known source, a recorded count and a checksum, so the cutover team can prove what left Clerk before anything is imported elsewhere.

Confirm the Clerk plan and export options
The account owner or a Clerk administrator checks which export paths the current plan and the account's role permit, and writes down the dashboard export, any API endpoints the team can call, and whether password hashes are included. Confirm the answers with Clerk support or the current Clerk documentation rather than relying on memory or an older guide. The output is a short written note listing each export path, the person who will run it, and the credentials used for API calls.
Freeze or log user changes during export
Agree with product and support leads that sign-ups, profile edits, password resets, MFA changes and organization membership changes are either paused or recorded during the export window. Without this, the dashboard export and the API pulls can describe different states of the user base. The output is a change log, opened before the first export starts, that records any change made to users or organizations while the files are being produced.
Run the dashboard export and API pulls
Run the dashboard user export first, then pull organizations, organization memberships and user metadata through the Clerk Backend API using a script the team has reviewed. Record the exact time, the account, the API version and the script version next to each file. The output is a complete set of raw files, one for users, one for organizations, one for memberships and one for metadata, each named with the export date.
Store all files in restricted staging
Move every export into an encrypted, access-controlled staging location that only the migration team can read, with access logging turned on. Exclude these files from shared drives, chat attachments and developer laptops. The output is a staging path with a documented access list, and confirmation from the security owner that the files are not copied anywhere else.
Record counts and checksums for each file
Count the records in each file, including the number of rows in the CSV and the number of objects in any JSON or NDJSON output, and compute a SHA-256 checksum for each file. Store the counts and checksums in a manifest file kept beside the exports. The output is a manifest that lets anyone later confirm that a file has not changed since it was produced.
Compare counts with the Clerk dashboard
Compare the user, organization and membership totals in each file with the figures shown in the Clerk dashboard at the time of export. Investigate any gap before continuing, and check the change log for changes made during the window that explain it. The output is a reconciliation sheet showing each total, the dashboard figure, the difference and the reason for any difference.
Spot-check sample records
Pick a small set of records and trace each one through every file. Include a user with MFA enabled, a user who signs in through an enterprise connection, and a member of an organization with a non-default role. Check that identifiers, email addresses, organization links and metadata match across files. The output is a signed-off sample sheet with each record's identifier, the fields checked and the result.
Confirm password hash format before cutover
Before any cutover, identify the hash algorithm and format the export contains, then confirm with the target platform's documentation or a test import that it can verify those hashes without forcing a password reset. If the target cannot read the format, stop and decide on a migration path such as just-in-time migration or forced resets before users are moved. The output is a written compatibility result, with a test login from a sample account, that is filed with the export log.
Keep a dated export log
Maintain a single export log that records each step, the person responsible, the time, the files produced, the manifest location and any issue found and how it was resolved. Keep the log with the staging files for as long as your data retention policy requires. The output is a dated record that auditors, the project owner and the target platform team can all read to see how the export was produced.

How the export format shapes the import for each target

ZITADEL documents migration guides from Auth0, Keycloak, Firebase and another ZITADEL instance, and it describes approaches such as just-in-time migration. Clerk is not among the named source platforms, so the mapping from a Clerk export is your work. Clerk's user records must land in ZITADEL's model of instances, organizations and projects, and that choice determines how logins, roles and grants behave after cutover.

Instance and organization mapping: Decide whether your users sit in one instance with an organization per customer, or in separate instances for full data isolation. Each Clerk organization needs a matching ZITADEL organization, and each project groups the applications and roles those users need.
Just-in-time migration: Consider moving users at first login instead of in a single bulk load. Confirm with ZITADEL how a just-in-time flow verifies a password against a hash exported from Clerk before you depend on it.
Password hash format: Confirm which hash algorithm and parameters your Clerk export uses, and whether ZITADEL's import path accepts them without a reset. If it does not, plan for forced password resets or passwordless enrollment.
Enterprise connections: Map any Clerk enterprise SSO connections to ZITADEL identity provider settings for each organization, since each customer organization can use a different identity provider.

Before committing, import a sample of users into a staging instance and test a login with a migrated password, a user with organization membership and a federated login.

Keycloak imports and exports realms as JSON files using the kc.sh export and kc.sh import commands. The Keycloak server guide warns that this process has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. The realm file is therefore a migration artifact, and you should create and load it inside a planned maintenance window rather than treating it as routine backup.

Realm mapping: Map your Clerk application and organization structure to a Keycloak realm. Decide whether customer organizations become Keycloak organizations or separate realms, and check which users, clients and roles the realm JSON actually carries.
Node shutdown: Plan a window in which every Keycloak node is stopped while the export or import runs. Confirm the steps against the server guide for your version, including what changes in a clustered deployment.
Password hash format: Confirm whether the realm JSON accepts pre-hashed credentials from Clerk, and which algorithm and iteration settings Keycloak expects. If the format does not match, users will need a password reset at first login.
Backup limits: Keep a separate export from the Clerk side and a tested restore path, so the realm file is not your only copy of user data.
Federation sources: If an LDAP or Active Directory server stays the system of record, decide how it interacts with imported users, since that changes what you import and what you keep in sync.

Before committing, import the realm into a non-production Keycloak, stop and restart nodes as your runbook describes, and test a password login, an OIDC client and a SAML client.

What the Clerk export may leave out and how to work around each gap

A user export carries profiles and, depending on the tool, some credentials, but many identity-related items sit outside it. Each card below names one gap, the workaround that usually fits, and what to confirm in Clerk's documentation before you rely on it.

Password hashes and other credentials

The dashboard CSV is described as including hashed passwords, but you should confirm that the hashes are present for every user, the hashing algorithm is recorded, and users who signed up only through social or passwordless login have no hash at all. Where a hash is missing or unsupported by your target, plan a forced password reset at first login or a just-in-time migration that verifies the old credential against Clerk on the first sign-in.

MFA secrets and passkey registrations

TOTP seeds, backup codes and registered passkeys are bound to the provider that issued them and are rarely included in a standard profile export. Expect to ask each user to re-enroll MFA and register a passkey on the new system, and to keep a short window where support staff can verify identity before resetting a second factor. Confirm with Clerk whether any factor data can be exported at all before you plan the cutover.

Active sessions and tokens

Session cookies, refresh tokens and API keys issued by Clerk do not move with the user list, so every signed-in user will be logged out at cutover. Plan the switch for a low-traffic window, communicate the expected sign-in step to users, and revoke Clerk-issued API keys after your applications point at the new issuer. Confirm how Clerk handles session revocation so no old token remains valid after you stop using it.

Enterprise connection secrets and certificates

SAML signing certificates, OIDC client secrets and directory sync credentials configured in Clerk for customer SSO are not part of the user export. Each enterprise customer must supply its identity provider metadata again, and your admins must re-create the connection in the new system and test it with a pilot account. Ask each customer to confirm the metadata URL and attribute mapping before the switch date.

Custom integrations and webhook data

Data that your app copies to other systems through Clerk webhooks, such as a billing customer ID or a CRM contact stored against a user, lives outside Clerk's user records. Inventory every webhook endpoint and every place your code stores a Clerk user ID, then decide whether to remap those IDs to the new subject identifiers. Replay or backfill events only after you confirm which webhook payloads Clerk retains and for how long.

Files and assets tied to users

Profile images, uploaded documents and other files attached to users may be stored in Clerk or in your own storage with only a reference in Clerk. Check which assets Clerk hosts, download them through its documentation or API, and update the stored URLs in your application. Keep a manifest that maps each user to each file so you can verify the count after the move.

Who should run the export and how to protect the files

The people who run the export should be the same people who verify it, and each file they produce should have one named owner. Start by confirming with Clerk, and with your own identity team, which roles in your Clerk account can open the dashboard export and which can call the API endpoints that pull organizations and metadata. Clerk's role names and their exact permissions can change, so take them from Clerk's current documentation or from your account contact rather than from memory or from this page. Record who holds those permissions before the export starts, because the export will contain personal data and, depending on what your Clerk configuration returns, password hashes that an attacker could try to crack offline.

Treat every export file as sensitive from the moment it is created. Store it on an encrypted volume or in an encrypted repository with access limited to a short named list of engineers, and do not send it through email, chat or a shared drive folder. Keep API tokens used for pulls in your secrets manager, not in scripts or shell history. Log who created, opened, copied and transferred each file, using your storage system's audit trail or a simple signed record kept by the owner. Set a deletion date tied to cutover and to the end of your verification window, and delete the files and any temporary copies on that date, then record the deletion. Confirm your retention obligations with your legal or privacy team before you set that date.

Assign a second reviewer to check the export before it is used. The reviewer should not be the person who ran it. They can compare record counts against the Clerk dashboard, sample a set of accounts, and confirm that the files they reviewed are the same files that were later imported. A second reviewer also catches a common failure: a file that looks complete but was exported from the wrong environment or without the fields the new provider needs. Agree the review steps in writing before the export runs, so the verifier is not asked to improvise.

What to plan before the Clerk contract ends

The export file is only one step in leaving Clerk. The cards below cover the calendar, the parallel run, application cutover, user communication, deletion of data held by Clerk and the approvals needed for the new platform. Check every date against your own Clerk agreement, since notice periods and data deletion terms are set there and not on this page.

Start the export early

Work backward from the notice period in your Clerk agreement, not from the renewal date you expect. Export users, organizations and metadata at least once well before any deadline so you have a full snapshot to test against. A later export can be taken again at cutover to pick up users who signed up in the meantime. Ask Clerk whether the dashboard export and API output match, and confirm whether password hashes are included for your plan tier.

Plan a parallel-run period

Decide how long both providers serve logins before Clerk is switched off. During this window, new sign-ups may land in either system, so you need a rule for which one is authoritative for each user. Define how you will detect users present in one system but not the other, and who signs off that the two user sets reconcile before Clerk access ends.

Map DNS and redirect changes

List every application, callback URL, allowed origin and webhook that depends on Clerk's domains. Each OIDC client on the new platform needs its redirect URIs registered before cutover, and any DNS record that points a custom login domain at Clerk must be changed in a controlled window. Keep old redirect URIs working until the parallel run is closed so that in-flight sessions do not fail.

Communicate credential and MFA resets

Users whose passwords cannot be imported, or whose multi-factor enrollment does not carry over, will need a reset or re-enrollment step. Write the message, the support path and the expected steps before cutover. Sending the notice early, with a clear date and a help contact, reduces help desk load on the switch day. Agree with your security team which fallback verification is acceptable for users who cannot prove identity.

Request deletion of data held by Clerk

Once the export is verified and the new platform is live, ask Clerk in writing to delete the user data it holds, and record the request and confirmation for your compliance file. Check your agreement for retention periods, backup handling and what Clerk keeps for billing or legal reasons. Keep your own copy of the verified export under the same retention and access controls as the source data.

Secure budget and approvals

Get written approval for the target platform's running costs before the parallel run begins. Costs include the infrastructure, the database such as PostgreSQL, backups, staff time for operations, and any paid support or migration help. Ask each vendor or partner for a quote based on a written scope, and confirm which items are one-time and which recur each year. Identify the approvers early, including security, privacy and finance.

Common questions about exporting users from Clerk

Can our own team export users from Clerk without outside help?

Usually, yes. A team member with dashboard access can start the export without outside help, and the export itself is the smallest step. Confirm in Clerk's current documentation which dashboard role is required and whether your plan changes what the export contains. The harder part is checking the file, mapping its fields to the target system and testing real logins. Bring in an implementation partner if your team lacks an owner for verification, the import or the cutover. A fixed-scope engagement can cover those steps in writing before any work starts.

How much effort do the export and verification take?

The export takes little time, but verification scales with what the file carries. The main drivers are:

User count, since larger files need more sampling and more import test runs.
Custom metadata fields, which each need a target attribute or a documented decision to drop them.
Organization memberships and enterprise connections, which must be rebuilt in the new system.
Hash format, because the target must accept the algorithm Clerk used before users can keep their passwords.

Ask any provider to price these drivers separately in the quote, so you can see which items your data actually triggers.

Does the dashboard CSV include organizations and user metadata?

The dashboard CSV is designed for user records, so organizations, memberships and metadata usually need a separate pull through Clerk's API. Confirm in Clerk's API reference which endpoints return organization data, membership roles and the public and private metadata on each user. Export these as structured data and keep the user IDs consistent across both files, because a mismatch breaks memberships after import. Record every field you export, its source endpoint and the date you pulled it, so the verification step has a clear baseline to compare against.

How long does a Clerk user migration take?

No duration can be stated from the research available here, so ask for milestones in the quote instead of a single number. The timeline depends on the number of applications that depend on Clerk sessions, how many organization and enterprise connection decisions remain open, whether password hashes import cleanly on the first test, and how many verification cycles your security reviewers require. It also depends on change windows for production cutover. Ask for a written schedule with a named deliverable for each phase, and check which parts depend on your team's availability.

What work does the migration need from our team?

Three roles from your team carry most of the work. An identity owner decides which users, organizations and connections move, and signs off on the field mapping. An application engineer updates the login code, session handling and any calls to Clerk's SDK, and tests each application against the new provider. A security reviewer checks how password hashes are stored during the move, how the export file is handled and deleted afterward, and whether MFA re-enrollment meets your policy. Name these people before the quote, because open decisions usually stall the schedule.

Will our users' Clerk password hashes move to the new system?

The dashboard export includes hashed passwords, so the hashes can be carried over, but whether they work depends on the target. Check the algorithm and format recorded in the export against the import options of your target system, then test with a sample of accounts before the full run. ZITADEL's migration guides describe approaches such as just-in-time migration, which can be a useful fallback. If a hash cannot be imported, the affected users will need a password reset, so plan that message in advance.

What happens to MFA and passkeys during the move?

Passkeys cannot be exported as they are, because the private key stays on the user's device or authenticator, so each user must register a passkey again with the new provider. Authenticator app secrets and SMS factors also usually do not move in a standard export, so confirm with Clerk exactly what its export omits. Plan a re-enrollment flow that verifies identity before a factor is reset, because a reset path is a common route for account takeover. Your security reviewer should approve this flow before cutover.

What does a fixed-scope migration engagement cover from DeployOpen?

A fixed-scope engagement from DeployOpen covers the work agreed in a written scope before it starts, including the deliverables and timelines. For this migration, that scope would typically cover planning the export and field mapping, verifying the exported data, configuring the target self-hosted platform, testing logins and documenting the result. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance reviews, but independent auditors and certification bodies issue any audit report. Ongoing support and upgrades are available as a separate retainer.

How DeployOpen scopes and delivers a Clerk exit

DeployOpen approaches a Clerk user export as one step in a fixed-scope migration that runs inside your own infrastructure. We agree in writing what is exported, how it is checked and where the data lands before any work starts, so the export is tested against the target platform rather than trusted on its own.

How we scope

Inventory which Clerk data you need: users, hashed passwords, organizations, memberships and metadata.
Confirm who in your Clerk account holds the rights to run the dashboard export and API calls.
Agree the target platform, hosting location and the written deliverables before any export runs.

How we build

Run the export in a controlled way and store the files in your own environment with restricted access.
Build import scripts and test them against a staging instance of the chosen open-source platform.
Check record counts, field mappings and password hash handling against the source before any cutover.

How we hand over

Document the export procedure, field mapping and validation results so your team can repeat them.
Deliver a checklist showing which records were verified, which were excluded and why.
Transfer administration of the target platform to your staff with written runbooks and access records.

How we support

Engagements are fixed-scope, and changes to scope are agreed in writing before further work.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask us to confirm during scoping which parts of the export depend on Clerk plan tiers or support requests.

How to export your users from Clerk