Lovable Cloud to owned Supabase

Move the app without losing auth, RLS, Storage, or Data API reachability.

A migration can look finished after schema, data, and auth users move over, then still fail at launch because the frontend points at the wrong backend, generated migrations depend on dashboard defaults, Storage overwrite policies are incomplete, or role-matrix tests were skipped.

The cutover risk is not just export and restore.

The brittle part is proving the rebuilt app behaves the same when Lovable Cloud is no longer the backend boundary.

Keep raw credentials, private repositories, customer records, payment records, screenshots from private dashboards, and real user data out of public comments and out of the preflight packet. Use redacted table names, flow names, policy summaries, and migration notes.

Minimum migration.md launch gate

1. Backend ownership

Identify whether production, preview, and local builds use Lovable Cloud, the owned Supabase project, or a mixed state.

2. Auth transfer

Record first-login evidence, profile foreign-key behavior, session refresh behavior, and fallback if transferred accounts fail.

3. Migration replay

Run a disposable rebuild or local reset so missing grants, broken policies, and generated revokes surface before launch.

4. Storage paths

Check bucket names, object-path ownership, public URL rewrites, and overwrite behavior for avatar or profile-image flows.

5. Role matrix

Test no-session, anon, authenticated owner, wrong owner, and service-path behavior without broad make-it-work grants.

6. Frontend switch

Verify deployed environment variables, old URL removal, rollback plan, and smoke tests after pointing the frontend at the new backend.

Lovable MCP handoff checks

Lovable MCP can make migration discovery faster, but it should not become the launch proof by itself. Treat each MCP action as a live account action that needs a redacted evidence trail before production traffic moves.

  • Record whether the source backend is Lovable Cloud or an owned Supabase project before reading migration notes.
  • Use MCP output only as inventory until a clean Supabase rebuild, auth smoke test, Storage test, and role matrix prove the new backend.
  • Map which tool or human step changed schema, data, policies, environment variables, project visibility, and deployment state.
  • Review database-query output as sensitive by default; keep connection strings, keys, user rows, hashes, private screenshots, and customer data out of public packets.
  • Confirm the final app uses the intended Supabase URL and anon key in deployed, preview, and local environments.

Source-backed constraints

These docs are why the checklist separates ownership, MCP access, and launch evidence.

When the free preflight is enough

  • You only need a structured checklist for your own migration notes.
  • You can safely redraft the generated migration and smoke tests yourself.
  • The packet has no launch-blocking gaps after role, grants, and Storage checks.

When a second pass is worth $25

  • The app is close to launch and the packet still has several missing evidence blocks.
  • Auth, profiles, Storage, Data API grants, or frontend target switching are unclear.
  • You want one concise Markdown report with severity, likely failure mode, and launch smoke tests within 24 hours.

Start with public, no-login materials

These pages do not connect to Supabase and do not need secrets. The paid path stays behind the scoped checkout page after the fixed scope is clear.