When in doubt, talk to us. Migrations can get complex, and we’d love to help
guide you through them. You can set up a call with us
here
If you don’t want to migrate yet, but want to take advantage of Dynamic on top of your existing provider, you can also use our Third Party Authentication feature.

Migration Path A: You only have a front-end “connect wallet” flow
Common scenarios
You built your own front end wallet connector or use Rainbowkit/ConnectKit. There is no SIWE, no issuing JWTs, and mostly just a front end.Recommended approach
You pretty much just swap out the modals. If you use wagmi, add our wagmi connector and follow our rainbowkit guide, but in general, no migration needed. After the initial update to the Dynamic modal, you can stay on our connect-only mode and not store any user info with Dynamic, or alternatively start adding more sophisticated features.Migration Path B: You store wallet info somewhere and a wallet is a user
Common scenarios
You built your own front end wallet connector or use Rainbowkit/ConnectKit, and in addition implemented a SIWE on your own, authenticating users and creating sessions for them.Recommended approach
For front end changes, you can follow path A above. In addition, you can use our create wallet endpoint to generate users and add wallet records to them. When they first log in, they will verify wallet ownership via SIWE (we provide that and return a JWT - you don’t need to do this), and you’re done.Migration Path C: You have users, but no embedded wallets
Common scenarios
You use Auth0, Firebase or another web2 user management system, or alternatively created something on your own. You store your users’ emails and basic info.Recommended approach
You’ll need to import your users into Dynamic- Bulk upsert your users into Dynamic, including their info capture/kyc information and their data
- For any profile information that Dynamic does not yet explicitly support, you can add these in the user.metadata, which is a key-value object
- When they log in, we verify their emails
Migration Path D: You have users, and they have embedded EOA wallets
Common scenarios
You use an embedded wallets provider, or have built a simple KMS-based key management system on your ownRecommended approach
There are really two options here:- Keep current users in their existing embedded wallets and generate Dynamic wallets for new users
- Migrate existing wallet users to Dynamic
- Switch to Dynamic auth
- When user logs in with email, check if they have an existing account:
- If so, redirect them to old login flow
- If they don’t, create a Dynamic-powered embedded wallet for them
- You’ll need to import your users into Dynamic (the previous section)
- When a user logs in, check if they have a wallet in the previous system
- Check if wallet was ever used/is empty
- If it isn’t, prompt user to transfer funds to new Dynamic wallet (this can feel like an account upgrade flow for the users)
- Next time that the user logs in, they go to their Dynamic wallet
Migration Path E: You have users, and they have AA wallets
Considerations
- Your users have an EOA embedded wallet, but it only serves as a signer for an AA layer (safe, zerodev etc).
- Hence, you’ll want to add the Dynamic-powered embedded wallet as a second signer to the AA layer, or alternatively swap signers from the old embedded wallet one to the Dynamic one
This is non-trivial, and we recommend that we chat before starting this
process. You can book time here