BPSI France — Migration Base44 → Supabase

Kontext

BPSI France plant Büroausbauten an mehreren europäischen Standorten. Ihre Plattform (Marketing-Seite + Karriere + Case Studies + Kundenbereich) lief auf Base44, einem proprietären Backend: starke Abhängigkeit, wenig Kontrolle über die Daten, wachsende Kosten und Lock-in.

Ziel: volle Kontrolle über den Stack zurückgewinnen — Daten, Auth, E-Mails, Deploy — ohne die Produktions-Seite oder ein Firmen-Postfach jemals lahmzulegen.

Technische Herausforderung

• 113 Base44-Referenzen über den Anwendungscode verteilt — komplett entfernen.
• Datenmodell (Stellen, Case Studies, Profile) auf Postgres neu aufbauen — mit sauberen Access-Policies (RLS).
• Migration ohne Downtime: die alte Seite musste durchgehend erreichbar bleiben.
• E-Mail-Falle: die Domain trägt aktive Postfächer (Titan) — eine fehlerhafte DNS-Änderung hätte sie gelöscht.

Lösung

• Datenmodell neu aufgebaut: 7 Postgres-Tabellen + Row Level Security, echte Daten re-importiert (offene Stellen, Case Studies, Profile).
• 8 Edge Functions (Supabase) für API, Sitemap, Assets und Mail-Versand.
• Angebotsformular an Resend angebunden (transaktionale E-Mail).
• Frontend Vite + React, statisch auf Cloudflare Pages deployt.
• Progressiver DNS-Cutover (A/CNAME chirurgisch geändert, MX/SPF/TXT unangetastet) → keine E-Mail verloren, alte Seite als Netz, keine Downtime.

Ergebnis

• 113 Base44-Referenzen → 0. Kompletter Ausstieg aus dem proprietären Backend.
• Migration in 8 sauberen Commits ausgeliefert, Staging end-to-end verifiziert.
• Unternehmens-Postfächer erhalten (Titan-Risiko dokumentiert, kein Postfach angerührt).
• Deploy-Handoff schriftlich: Kommandos, Sofort-Rollback-Plan, Checkliste.

Learnings & Trade-offs

• Das echte Risiko einer Migration ist nicht der Code, sondern DNS und E-Mail. Die meiste Sorgfalt floss in einen reversiblen Cutover, nicht ins Refactoring.
• Jeden irreversiblen Schritt vor der Ausführung dokumentieren — und vor einer gefährlichen Checkbox innehalten können.