Migrate from Clerk to Better Auth

You shipped with Clerk, and it worked. Then the bill, the lock-in, or the "your users live in someone else's database" feeling pushed you to look at Better Auth. Searching for how to migrate from Clerk to Better Auth usually lands you on a script dump or a comparison post. This guide is the project plan: what moves, what breaks, which strategy fits, and how to cut over without guessing.

Still deciding if you should leave Clerk at all? Read Better Auth vs Clerk vs NextAuth vs Supabase Auth first, then come back here when the decision is migrate.

Why teams leave Clerk for Better Auth

Clerk is a hosted auth product. Better Auth is a self-hosted TypeScript library. The migration is really a change of ownership model.

That last row is why this topic shows up next to SaaS starters: kits like TurboStarter already ship Better Auth wired to your database, so greenfield skips this migration entirely.

Cutover vs dual-run: pick before you write a script

Do not start with migrate-clerk.ts. Start with session strategy.

Clerk itself documents the same two shapes when people migrate into Clerk (export/import vs trickle). The reverse trip uses the same tradeoffs. Val Town's public write-up on leaving Clerk for Better Auth used a two-week dual-run: every auth-aware endpoint accepted either cookie until traffic drained off Clerk (Val Town blog).

Decision rule: if a full re-login on deploy day is acceptable (email announcement + OAuth one-click), use cutover. If you need sessions to die of old age, dual-run.

What actually migrates (and what does not)

Clerk can export user data from the Dashboard (Settings → User Exports → Export all users). That CSV includes hashed passwords for email/password users (Clerk: migrating / exporting users). You can also pull rich user records from the Backend API for OAuth links, images, ban flags, and more.

Ignore blog posts that claim "Clerk never exports password hashes." Clerk's own docs say the Dashboard export includes hashed passwords. The catch is algorithm mismatch (bcrypt vs Better Auth's default scrypt), not missing digests.

Prerequisites

Before any import:

1. A Postgres (or other) database Better Auth can own
2. Better Auth installed and schema migrated (npx auth migrate or your Drizzle generate/migrate flow)
3. Same OAuth apps (Google, GitHub, etc.) with new callback URLs pointing at Better Auth routes
4. Email provider ready for verification / reset (you own that now)
5. Staging clone of production user export for a dry run
6. Inventory of every place you call auth() / currentUser() / Clerk middleware

If you need drop-in screens after the server move, pair Better Auth with Better Auth UI or start from a Next.js Better Auth template.

How to migrate from Clerk to Better Auth (cutover)

This follows the official guide's shape. Use their full script as the source of truth; customize for your adapters and plugins.

import { betterAuth } from "better-auth";
import bcrypt from "bcrypt";

export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    password: {
      hash: async (password) => bcrypt.hash(password, 10),
      verify: async ({ hash, password }) => bcrypt.compare(password, hash),
    },
  },
});

Dual-run extras (if cutover is too sharp)

If you choose dual-run:

1. Ship Better Auth routes and UI behind the same app
2. Make new sign-ins create Better Auth sessions only
3. Teach every auth gate to accept Clerk session or Better Auth session
4. Optionally nudge users (banner, soft re-auth on sensitive actions)
5. Watch Clerk MRU / active session metrics until residual traffic is tiny
6. Export remaining inactive users, import, then delete Clerk codepaths

This is more engineering than the official script. Treat it like a temporary compatibility layer with a kill date, not a permanent abstraction.

Organizations, IDs, and other sharp edges

Organizations. Better Auth's guide does not migrate Clerk Organizations today. If you use B2B orgs, export memberships separately and map them into the Organization plugin tables, or rebuild org invites after cutover. Budget this as its own milestone.

Foreign keys. Apps that treated Clerk as the user table often have clerk_user_id columns everywhere. Prefer preserving IDs on import, or run a one-shot remap before flipping reads.

Rate limits and sync debt. If you already mirrored Clerk users into Postgres via webhooks (common once you hit API rate limits on profile reads), decide which row is canonical after cutover. Better Auth should become the sole writer for auth fields.

Email and abuse. You now own verification, password reset, and rate limiting. Wire those before removing Clerk's hosted flows.

Mobile / extension. Shared-session products need the new auth origin and cookie strategy on every client. TurboStarter's web, mobile, and extension docs assume one Better Auth backend; a Clerk migration that stops at Next.js middleware is incomplete if you ship those surfaces.

When a starter beats DIY migration

Migrating auth is only worth it if the destination stack is the one you want long term. If you are also rewriting billing, orgs, admin, and marketing pages, cloning a kit that already uses Better Auth + Drizzle can be cheaper than a six-week auth-only project.

TurboStarter ships Better Auth on web (and shared patterns for mobile/extension), with MFA, OAuth, and organizations already wired. Use this guide when you have an existing Clerk production app. Use the kit when you are starting over or spinning up the next product and do not want to earn the migration scars twice.

FAQ

Migrating from Clerk to Better Auth is a data job plus an application rewrite of every auth boundary. Get the strategy right, preserve bcrypt passwords from Clerk's export, dry-run the official import script, then swap middleware and UI with your eyes open about sessions and organizations. Do that once, cleanly, and you own the identity layer for the rest of the product.