Migrate from Lovable Cloud with AI (Two Routes, Zero Panic)

My main migration guide walks the whole journey from Lovable Cloud to your own Supabase, click by click, and I promised there that the AI version was coming. Here it is.

Because here's the honest truth about that guide: the path is safe and well marked, but a few stops on it are genuinely technical. A restore command. Compression tooling. SQL checks. URL rewrites. None of it is hard once you've done it, all of it is intimidating the first time. And this happens to be exactly the kind of work AI does beautifully: repetitive, precise, verifiable.

So this guide hands those parts to Claude, two different ways, and you keep the parts that matter: the decisions, the dashboard clicks, and the final "yes, everything made it."

Pick your route

Both routes follow the same map as the main guide, and the one sacred rule never changes:

EXPORT → DOWNLOAD → BUILD → VERIFY → and only then → REMOVE

Nothing gets removed until its replacement is alive and verified. In both routes, Cloud keeps running your app untouched until the very end. That's your safety net, and neither you nor Claude ever works without it.

Before you start: the ingredients

Five minutes of gathering, and the rest flows:

• Your Lovable project connected to GitHub (editor > + menu > GitHub > Connect, how the integration works). Your edge functions travel through the repo.
• A [Supabase account](https://supabase.com/dashboard), free tier is fine to start.
• Your inventory: open the Cloud panel and write down your table count, user count, files per bucket, function names, secret names, and jobs. Two minutes, and it becomes your victory checklist at the end.
• Route A only: the Lovable and Supabase connectors in claude.ai (Settings > Connectors). My setup guide with screenshots walks it.
• Route B only: Claude Code and my migration skill (one command, below).

That's it. No CLI for Route A, no manual SQL for either.

Route A: claude.ai (two connectors, ready prompts, no terminal)

This route uses Claude as the bridge: with both connectors on, Claude can read your Cloud database directly and write everything into your new Supabase while you watch. No export file needed, no restore command, no terminal. You stay in one chat the whole time.

A1. Connect the two connectors

In claude.ai: Settings > Connectors. Supabase is already in the directory, you just click Configure. Lovable goes in as a custom connector with the URL https://mcp.lovable.dev. Each one opens an authorization page where you click Allow, and you're done when both show a Configure button. My connector setup guide walks every click if anything looks unfamiliar.

Two human details before your first prompt. In a new chat, open the tools menu (the sliders icon by the message box) and check that both connectors are turned on for that conversation. And know that when Claude uses them, it asks your permission before each action with a small Allow button. You'll be clicking it a fair amount today, and that's a feature, not friction: nothing touches your projects without you saying yes.

A2. Create the new Supabase project

You can do it by hand in the Supabase dashboard (New project, pick a region close to your users, save the database password somewhere safe), or ask Claude in the chat:

Create a new Supabase project for me called [name], in the region
closest to [your users' location]. Tell me the cost before creating it.

Claude will ask which organization to use if you have more than one, tell you the monthly price, and wait for your yes before creating anything.

And one human detail that saves real confusion: your Supabase connector was authorized BEFORE this new project existed. If Claude says it can't find or access the new project, nothing is broken. Go back to Settings > Connectors > Supabase > Configure, re-authorize, and the new project appears. Thirty seconds.

A3. The big prompt: copy the database

This is the heart of the route. Paste, adjust the two names, send:

Copy my Lovable Cloud database from my project [project name] into my
Supabase project [new project name]: schema, all data, RLS policies,
and auth users with their password hashes and identities. When done,
show me a table comparing row counts on both sides.

Claude reads your schema, recreates it, moves every row, and carries your users complete, original passwords included, because the connector can read the auth tables that normal exports of other platforms hide. The row-count table at the end is your proof, compare it against your inventory.

Two things to know while it works:

• Do this while Cloud is still running. Claude reads from the live source. (The sacred rule again: nothing gets removed yet.)
• Big tables travel in batches. If your project is large, Claude will work in chunks, just let it finish and check the final table.
• You stay in the loop. Claude asks Allow before each round of writes. If the chat seems to pause mid-thought, look for an approval button waiting for you.

A4. Your storage files: the manual part of this route

Claude can't drag files from one storage to another from chat, so this part is yours, and it's the same calm process as steps 2 and 5 of the main guide: download each bucket from the Cloud panel to your computer (one folder per bucket, same names), then upload them to Supabase Dashboard > Storage into the matching buckets. Your buckets already exist, the database copy brought them.

Then ask Claude for the finishing touch:

In my Supabase project [name], find every text or jsonb column that still
contains my old Lovable Cloud project URL and rewrite those values to my
new project URL. Skip signed URLs (the ones with ?token=), list those
separately instead. Show me what you changed.

That last instruction matters: signed URLs are tied to the old project by design and want regeneration, not rewriting. Claude listing them for you is exactly the visibility you want.

A5. Edge functions and their secrets

Ask Claude to deploy your functions straight from your repo:

Deploy all edge functions from the supabase/functions folder of my GitHub
repo [repo name] to my Supabase project [name], keeping the verify_jwt
setting each function has in supabase/config.toml.

The secrets, though, are yours alone: no AI can (or should) set them. Supabase Dashboard > Edge Functions > Secrets, enter each name from your inventory with a fresh value from its provider. Names must match exactly, capitalization included.

A6. Verify, then the two clicks

The verification prompt, before touching anything in Lovable:

Compare my Lovable Cloud project [name] against my Supabase project [name]:
tables, row counts per table, RLS policies, functions, triggers, auth users,
auth identities, storage buckets. Show me a table with both sides and flag
any mismatch.

All green, plus a real login test with one of your users' original passwords? Then, in the Lovable dashboard, the two clicks from the main guide: Remove Lovable Cloud (Cloud tab > Overview > Advanced settings), then connect your own Supabase ("Already have a Supabase project? Connect it here"). Lovable rewires your .env automatically.

And leave your Lovable agent this final prompt, it cleans up the one hiccup the integration sometimes causes:

Review my Supabase connection: confirm the app points to my new Supabase
project, check that auth, database queries, storage and edge functions all
work against it, and list anything still referencing the old backend.

Important context: the database, users, storage files and edge functions
ALREADY EXIST in the new project, they were migrated. Do NOT create tables,
run migrations, or re-seed data. Fix wiring only.

That's the whole route. One chat, a handful of prompts, two dashboard clicks, zero terminal.

Route B: Claude Code (the whole playbook, automated)

If Route A is Claude as your bridge, Route B is Claude as your engineer. Claude Code runs on your machine, which means it can do everything Route A does PLUS the parts that need hands: download and verify the official export, run the restore with the right tooling, script the storage move, and run every verification query from my checklist without you pasting anything.

B1. Install the skill

npx skills add CarolMonroe22/lovable-cloud-to-supabase-migration

The skill is the distilled version of every migration I've done and documented, 33 steps with every trap I've hit built in as an explicit check: the compression quirk of the export file, the identities ordering fix, the cron jobs that come back pointing at the old project, the storage ghost rows, the signed URLs, all of it. Claude Code follows it step by step and asks before anything that costs money or can't be undone.

B2. Say the sentence

With the Lovable and Supabase MCPs connected in Claude Code (the skill checks and helps with this too):

Migrate my Lovable Cloud project [name] to my own Supabase.

That's genuinely it. From there, Claude Code:

1. Takes a full baseline inventory of your Cloud project (the 12-count audit)
2. Guides you through the export click and picks up the file
3. Creates your Supabase project (asking you to confirm the cost)
4. Restores the export with zstd-capable tooling, then runs the known fix passes
5. Recreates your cron jobs with fresh URLs
6. Clears the ghost storage rows and moves your files, scripted
7. Rewrites old URLs in your data, flags signed ones
8. Deploys your edge functions with the right verify_jwt per function
9. Runs the full 12-category verification gate against the baseline
10. Only with everything green, walks you through Remove + Connect

B3. What stays yours

Even in the most automated route, a few moments are deliberately human, and the skill will pause and ask:

Which route would I pick?

Both, honestly, depending on the project. For a small app with a dozen files in storage, Route A in a claude.ai tab is lovely: conversational, visible, done in a sitting. For anything with real storage volume, many functions, or a database you'd rather not copy row by row, Route B earns its setup in the first ten minutes, because the export-restore path it uses is the same one the main guide trusts, just with all the checks running themselves.

And if halfway through Route A you feel like you'd rather have the automation, nothing is lost: everything both routes do lands in the same place, and the verification gate is identical.

A word about trust, keys, and cleaning up

You're letting an AI touch your backend, so let's be adults about what that means:

• Connectors beat pasted credentials. Both routes authenticate through official integrations, you never paste your database password into a chat. If a connection string does pass through a conversation at some point, rotate that password afterwards (Dashboard > Settings > Database, thirty seconds).
• Nothing is removed until you click Remove. Both routes are read-from-Cloud, write-to-new. The destructive step is a dashboard button only you can press, after the gate is green.
• Secrets never travel. Not in exports, not through Claude. You re-enter them fresh, which doubles as good hygiene.
• Delete temporary helpers everywhere. If anything deployed a helper function during your migration, remove it from Supabase AND from your repo, GitHub sync is two-way and will lovingly restore what you forgot to delete.

The finish line

Same as always, your inventory turned victory lap:

□ tables match          □ auth users match      □ files open in browser
□ row counts match      □ auth identities match □ zero old URLs in data
□ RLS policies match    □ one real login works  □ jobs running, fresh URLs
□ functions deployed    □ secrets re-entered    □ AI features re-wired

When that's all checked, your app runs on infrastructure that's fully yours, your users never noticed a thing, and you did it in a conversation.

The bookmarks

*Both routes verified July 2026 on a real migration: 12 tables, 237 rows, 23 users with their original passwords, 40 storage files, 5 edge functions and 2 scheduled jobs, all accounted for on the other side. This guide supersedes my earlier claude.ai chat migration guide, which now points here.*