Moving a Supabase project into another Supabase project sounds simple until you sit down to actually do it. There is more than the database to move: auth users, storage files, secrets, Edge Functions, cron jobs, and every application config that references the old project. This guide walks through what serious teams plan before touching production.
Why teams migrate Supabase projects
Teams migrate Supabase projects for a range of reasons: consolidating environments, splitting a shared project into per-tenant projects, moving between organizations, switching regions for latency or compliance, or promoting a staging project to production. Whatever the reason, the migration crosses several subsystems that were never designed to move together.
What needs to move
A Supabase-to-Supabase migration typically covers seven surfaces:
Database schema
Tables, views, functions, triggers, policies, extensions, and enums. Recreate the schema on the destination before importing data so foreign keys, RLS, and defaults behave the way the app expects.
Table rows
Row data has to arrive in dependency order. Serial and identity sequences need to be reset after import so new inserts do not collide with existing IDs.
Auth users
Users, identities, and hashed passwords are the trickiest surface. Preserve user IDs so foreign keys and RLS policies in the destination still match. Never regenerate IDs unless the app never referenced them.
Storage buckets and files
Recreate bucket configuration (public flag, allowed MIME types, size limits) before copying objects. File paths inside a bucket usually need to be preserved so signed URLs and app references keep working.
Secrets and environment variables
Anything the app or Edge Functions reads from the environment needs a matching value on the destination. Missing keys are the most common cause of a broken post-migration deployment.
Edge Functions
Function code, imports, and per-function secrets. Functions frequently depend on service role keys or third-party API keys that must be copied over intentionally, not assumed.
Cron jobs and scheduled tasks
Scheduled invocations that live in pg_cron or in the platform scheduler need to be recreated with the new URLs and secrets.
Common migration risks
- Auth IDs get regenerated and every foreign key relation breaks silently.
- Sequences are not reset and the first insert conflicts with existing rows.
- Storage files are copied but bucket public/private flags are not.
- Edge Function secrets are missing on the destination.
- Cron jobs continue running on the old project during cutover.
- No rollback plan exists, so any error requires manual recovery.
Recommended pre-migration checklist
- Snapshot the source project's schema, data, and storage inventory.
- Provision the destination project and confirm plan limits.
- List every secret and environment variable the app reads.
- List every Edge Function and its dependencies.
- Freeze schema changes on the source during the migration window.
- Prepare rollback: keep the source project running and read-only.
Why validation matters before running migration
A validation pass on the destination confirms schema parity, checks for name collisions, verifies that required extensions exist, and flags secrets that are still missing. Running validation before any write is the difference between a controlled migration and an emergency.
Rollback planning
Rollback is not just "restore a backup." A rollback-aware migration tracks every created row, bucket, and function so it can be undone or the migration can be re-run without duplicating data. Plan how to point the app back at the source in minutes, not hours.
How Miglify helps
Miglify is a migration control center for Supabase and other modern SaaS platforms. It analyzes the source project, validates destination readiness, tracks each migration job across schema, data, auth, storage, secrets, and Edge Functions, and produces a report so teams understand exactly what moved and what still needs attention.
Final thoughts
A Supabase-to-Supabase migration works when it is planned as a workflow, not a single command. Split the work by surface, validate before writing, keep a rollback path open, and log everything you touch. The teams that treat migration as an engineering project ship them without downtime.
Miglify keeps every step observable — analyze source, validate destination, and prepare rollback-aware runs before you cut over.