Migrate Users From an Existing Auth Source to PropelAuth

Want to use AI to assist in migrating to PropelAuth? Check out the PropelAuth Integration MCP Server for installation instructions.

If you switch your auth provider, there are a few major considerations to take into account.

For example:

• I have user IDs already persisted in my database, how can I maintain those IDs?
• How can I allow my users to keep their existing password?
• Some of my users have 2FA enabled, how do I make sure they keep it enabled?
• Can I test the migration before committing to it?

Ideally, there's no user impact and a simple API to use. Luckily, we have a simple API that you can use to migrate your users. Each of our backend libraries has an API wrapper that you can use called migrateUserFromExternalSource.

Migration Guides

We have a few guides to help you migrate your users from some of the most common auth providers. If you don't see your auth provider listed, please reach out to support@propelauth.com.

Migrating from Auth0

Migrate your users and organizations from Auth0 to PropelAuth.

Migrating from Clerk

Migrate your users and organizations from Clerk to PropelAuth.

Migrating from Cognito

Migrate your users and groups from AWS Cognito to PropelAuth.

Migrating from Firebase

Migrate your users from Firebase to PropelAuth.

Migrating from Supabase

Migrate your users from Supabase to PropelAuth.

CSV Import

Alternatively, we also offer a CSV import option to assist in importing your users. Navigate to the Users page in your PropelAuth dashboard and click Import to get started.

Running into issues? Click Download Example CSV to check how the CSV is expected to be formatted.

Linking user IDs

Our migration API also takes in the user's existing ID, and we will present a legacy_user_id everywhere alongside our user_id. This allows you to use the legacy_user_id whenever it's present and fallback to new user_ids for any user created after the migration.

Maintaining users' passwords

Passwords should never be stored in plaintext or any recoverable form. Our migration API doesn't take in a password; it takes in a password hash. We support BCrypt, Argon2, and PBKDF2 hashes, and by providing your user's password hash, they will be able to log in with their existing password. Here is a full list of our supported password hashing algorithms as well as an example of each hash:

• pbkdf2_sha256
  Format: pbkdf2_sha256$iterations$salt$hash
  Example: pbkdf2_sha256$60000$hNHNc0pi50Y71rRZRGi$izM2CPlczdLCfc690vKXsI0+O0NYtScKpvBPL4=

• pbkdf2_sha256_b64- This is the same as pbkdf2_sha256 but the salt is base64 encoded. This is an option for frameworks like .NET that have binary data as their salt.

  Format: pbkdf2_sha256_b64$iterations$salt$hash
  Example: pbkdf2_sha256_b64$10000$3d1bed5b21$ohZ+ZinTWu+6jLIZvyyqH78XoJl0aW8q4zbS1vvuD0Q==

• pbkdf2_sha512
  Format: pbkdf2_sha512$iterations$salt$hash
  Example: pbkdf2_sha512$10000$3d1bedb5b21$ohZ+ZinTWu+6jLIZvyyqH78yXoJl0aW9M8q4zbS1vvuD0Q==

• bcrypt
  Format: $version$cost$salt+hash
  Example: $2b$10$DqQ/afxHqWiG5a/YriRyceNv30qHq4rNkyj2uZX0McrdUv5YBTLcW

• argon2id
  Format: $argon2id$version$parameters$salt$hash
  Example: $argon2id$v=19$m=16,t=2,p=1$WVZE5LekxLZ2JCdmozdA$dpsMxfUopSZPDgITQ

Maintaining MFA

Our migration API also optionally takes in a base32 encoded MFA secret. If you pass one in, we'll enable MFA for your user's account automatically, and their existing MFA device's codes will work just like they currently do.

[Migrating SAML / SSO Connections](https://docs.propelauth.com/migrations# migrating-saml-sso-connections)

We're working on some tools to make this easier. In the meantime, please reach out to support@propelauth.com so we can help!

Testing the migration

All this works in both your production and test environments, allowing you to test the migration before fully committing to it.

Questions?

Have any questions or need any help with your migration? Don't hesitate to reach out at support@propelauth.com