Supabase-Projekt in eine andere Region oder Organisation migrieren

Sie möchten ein produktives Supabase-Projekt in eine andere Region, Organisation oder Zielumgebung verschieben? WZ-IT bietet die Supabase-Migration ab 3.490 € nach technischer Einordnung des tatsächlichen Umzugs an.

Die Suchanfrage „Supabase-Projekt migrieren“ kann mehrere unterschiedliche Vorgänge meinen. Ein Organisationswechsel benötigt keinen vollständigen Datenumzug. Ein Regionswechsel, ein neues Projekt oder der Übergang zu Self-Hosting dagegen schon.

Der richtige Weg wird deshalb vor dem ersten Export eindeutig festgelegt.

Vier unterschiedliche Supabase-Umzüge

Die offizielle Supabase-Dokumentation unterscheidet Projekttransfer und Migration ausdrücklich. Ein Transfer verändert die Organisation, während Datenbankmigrationen unter anderem für Regions- oder Versionswechsel verwendet werden.

1. Projekt in eine andere Organisation übertragen

Wenn das Projekt selbst unverändert bleiben soll, ist ein Transfer der sauberste Weg. Typische Gründe:

• Übergabe vom Dienstleister an den Kunden
• Wechsel der abrechnenden Organisation
• Konsolidierung mehrerer Supabase-Organisationen
• Änderung von Team- und Zugriffsverantwortung

Vor dem Transfer werden Eigentümer, Rollen, Abrechnung, Marketplace-Abhängigkeiten, Integrationen und mögliche organisatorische Einschränkungen geprüft. Datenbankhost und Projekt-URL ändern sich dabei normalerweise nicht wie bei einem Neuaufbau.

2. Supabase-Region wechseln

Ein Regionswechsel bedeutet in der Regel ein neues Zielprojekt. Neben Latenz und Datenstandort verändern sich:

• Datenbankhost und Pooler-Endpunkte
• Projekt-URL und API-Schlüssel
• Auth- und OAuth-Callback-URLs
• Storage-Endpunkte und signierte URLs
• Edge-Functions-Endpunkte
• Netzwerkfreigaben und DNS
• Monitoring, Backups und Integrationen

Die Anwendung muss deshalb gegen das Ziel getestet und kontrolliert umgeschaltet werden.

3. Backup in ein neues Supabase-Projekt wiederherstellen

Supabase nennt abhängig vom Plan und Backupformat verschiedene Wege:

• Restore eines physischen Backups in ein anderes Projekt, sofern verfügbar
• Dashboard-Backup im Supabase-Format
• SQL-Backup und Restore mit der Supabase CLI

Der Datenbankrestore deckt Schemas und Daten ab. Je nach Verfahren werden Rollen und Supabase-interne Objekte unterschiedlich behandelt. Ein Testrestore zeigt, welche Nacharbeiten das konkrete Projekt benötigt.

4. Cloud zu Self-Hosted

Der Wechsel auf eigene oder verwaltete Infrastruktur ist der umfangreichste Pfad. Neben PostgreSQL müssen Auth-Konfiguration, Storage-Dateien, Functions, Secrets, SMTP, Domains, Monitoring und Backups übernommen werden.

Der vollständige Ablauf steht in Supabase Cloud zu Self-Hosted migrieren. Ein normaler projektinterner Restore darf nicht mit diesem Plattformwechsel verwechselt werden.

Was außerhalb des Datenbankbackups liegt

Unabhängig vom Zielprojekt werden gesondert erfasst:

• tatsächliche Storage-Objekte und Buckets
• Edge Functions und Deployments
• Function Secrets und externe API-Schlüssel
• OAuth-Provider und Callback-Konfiguration
• SMTP, E-Mail-Templates und Absender
• Custom Domains und DNS
• Webhooks und externe Automationen
• Observability, Alarmierung und Backupregeln

Ein vollständiger Datenbankrestore ist deshalb noch keine vollständige Projektabnahme.

Auth und aktive Sessions

Bei einem neuen Projekt ändern sich Projekt-URL und Schlüssel. Je nach Migrationsweg können Nutzerkonten übertragen werden, während aktive Tokens und Providerkonfiguration neu bewertet werden müssen.

Zu testen sind:

• Passwort- und OAuth-Login
• E-Mail-Verifikation und Passwort-Reset
• Redirect- und Callback-URLs
• Token Refresh und Logout
• MFA und SSO
• RLS mit den neuen JWTs

Eine geplante Neuanmeldung ist besser als unvorhersehbar ungültige Sessions nach dem Cutover.

Cutover ohne konkurrierende Schreibstände

Der finale Wechsel benötigt einen definierten Datenstand. Mögliche Vorgehensweisen:

• Wartungsfenster mit finalem Backup und Restore
• logische Replikation für kompatible PostgreSQL-Quellen
• anwendungsspezifischer Delta-Transfer
• schreibgeschützte Phase mit geordnetem Umschalten

Vor Freigabe werden Sequenzen, Mengen, Auth, Storage, Functions und kritische Nutzerwege geprüft. Das alte Projekt bleibt für das vereinbarte Rückfallfenster unverändert.

Projektidentität vollständig umstellen

Ein neues Projekt besitzt nicht nur einen anderen Datenbankendpunkt. Zu inventarisieren sind alle Stellen, an denen Projekt-URL, Publishable Key, serverseitiger Schlüssel, direkte Datenbankverbindung oder Pooling-Endpunkt verwendet werden. Dazu zählen Produktions- und Preview-Deployments, CI/CD, mobile Apps, Cronjobs, Webhooks, BI-Werkzeuge und lokale Entwicklungsumgebungen.

Die Umstellung erfolgt anhand einer Endpunktliste mit Verantwortlichem und Prüfschritt. Alte Schlüssel werden erst nach erfolgreicher Abnahme und Ablauf des Rückfallfensters widerrufen. Damit bleibt der Rückweg kontrolliert, ohne dauerhaft zwei aktive Projektidentitäten in der Anwendung zu hinterlassen.

Entscheidungshilfe

• Nur Eigentümer oder Abrechnung ändern: Projekttransfer prüfen.
• Region ändern: neues Projekt und vollständigen Cutover planen.
• Projekt duplizieren oder Version wechseln: passendes Backup-/Restore-Verfahren wählen.
• Infrastruktur selbst kontrollieren: Cloud-zu-Self-Hosted-Migration durchführen.

Die Supabase-Migrationscheckliste fasst die gemeinsamen Review-Gates zusammen. WZ-IT kann das Ziel anschließend als Managed Supabase betreiben.

Quellen

• Supabase: Migrating within Supabase
• Supabase: Transfer a project
• Supabase: Restore a Platform project to self-hosted