Move a production Supabase project to another region, organisation or target through a tested process. WZ-IT provides a Supabase migration from €3,490 after identifying the actual type of move.
The query “migrate Supabase project” can describe several different operations. An organisation change does not require a complete data move. A region change, new project or transition to self-hosting does.
Choose the correct path before creating the first export.
Four different Supabase moves
| Objective | Appropriate base path |
|---|---|
| Another Supabase organisation | Transfer the existing project |
| Another Supabase region | Create and migrate to a new project |
| New project for version or isolation | Restore or CLI-based project move |
| Customer-controlled infrastructure | Complete Cloud-to-self-hosted migration |
The official Supabase documentation explicitly separates project transfer from migration. Transfer changes the organisation, while database migrations can support region or version changes.
1. Transfer a project to another organisation
When the project itself should remain unchanged, transfer is the cleanest path. Typical reasons include:
- handover from a service provider to the customer
- change of billing organisation
- consolidation of multiple Supabase organisations
- change of team and access responsibility
Review owners, roles, billing, Marketplace dependencies, integrations and organisational restrictions. The database host and project URL normally do not change as they would in a rebuild.
2. Change the Supabase region
A region change usually means a new target project. In addition to latency and data location, the following change:
- database host and pooler endpoints
- project URL and API keys
- Auth and OAuth callback URLs
- Storage endpoints and signed URLs
- Edge Function endpoints
- network controls and DNS
- monitoring, backups and integrations
Test the application against the target before a controlled switch.
3. Restore into a new Supabase project
Depending on plan and backup format, Supabase documents several paths:
- physical backup restore into another project where available
- dashboard backup in Supabase format
- SQL backup and restore using the Supabase CLI
Database restore covers schemas and data. Roles and Supabase-internal objects behave differently depending on the method. A rehearsal reveals the required project-specific remediation.
4. Cloud to self-hosted
Moving to managed customer-controlled infrastructure is the broadest path. PostgreSQL, Auth configuration, Storage files, Functions, secrets, SMTP, domains, monitoring and backups all need attention.
See migrate Supabase Cloud to self-hosted for the complete process. Do not confuse a normal project restore with this platform move.
What lives outside the database backup
Regardless of the target, inventory separately:
- actual Storage objects and buckets
- Edge Functions and deployments
- Function secrets and external API keys
- OAuth providers and callback configuration
- SMTP, email templates and senders
- custom domains and DNS
- webhooks and external automation
- observability, alerts and backup policies
A complete database restore is therefore not complete project acceptance.
Auth and active sessions
A new project changes project URL and keys. Accounts may transfer depending on the method, while active tokens and provider configuration need renewed assessment.
Test:
- password and OAuth login
- email verification and password reset
- redirect and callback URLs
- token refresh and logout
- MFA and SSO
- RLS with the new JWTs
A planned sign-in is preferable to unpredictable session invalidation after cutover.
Cut over without competing write states
The final move requires a defined data state. Options include:
- maintenance window with final backup and restore
- logical replication for compatible PostgreSQL sources
- application-specific delta transfer
- read-only phase followed by a controlled switch
Before release, verify sequences, counts, Auth, Storage, Functions and critical user journeys. Keep the old project unchanged through the agreed rollback window.
Replace the complete project identity
A new project changes more than the database endpoint. Inventory every place that uses the project URL, publishable key, server-side key, direct database connection or pooler endpoint. This includes production and preview deployments, CI/CD, mobile applications, cron jobs, webhooks, BI tools and local development environments.
Switch them through an endpoint register with an owner and verification step for each consumer. Revoke the old keys only after acceptance and the rollback window. This preserves a controlled return path without leaving two active project identities embedded in the application indefinitely.
Decision guide
- Only owner or billing changes: assess project transfer.
- Region changes: create a new project and plan full cutover.
- Project copy or version change: choose the appropriate backup and restore path.
- Infrastructure control is the goal: run a Cloud-to-self-hosted migration.
The Supabase migration checklist combines the shared review gates. WZ-IT can operate the target as managed Supabase.
