How to combine 2 Supabase projects?

[MichaelDeBoey]

Hi everyone! 👋

I'm looking for advice on combining two Supabase projects into one

• BC (target project) is the largest project, that uses RLS, uses Azure as the auth provider and doesn't use Supabase Storage
• IS (to be merged into BC) doesn't use RLS, uses the email auth provider (magic links) and uses Supabase Storage for user-uploaded images

The goal is to move all IS data into BC

I also would like to accomplish the following things:

• IS users should keep their accounts and data and shouldn't need to create a new account or lose access
• IS users must still be able to log in via magic links
• If an IS user and a BC user share the same email, I’d like to merge them into a single auth.users record to avoid having duplicate accounts
• IS also has its own users table where users.id is a FK to auth.users.id, so if users are merged we'd need to update those references as well

I’m aware that some level of re-authentication may be unavoidable, but I’d like to avoid recreating user accounts or breaking existing user–data relationships if possible.

I'm especially unsure about

• Best practices for merging auth.users (keeping magic link logins for IS, preserving Azure for BC)
• How to merge identities/user_metadata/app_metadata safely (which row to pick as canonical, what to copy/merge, ...)
• RLS gotchas: roles/claims/policies that must be transferred or adapted for imported users
• Recommended tools/approach for the storage migration when I copy IS's user image into BC storage while preserving paths/DB refs and access control

Any recommended patterns, tools or gotchas for doing this kind of merge?

Thanks in advance!

[R3Dzf]

Hi! I'd approach this as an identity migration plus data migration, rather than trying to merge both databases directly in one step.

The most important part is handling users who already exist in both projects.

Here's the approach I'd recommend:

1. Back up both projects first, and rehearse the migration on a staging project.
2. Build a mapping from each IS user ID to its intended BC user ID. If the person already exists in BC, retain the BC ID as the canonical identity. If not, plan how to import or create the user through a supported migration process.
3. For matching emails, don't automatically merge accounts based on email alone. Identity ownership needs to be verified, especially since one project uses Azure and the other uses magic links.
4. Migrate application records using the ID mapping, updating foreign keys consistently. Validate row counts and referential integrity afterward.
5. Migrate Storage buckets and files separately using supported Storage APIs or tooling. Copying database metadata alone won't migrate the actual image objects.
6. Enable the required Auth providers in BC, then carefully test the resulting login and account-linking flows.
7. Review RLS policies using both newly imported users and existing BC users before switching production traffic.

Supabase documents migration of Auth schema data, including password hashes, but merging that data into an already populated Auth schema is a different problem and needs conflict handling.

I'd strongly recommend doing a dry run with a few representative cases: an IS-only user, a BC-only user, and someone present in both.

These docs are useful starting points:

• https://supabase.com/docs/guides/troubleshooting/migrating-auth-users-between-projects
• https://supabase.com/docs/guides/platform/migrating-within-supabase

I'd be happy to help think through the user-ID mapping if you can share how your application tables reference auth.users.