Use case

Replace Clerk and the stack around it

AscendKit gives you Clerk-grade drop-in auth components and a hosted dashboard, and it keeps going where Clerk stops. The difference is not where the record is stored — AscendKit hosts it, the same as Clerk does. The difference is that it is one record. With Clerk you end up copying every user into Resend, Loops, and Typeform and keeping four copies in sync over webhooks. With AscendKit, auth, email, journeys, and surveys read the same usr_ profile, so there is nothing to sync and nothing to drift.

How it works

1. Install and configure
Add @ascendkit/nextjs, set your public key, and drop in the auth-card, login, and user-button components in place of Clerk's.
2. Get one user record instead of four
Users become usr_ profiles that auth, email, journeys, and surveys all read from. No webhook chain copying people between an auth vendor, an email vendor, and a survey vendor.
3. Import existing users
Migrate your current Clerk user base through the import path so accounts carry over without forcing a reset.

What does the migration actually involve?

Three things: swapping the auth components, importing your existing users, and deciding what happens to the tools bolted around Clerk. The third is the real work and the reason to do this at all.

The component swap is mechanical — AscendKit ships drop-in auth surfaces that replace Clerk's, and the sign-in flows your users see stay recognisable. The user import moves existing accounts so nobody is forced to reset a password or re-register.

The part worth planning is the webhook chain. If Clerk currently fires user.created into your backend, into Resend, and into a lifecycle tool, each of those consumers needs a decision: keep it pointed at AscendKit, or delete it because the thing it was synchronising no longer needs synchronising.

What changes, by component.
Piece	Before	After
Sign-in UI	Clerk components	AscendKit components
User records	Clerk	AscendKit, in Better Auth schema
Welcome email	Webhook into Resend	Same record, no webhook
Lifecycle sequences	Webhook into Loops	Journeys on the same record
Surveys	Separate tool, separate identity	Same record
Systems holding your users	4	1

Should you migrate at all?

Not if Clerk is working and you have no plans beyond authentication. Replacing a functioning auth provider is real risk for no gain, and consolidating vendors is not by itself a reason to touch something that works.

The moment it becomes worth considering is when you are about to add the third or fourth tool around Clerk and can see the webhook chain forming. Migrating before you build that chain is far cheaper than migrating after.

Be clear-eyed about what you are trading. Clerk is more mature with a larger ecosystem, and AscendKit is a smaller operation. What you get in return is one user record instead of four, and an auth layer built on Better Auth — open source, so the foundation outlives any vendor including us.

FAQ

Where do my users live after moving off Clerk?

On AscendKit, in a standard Better Auth schema — the same hosted arrangement you had with Clerk. What changes is that email, journeys, and surveys read that one record instead of each vendor holding its own copy.

Is AscendKit a smaller company than Clerk?

Yes, and that is worth weighing. AscendKit is built on Better Auth, an open-source library you can run yourself, and it stores auth data in Better Auth's own schema rather than a proprietary user model.

Can I migrate my existing Clerk users?

Yes. AscendKit has been used to migrate a live customer off Clerk via its user import path, so existing accounts move over rather than starting fresh.

Related guides

Moving off Clerk webhooks — the phased migration playbook and its failure modes.
AscendKit vs Clerk — the head-to-head, including where Clerk is the better choice.
How to leave AscendKit — the exit path from here, before you commit to the entrance.

Start with one API key

Auth, email, surveys, and journeys share one user record, so you ship this without stitching vendors together.

Start free