Migrate from another provider
Side-by-side migration guides for teams moving to Synq from a different identity provider. Each guide is written so an engineer unfamiliar with Synq can land on it cold and ship a complete integration in one sitting.
| From | What to read |
|---|---|
| Auth0 | Universal Login → branded hosted UI, Rules/Actions → webhooks + custom claims, Roles → product-side enums, gradual dual-issuer rollout. |
| Clerk | <ClerkProvider> → <SynqProvider>, <UserButton> → roll your own with useUser(), organization model differences, custom claims. |
| NextAuth / Auth.js | The fastest migration in this list — auth() is the same name. One-page line-by-line replacement of the configure-once lib/synq.ts. |
| WorkOS | Connections → Brand Connections, Directory Sync (SCIM) → Directory API + webhooks, AuthKit → branded hosted UI, multi-tenant ergonomics. |
What they all have in common
Three mental-model translations recur in every migration. Internalize these first and the guide pages will be 80% review:
Hosted UI
Auth0 has Universal Login, Clerk has its hosted components, NextAuth
has provider buttons in your own app, WorkOS has AuthKit. Synq has
a per-Brand branded hosted login surface. Your client_id maps
to a Brand; the Brand’s logo, colors, sign-in providers, copy, and
domain are configured in the Synq dashboard. There is no “Powered
by Synq” footer.
Session model
Most of the above ship some flavor of “server session + httpOnly
cookie”. Synq ships the same — @synqid/nextjs puts the session in
an iron-session encrypted cookie holding the access token + ID
token; @synqid/js lets you bring your own storage. The
Sessions and tokens chapter is the
canonical reference.
Authorization
Auth0 has Roles + Permissions, Clerk has organization roles, NextAuth
encourages callbacks that add a role to the session, WorkOS has
Roles. Synq deliberately does not model permissions. Your product
defines its own permission enum, your product fetches its own
permission set on every request (or caches it server-side), and
Synq’s requireAccess(predicate) runs whatever check you give it.
Why: identity and authorization are different jobs, conflating them
forces every customer’s authorization rules into one library’s
mental model. Two seams cleaner than one.
If the lack of built-in roles surprises you, read the
requireAccess section
of the Next.js SDK page first — the seven-line predicate that
replaces a five-key middleware config is usually the click.
Common timeline
A typical migration runs 1–2 sprints end to end. Rough breakdown:
| Phase | Time |
|---|---|
| Set up Synq Org + Brand + App, dual-issuer middleware | half a day |
| Migrate the auth surface (login route + handler + provider) | 1–2 days |
| Migrate authorization (Roles → permission predicates) | 1–3 days |
| Migrate Rules / Callbacks / Webhooks | 1–2 days |
| Production cutover | half a day |
Gradual rollout via a feature flag is the path we recommend. Every migration page below opens with the dual-issuer middleware that accepts both your old and the Synq access tokens during the cutover window so you can flip clients independently.
Not seeing your provider?
The translations in these guides cover ~95% of cases for Supabase Auth, Stack Auth, Better-Auth, Kinde, Ory, Descope, and Stytch as well. If you’re migrating from one of those and want a guide, reach out — we’ll prioritize.