Migrate from another IAM

Moving to Avnology ID from an existing identity provider is a two-step migration:

1. Users — import the provider's user export with avnology migrate <provider> --import users.json. The import preserves each user's external ID so re-running is idempotent.
2. OAuth clients + redirect URIs — re-create your client applications on Avnology ID and update redirect URLs in-place.

Provider guides

• Auth0 — bulk user import, Actions → Hooks, tenant → org mapping.
• Clerk — user export, Clerk components → @avnology/id-elements.
• Firebase Auth — password hash compatibility, social provider remap.
• Amazon Cognito — user pool export, app client migration.

The avnology migrate CLI

Every provider guide walks you through the same three commands:

Imports are idempotent: the provider's original user ID becomes the external_id on the Avnology identity, so re-running the same export is a no-op.

What does NOT migrate automatically

• Session tokens — users must sign in once after cutover. Plan a dual-write window or accept a forced re-auth.
• Custom domains / DNS — you'll point your custom auth domain at Avnology's infrastructure separately.
• Email + SMS templates — recreate them under Branding in the dashboard.
• Webhook endpoints + secrets — new secrets are minted when you register a webhook on Avnology.
• MFA enrollments — users enroll again after first sign-in (TOTP, SMS, passkeys).

Cutover pattern

Most teams follow the same staged cutover:

1. Day 0 — Import users in a read-only side-by-side environment. Verify a few logins via the Avnology hosted sign-in page.
2. Day 1-7 — Dual-write mode: new users are created on Avnology AND the legacy system, so a rollback is still cheap.
3. Cutover day — Flip DNS / load-balancer rules so all new traffic hits Avnology. Existing sessions may fail over at their next refresh.
4. Day 30 — Decommission the legacy provider. Export final audit logs first.