# Migrating to Openfort Migrating from one auth and embedded wallet provider to another involves moving users, wallets, and assets. This guide covers migration strategies depending on your use case. At the end, you'll find tips and techniques to ensure the migration goes smoothly. :::tip Migrations can get complex. You can [book a call with us](https://cal.com/joalavedra) for guidance. ::: :::info If you don't want to migrate yet, but want to start using Openfort alongside your existing provider, you can evaluate our SDK independently or run both providers in parallel during a transition period. ::: Use this flow chart to identify the right migration strategy: ![Migration guide decision flow](https://www.openfort.io/images/blog/migration_fd640f8de5.png?updated_at=2026-01-23T12:41:58.681Z) ## Migration path A: You only have a front-end "connect wallet" flow You built your own front-end wallet connector or use Rainbowkit/ConnectKit. There is no SIWE, no issuing JWTs, and mostly a front end. ### Recommended approach Swap out the modals. If you use wagmi, Openfort integrates with your existing setup through the [wagmi connector](/docs/products/embedded-wallet/react/wallet) and the [Rainbowkit guide](https://www.openfort.io/blog/migrate-from-rainbowkit). After the initial update, you can stay on connect-only mode and not store any user info with Openfort, or start adding features like gas sponsorship and session keys. ## Migration path B: You store wallet info somewhere and a wallet is a user You built your own front-end wallet connector or use Rainbowkit/ConnectKit, and implemented SIWE on your own, authenticating users and creating sessions for them. ### Recommended approach For front-end changes, follow path A above. In addition, use the [Create User API endpoint](https://openfort-xyz.github.io/swagger-api-doc/#/accs%20v2/createAccountV2) to generate users and add wallet records to them. When they first log in, they verify wallet ownership via SIWE (Openfort provides that and returns a JWT), and the migration is complete. ## Migration path C: You have users, but no embedded wallets You use Supabase, Firebase, or another user management system, or created something on your own. You store your users' emails and basic info. ### Recommended approach Import your users into Openfort: 1. **Bulk import your users** - Use the Openfort API to create user records, including their profile information and any captured data. 2. **Store additional metadata** - For any profile information that requires custom fields, you can add these to the user metadata object. 3. **Seamless re-authentication** - When they log in via Openfort, their email addresses or social login credentials are verified independently as part of the auth flow, and a JWT is issued upon successful login. When your users log in again, Openfort verifies their identity and issues secure tokens. ## Migration path D: You have users, and they have embedded EOA wallets You use an embedded wallets provider such as Privy or Turnkey, or have built a simple KMS-based key management system on your own. ### Recommended approach **Two options:** 1. Keep current users in their existing embedded wallets and generate Openfort wallets for new users 2. Migrate existing wallet users to Openfort **Keep current users:** 1. Switch to Openfort auth 2. When user logs in with email, check if they have an existing account: * If so, redirect them to old login flow (for legacy users with assets) * If they don't, create an Openfort-powered embedded wallet for them ## Migration path E: You have users, and they have smart wallets (accounts) Your users have an EOA embedded wallet, but it only serves as a signer for an smart account (7702, Safe, ZeroDev, Thirdweb,and so on). You need to add the Openfort-powered embedded wallet as a second signer to the AA layer, or swap signers from the old embedded wallet to the Openfort one. Hence, you’ll want to add the Openfort-powered embedded wallet as a second signer to the smart account, or alternatively swap signers from the old embedded wallet one to the Openfort one. :::tip This is non-trivial. [Book a call](https://cal.com/joalavedra) before starting this process. ::: ## Extra migration techniques and tips ### Asset transfers If your users have assets in their existing embedded wallets, ensure they move those to their new Openfort-powered embedded wallets. Build a migration flow for your users using your own UI to prompt asset transfer, or provide instructions to transfer assets manually. ### Webhooks As you import your users into Openfort, you can notify other systems and take further action with webhooks. Available events include `user.created`, `user.updated`, `wallet.created`, and more. Set them up by providing a URL to post to in the [Openfort Dashboard](https://dashboard.openfort.io/webhooks) and selecting which events to subscribe to. See the [webhooks guide](/docs/configuration/webhooks) for details. ## Provider-specific migration guides Select the guide based on your current provider for detailed, step-by-step instructions: ## What you gain with Openfort After migration, you'll have access to Openfort's full feature set: