Migrate from Stytch

Move Stytch Consumer or B2B authentication to Authdog while preserving user/member IDs and organization access. This guide covers export, authentication-method mapping, passwords, organizations, staged cutover, rollback, and validation.

Prerequisites

• An Authdog tenant, project, and environment for staging rehearsal.
• Stytch API access to list users or members, organizations, authentication factors, roles, SSO connections, and relevant settings.
• An inventory of every Stytch SDK, project ID, session validator, webhook, redirect URL, and machine-to-machine client.
• A decision on whether Consumer or B2B records map to one or multiple Authdog projects/environments.

Migration shape

1. Inventory and export — capture users/members, organizations, factors, roles, and connections.
2. Map and import — retain stable Stytch IDs and recreate access.
3. Parallel run — validate cohorts while Stytch still serves production.
4. Cut over and retire — switch clients and APIs, soak, then revoke Stytch credentials.

1. Inventory Stytch

Record account lock/deletion state, invitations, trusted metadata, MFA policy, callback/logout URLs, webhook consumers, and code that branches on Stytch-specific claims.

2. Export users, members, and organizations

Use Stytch's supported list/search APIs with pagination. Retain:

• Stytch user_id for Consumer users or member_id for B2B members
• Email addresses and phone numbers with verification state
• Name, status, trusted/untrusted metadata required by your app
• Authentication factor/provider identifiers exposed by supported APIs
• B2B organization_id, organization settings, memberships, and roles
• Created and last-authenticated timestamps

Store source user/member ID as the Authdog external identifier. For B2B, keep stytch_organization_id → Authdog organization ID mappings. Do not key migration joins on email, organization slug, or domain.

Password and authenticator strategy

Confirm export capabilities with Stytch and Authdog before promising password continuity:

• Compatible hash import — only when full hash material, parameters, and encoding are exportable and accepted by Authdog.
• Progressive migration — validate once against Stytch through a secure server-side bridge, then establish the Authdog credential.
• Reset/passwordless — use reset, magic link, OAuth, or SSO when hashes cannot be moved.
• Re-enrollment — plan new passkey/TOTP enrollment unless explicit portable credential support is confirmed.

Magic-link and OTP records are ephemeral and should not be migrated. Never log raw passwords, OTPs, recovery codes, or authenticator secrets.

3. Map organizations, roles, and identities

For B2B, create Authdog organizations before members. Translate Stytch roles and permissions to Authdog roles, preserving organization scope and testing users who belong to multiple organizations. Map organization authentication policies deliberately rather than flattening them into one environment-wide rule.

Recreate OAuth and SAML/OIDC connections using Authdog callback/ACS URLs. Configure provisioning for directory-managed users and preserve deactivation semantics. Authdog links identities by verified email; test duplicate addresses, unverified identifiers, and members represented separately across organizations.

4. Import and update applications

Import through console tooling or the REST Directory API:

1. Upsert profile and verified identifiers.
2. Set Stytch user/member ID as external identifier.
3. Attach required metadata and suspend inactive users.
4. Create organization memberships and mapped roles.
5. Record password and MFA migration state.

Replace Stytch client SDK methods and UI with Authdog (quickstarts), configure the environment public key (pk_...), and update redirects. Backends must validate Authdog sessions instead of Stytch sessions. Rewrite checks for Stytch user_id, member_id, organization_id, roles, and custom claims. See Backend requests.

5. Stage cutover and rollback

1. Rehearse Consumer or B2B export/import and every used sign-in method in staging.
2. Capture a baseline, then reconcile new users, organization changes, and role deltas.
3. Move internal users and one small organization/application cohort.
4. Keep temporary dual-issuer validation instrumented and time-boxed.
5. Monitor sign-in failures, duplicate identities, MFA enrollment, org routing, and authorization.
6. After soak, disable Stytch callbacks and new sign-ups, revoke secrets, and remove old session validation.

Rollback: send affected cohorts back to Stytch while fixing mappings. Keep source IDs stable and avoid concurrent membership writes unless a tested reconciliation process exists.

Validation checklist

• Consumer users or B2B members reconcile with expected totals.
• Every Stytch source ID and organization mapping is retained.
• Password path succeeds without assumed hash compatibility.
• MFA/passkey re-enrollment is tested where required.
• Organization memberships, roles, and policies pass access tests.
• OAuth, SSO, SCIM, callbacks, and logout work end-to-end.
• Backends and webhooks use Authdog session/user shapes.
• Delta reconciliation and rollback are tested.
• Stytch credentials and dual-issuer code are removed after soak.

Related

• Users
• Organizations
• Permissions
• Authentication
• Provisioning