How to Migrate Lovable Auth Users to Supabase and Keep Their Passwords

Why user ids and password hashes must stay identical

Your tables refer to people by id: profiles.user_id, orders.customer_id, and so on. If a user gets a new id in the new project, every one of those references points to nobody. Copy the id exactly.

Passwords are stored as bcrypt hashes in encrypted_password. Copying the hash means the old password keeps working. If you cannot copy hashes, the only alternative is to send a password reset email to everyone.

Step 1: Export auth users from Lovable Cloud

1. 1Open the SQL editor

   In Lovable, open the Cloud area and the SQL editor.

   

2. 2Run the export query

   Run the query below and export the result as a CSV file.

   SQL: export users Copy

   select id, email, encrypted_password, email_confirmed_at,
          raw_user_meta_data, raw_app_meta_data, created_at
   from auth.users
   order by created_at;

Step 2: Migrate Lovable auth users into the new Supabase project

Each user needs a row in auth.users and, for email sign-in, a row in auth.identities. The identity row stores the provider (email), the provider id (the user id as text) and an identity_data JSON object with sub, email and email_verified.

Set aud and role to authenticated, keep email_confirmed_at so users do not have to confirm again, and use empty strings for the token columns, because current Supabase Auth expects them not to be null.

The migrator tool does this in batches of 50 users, uses on conflict do nothing so you can re-run safely, and retries one user at a time if a batch fails, so one bad row never blocks the rest.

Step 3: Handle triggers and profile tables

Many apps have a trigger that creates a profiles row whenever a user is inserted into auth.users. If you also import a profiles CSV, you can end up with duplicates or a duplicate key error. Decide which source wins: either let the trigger create profiles and update them from the CSV afterwards, or disable the trigger while you import and enable it again.

Also remember that any table with a foreign key to auth.users(id) needs the users to exist first. If you hit a foreign key error, see the troubleshooting guide.

Step 4: Re-enable social and other providers

Only email and password accounts can be copied this way. Providers such as Google need to be set up again in Authentication → Sign In / Providers in your Supabase dashboard, with your own OAuth credentials. See the Supabase Auth docs for each provider.

Users who signed in with Google before will have no password hash, so import them as users without an email identity and let them sign in with Google again once the provider is on.

Test the migration

• Sign in with a real existing account and its old password.
• Check that the user's data (orders, profile, posts) shows up.
• Request a password reset email to confirm your email settings work.
• Compare the user count in both projects.

Frequently asked questions

Related guides