API Integration · SaaS

Forma
HR.

Auth0 restructured their pricing in 2023 and Forma's auth bill went from $600 to $3,800 a month overnight. We migrated 47,000 users to Clerk — zero forced password resets, zero downtime, full MFA preservation, per-account rollback capability at every step.

Client
Forma HR
Year
2024
Type
API Integration
Stack
Auth0 · Clerk · Next.js · PostgreSQL · LaunchDarkly
Timeline
5 weeks
01 — The Problem

A 6× Price Increase.
47,000 Users in the Way.

Forma is a B2B HR platform — time tracking, leave management, and compliance workflows for mid-market companies. Authentication was handled by Auth0. In mid-2023, Auth0 (now Okta) revised their pricing model, reclassifying Forma's plan in a way that increased their monthly bill from $600 to $3,800 — a 533% increase with 60 days' notice.

Migrating away from Auth0 meant moving 47,000 active users, 200+ business accounts, 18 enterprise SSO connections, and years of stored MFA configurations — without a single user needing to reset their password or re-enrol their authenticator app. HR software can't have planned downtime. It was used around the clock across four time zones.

$3,200/month overnight

Auth0's pricing restructure turned a predictable $600 line item into a $3,800 expense with 60 days' notice.

47,000 users to migrate

Any solution requiring a forced password reset was a non-starter — support volume would have been unmanageable.

18 enterprise SSO connections

SAML and OIDC configurations for Google Workspace and Microsoft Entra across 18 accounts — each needing a precise re-wiring.

Zero downtime tolerance

HR software is used during payroll runs, onboarding, and compliance deadlines. A maintenance window would have had real business consequences for Forma's clients.

Core insight

The migration risk wasn't technical — Clerk supports bcrypt hash import and TOTP re-enrolment via API. The risk was operational: 200 accounts, any one of which could report auth failures post-cutover. The solution was making rollback instant and per-account, so the worst case for any single customer was 60 seconds of disruption, not a full incident.

02 — The Approach

Four Principles
That Shaped the Migration.

01

Migrate credentials server-side, not via user action

Asking 47,000 users to reset their passwords or re-enrol MFA would have generated thousands of support tickets and damaged trust. Clerk's import API accepts Auth0's bcrypt hashes and TOTP secrets directly — users never knew anything changed.

→ 99.2% of MFA users completed the migration without any interaction. The 0.8% who needed the fallback re-enrolment link were enterprise accounts with hardware key configurations.
02

JWT bridging over big-bang cutover

Replacing the auth provider instantly would have invalidated every active session. The 30-day JWT bridge let existing sessions expire naturally — mobile clients, API integrations, and cached browser sessions all continued working without being forced to re-authenticate.

→ Validated against Forma's mobile app session data. 94% of active sessions refreshed within 7 days — the bridge window was sized to cover the remaining 6%.
03

Per-account cutover, not per-user

Migrating users individually across all accounts simultaneously would have created an unmanageable rollback surface. Migrating one business account at a time meant a problem in Account A had no effect on Account B — and rollback was a single flag flip.

→ All 200+ accounts migrated over three weeks with a team of two. Zero accounts required rollback.
04

Feature flags over code deployments for rollback

Rollback via code deployment takes 3–5 minutes even on fast CI. LaunchDarkly flags flip in under one second. For a production auth migration, the difference between a 60-second recovery and a 5-minute outage is the difference between a non-event and an incident report.

→ LaunchDarkly was the most expensive line item in this project. It was also non-negotiable.
03 — How It Works

Inside the
Migration.

01

Audit and mapping

A full export of Auth0 user data was performed: user IDs, email addresses, password hashes (bcrypt), MFA enrollment status, TOTP secrets, and per-account metadata. Every active SSO connection — Google Workspace and Microsoft Entra for 18 enterprise accounts — was documented with the exact SAML/OIDC configuration. This audit became the migration checklist.

Auth0 Management APIPostgreSQLTypeScript
02

Clerk org structure setup

Forma is multi-tenant — each business customer is a separate account with its own users, roles, and SSO configuration. Clerk's Organizations model maps to this directly. Each Forma account was pre-created as a Clerk organisation before any user migration began, with roles replicated from Auth0's permissions model.

Clerk APITypeScript migration scripts
03

Password hash import

Auth0 bcrypt password hashes were imported directly into Clerk using their user import API, which accepts external password hashes with algorithm specification. Users migrated this way log in with the same password on the new system — no reset, no friction. Clerk re-hashes on first login to their own standard.

Clerk User Import APIAuth0 user export
04

MFA migration

TOTP secrets exported from Auth0 were re-enrolled in Clerk via the API — not through a user-facing re-enrolment flow. Enterprise users with hardware keys or backup codes received a targeted email explaining the migration with a one-click re-enrolment link as a fallback. 99.2% completed silently; 0.8% used the fallback.

Clerk MFA APIAuth0 TOTP exportResend (email)
05

JWT bridging period

During migration, both Auth0 and Clerk tokens were valid. Custom middleware in Forma's Next.js app inspected incoming JWTs, identified the issuer, and routed to the correct validation path. This meant users on old tokens (mobile clients, cached sessions) weren't logged out mid-migration. The bridge ran for 30 days.

Next.js MiddlewareAuth0 JWKSClerk JWKSLaunchDarkly
06

Per-account cutover with rollback

Each business account was migrated individually, controlled by a LaunchDarkly feature flag. If an account reported auth issues post-cutover, the flag was flipped back to Auth0 in under 60 seconds with no code deployment. All 200+ accounts were migrated over three weeks — zero required rollback.

LaunchDarklyClerkAuth0
04 — Results

Numbers Worth
Shipping For.

0
Forced password resets
0
Minutes of downtime
87%
Reduction in monthly auth bill
3wks
All 200+ accounts migrated
05 — Key Decisions

Calls Worth
Explaining.

Clerk
over Supabase Auth
benefitClerk's Organizations model matched Forma's multi-tenant structure exactly — each business account maps to a Clerk organisation with its own users, roles, and SSO. Supabase Auth has no native multi-tenancy; Forma would have needed to build and maintain their own.
tradeoffClerk is more expensive than Supabase Auth at Forma's user volume. The multi-tenancy fit made it the right call — but it's worth pricing out Supabase + custom tenancy at the 100K user mark.
LaunchDarkly
over an in-house flag system
benefitProduction auth migrations are not the place to trust a homegrown flag system. LaunchDarkly's sub-second propagation, audit log, and instant rollback were worth the cost. We've seen in-house flag systems add 30-second propagation delays in production — that's a long time when an account can't log in.
tradeoffLaunchDarkly adds a vendor dependency and a non-trivial per-seat cost. For a post-migration steady state, a lighter solution (Unleash, GrowthBook) could replace it once the risk window closes.
30-day JWT bridge
over immediate cutover
benefitForma's mobile apps are not force-updated. A significant portion of active sessions on any given day are from users who haven't opened the app in weeks. An immediate cutover would have invalidated these sessions and generated a wave of "can't log in" support tickets.
tradeoffRunning two auth providers simultaneously added 30 days of operational complexity — two JWKS endpoints, two token validation paths, and two places to check when debugging an auth issue. Worth it for the zero-disruption outcome.