Skip to content
Deepak Gupta markCIAM Compass

Transformation pattern

Replacing homegrown authentication with a modern CIAM

Updated 2026-07-19

This is a composite, anonymized pattern drawn from common transformations, not a single named customer. It illustrates the shape of the change and typical outcomes, not specific measured results.

Starting state

  • Custom-built authentication with bcrypt password hashes
  • No MFA beyond optional TOTP, no enterprise SSO
  • Growing security and maintenance burden on the app team

Trigger for change

  • An enterprise deal blocked on SSO and audit requirements
  • A near-miss credential-stuffing incident
  • Leadership decision to stop maintaining undifferentiated auth

Constraints

  • No forced password reset for the existing user base
  • Zero-downtime login during the migration
  • Preserve existing user IDs so links and sessions keep working

Architecture choice

  • Adopt a managed CIAM as the new source of truth
  • Import portable bcrypt hashes; lazy-verify anything non-portable
  • Keep an identifier mapping from legacy IDs to new subject IDs

Rollout plan

  1. 1

    Coexist

    Stand up the CIAM alongside the legacy store; no user impact yet.

  2. 2

    Dual-run

    Route new signups to the CIAM; migrate existing users lazily on next login.

  3. 3

    Drain

    Monitor the migrated-vs-remaining tail; nudge dormant users to log in.

  4. 4

    Cutover

    Flip the app to the CIAM as sole IdP; decommission the legacy store.

Typical outcomes

  • MFA and enterprise SSO available without app-team maintenance
  • No mass password reset and no login downtime during migration
  • Security and audit burden shifted to a purpose-built platform

Lessons learned

  • Inventory password-hash formats before committing to a timeline
  • Lazy migration beats big-bang for any sizable user base
  • Keeping identifier continuity avoids a long tail of broken links

Build it: blueprints

Go deeper

FAQ

How long does a homegrown-to-CIAM migration take?
It varies with user-base size and hash portability, but the phased approach, coexist, dual-run with lazy migration, then cutover, avoids downtime and lets you drain the long tail at a safe pace rather than racing a deadline.
What's the biggest risk in this migration?
Forcing a mass password reset or a big-bang cutover. Both are avoidable: migrate hashes or lazy-verify on login, and keep identifier continuity so existing sessions and links don't break.