Supabase-Migrationscheckliste: von Discovery bis Cutover

Sie möchten die Checkliste nicht nur abhaken, sondern Migration, Generalprobe und Cutover aus einer Hand durchführen? WZ-IT bietet eine Supabase-Migration ab 3.490 Euro netto mit individuell geprüftem Umfang.

Eine Supabase-Migrationscheckliste verhindert, dass sich die Planung auf den PostgreSQL-Dump reduziert. Supabase verbindet Datenbank, Authentifizierung, Storage, Realtime, APIs und Functions. Eine Anwendung ist erst erfolgreich umgezogen, wenn diese Bausteine zusammen funktionieren und anschließend betrieben werden können.

Die folgende Checkliste eignet sich für Supabase Cloud zu Self-Hosted, projektinterne Umzüge und die Migration bestehender Datenbanken, Anwendungen oder Identitätssysteme zu Supabase.

Passenden Quellpfad wählen

Die gemeinsamen Review-Gates bleiben gleich, die technische Übertragung unterscheidet sich jedoch deutlich:

• Supabase Cloud zu Self-Hosted: vollständiger Plattformumzug mit Auth, Storage und Functions
• Supabase-Projekt oder Region wechseln: Transfer, Restore und neues Zielprojekt unterscheiden
• PostgreSQL zu Supabase: homogener Datenbankumzug mit Rollen, Extensions und Pooling
• AWS RDS oder Aurora zu Supabase: AWS-Netzwerk, Rollen, Replikation und Abhängigkeiten einbeziehen
• Heroku Postgres zu Supabase: Datenbank und PaaS-Komponenten sauber trennen
• Neon oder Vercel Postgres zu Supabase: Branches, Serverless-Treiber und Preview-Umgebungen abbilden
• MySQL oder MariaDB zu Supabase: Datenmodell und SQL-Dialekt nach PostgreSQL konvertieren
• Microsoft SQL Server oder Azure SQL zu Supabase: T-SQL, Routinen, Datentypen und Identitäten übersetzen
• Auth0 zu Supabase Auth: Nutzer, Passwörter, Provider, MFA, Rollen und Sessions migrieren
• Firebase zu Supabase: Firestore, Auth, Storage, Rules und Functions gemeinsam neu abbilden
• Lovable Cloud zu Supabase: Backend und generierte Anwendung kontrolliert entkoppeln

1. Discovery: den Ist-Zustand beweisbar machen

Zusätzlich werden erwartete Änderungen bis zum Cutover und laufende Releases erfasst. Ohne diesen Zeitbezug kann eine korrekte Bestandsaufnahme bereits vor der Migration veraltet sein.

2. Zielarchitektur und Betriebsmodell

• Ziel ist Supabase Cloud, Managed Hosting oder Self-Hosted
• benötigte Cloud-Funktionen sind im Ziel verfügbar oder ersetzt
• Entwicklungs-, Staging- und Produktionsumgebung sind getrennt
• Domain, TLS, DNS und Netzwerkwege sind geplant
• SMTP, OAuth-Provider und externe APIs sind vorgesehen
• Datenstandort und Zugriffswege sind dokumentiert
• Skalierungsgrenzen und Kapazitätsreserven sind bestimmt
• Betriebsverantwortung und Service Level sind geklärt

Self-Hosting bildet nicht jede verwaltete Supabase-Cloud-Funktion automatisch ab. Der Feature-Vergleich gehört daher vor die Terminplanung.

3. Recovery-Ziele und Abnahmekriterien

Vor der technischen Arbeit sollten RPO und RTO feststehen:

• RPO beschreibt den maximal akzeptierten Datenverlust.
• RTO beschreibt die maximal akzeptierte Wiederherstellungsdauer.

Daraus folgen Backup-Häufigkeit, Replikation, Wartungsfenster und Rückfallverfahren. Abnahmekriterien werden messbar formuliert, zum Beispiel:

• Zeilenzahlen je kritischer Tabelle stimmen überein
• alle Storage-Objekte sind übertragen und stichprobenartig lesbar
• jeder relevante Auth-Provider besteht Login und Logout
• unberechtigte Rollen scheitern in RLS-Negativtests
• kritische Nutzerwege funktionieren mit dem neuen Backend
• Backup, Monitoring und Alarmierung sind aktiv

4. Datenbank vorbereiten

• vollständiger Quell-Backup vor Beginn
• Versionen und Extensions im Ziel kompatibel
• Rollen, Ownership und Grants erfasst
• Funktionen und Trigger in Abhängigkeitsreihenfolge planbar
• große Tabellen und lange Imports identifiziert
• Sequenzen und Identitäten nach Import prüfbar
• fachliche Constraints und Referenzen testbar
• Änderungen zwischen Erstimport und Cutover berücksichtigt

Ein erfolgreicher Import ohne Fehlermeldung ist kein Konsistenznachweis. Kritische Abfragen, Fremdschlüssel, Sequenzen und fachliche Summen müssen verglichen werden.

5. Authentifizierung planen

• Nutzer, Identitäten und Provider vollständig inventarisiert
• Passwort-Hashes oder Reset-Verfahren geklärt
• JWT-Secrets und Session-Folgen bewertet
• Custom Claims und Rollen gemappt
• OAuth-Redirects für neue Domains vorbereitet
• SMTP, Absender und E-Mail-Templates getestet
• MFA- und Recovery-Wege berücksichtigt
• repräsentative Testkonten je Login-Art vorhanden

Ein erzwungener erneuter Login kann akzeptabel sein. Er darf nur nicht erst nach dem Cutover auffallen.

6. Storage separat migrieren

• Bucket-Konfiguration und Sichtbarkeit dokumentiert
• Objektzahl, Volumen und größte Dateien bekannt
• Download- und Upload-Verfahren getestet
• Content Types und Metadaten bleiben erhalten
• Storage-RLS ist im Ziel eingerichtet
• öffentliche, private und signierte URLs getestet
• Prüfsummen oder repräsentative Stichproben vorgesehen
• Anwendung verwendet die neuen Objektpfade

Die Supabase-Dokumentation weist ausdrücklich darauf hin, dass Datenbank-Backups die eigentlichen Storage-Objekte nicht enthalten.

7. Functions, Realtime und Secrets

• Function-Code ist versioniert
• alle Secrets sind bekannt und werden sicher übertragen oder rotiert
• externe Webhooks und Callback-URLs werden geändert
• Laufzeit und Dependencies sind im Ziel unterstützt
• Realtime-Kanäle und Replikation sind konfiguriert
• geplante Jobs und Trigger sind erfasst
• CORS und erlaubte Origins sind eingeschränkt
• Fehler, Logs und Timeouts sind beobachtbar

8. RLS und Zugriffsrechte

• RLS ist auf exponierten Tabellen aktiviert
• Grants und Policies passen zusammen
• anon, authenticated und serverseitige Rollen sind getrennt
• Mandanten- und Eigentümergrenzen sind getestet
• INSERT, SELECT, UPDATE und DELETE werden getrennt geprüft
• Views, Functions und Storage sind einbezogen
• Service-Schlüssel liegen nie im Browser
• Negativtests sind automatisiert oder dokumentiert

9. Anwendung und Integrationen

• neue Supabase-URL und öffentliche Schlüssel gesetzt
• serverseitige Schlüssel getrennt und geschützt
• Frontend und Backend neu gebaut oder ausgerollt
• API-, Function- und Storage-Endpunkte geändert
• OAuth- und E-Mail-Links zeigen auf die neue Domain
• Fehlerbehandlung und Token-Refresh getestet
• Monitoring oder Analytics erhalten neue Endpunkte
• alte Clients und Versionen sind berücksichtigt

10. Generalprobe

Eine Generalprobe verwendet einen aktuellen Quellstand und die geplante Zielarchitektur. Erfasst werden:

• Dauer jedes Exports und Imports
• manuelle Schritte und Wartezeiten
• Warnungen und Abweichungen
• tatsächliche Downtime
• Dauer der technischen und fachlichen Tests
• benötigte Zugänge und Entscheidungsträger

Das Ergebnis fließt in ein ausführbares Runbook mit Zeit, Verantwortlichem, Eingabe, erwarteter Ausgabe und Rückfallkriterium.

11. Cutover

• Beteiligte und Nutzer sind informiert
• Änderungen und Deployments sind eingefroren
• Quellsystem ist gesichert
• Schreibgrenze oder Wartungsmodus ist aktiv
• finaler Daten- und Storage-Abgleich ist abgeschlossen
• Ziel wird veröffentlicht und Anwendung umgestellt
• Smoke Tests und fachliche Tests sind bestanden
• Go/No-Go wird dokumentiert
• Rückfallfenster und Quellsystem bleiben erhalten

12. Betrieb nach der Migration

• Monitoring und Alarmwege sind aktiv
• Datenbank- und Storage-Backups laufen
• Restore-Verfahren ist dokumentiert und terminiert getestet
• Patch- und Upgrade-Prozess ist festgelegt
• Kapazität und Wachstum werden überwacht
• Secrets und temporäre Zugänge sind rotiert
• Betriebsdokumentation ist übergeben
• Altsystem wird erst nach Abnahme stillgelegt

Quellen

• Supabase: Cloud zu Self-Hosted übertragen
• Supabase: Plattform zu Self-Hosted wiederherstellen
• Supabase: Datenbank-Backups
• Supabase: Self-Hosted aktualisieren
• Supabase: Row Level Security