Two different things people call 'export'
The first is a backup. You want a copy of your database sitting on your own disk, because a product with real customers in it shouldn't exist only inside one platform. That's a five-minute job and you should do it on a schedule.
The second is leaving. You want your app running against your own Supabase project, with your own dashboard, your own keys and your own backups. The export is step one of that, but it's maybe a third of the work.
Both start in the same place, so run the export either way. What differs is everything you do afterwards.
The limits nobody reads until they hit them
A database export is capped at 5 GB, and you can request one every 24 hours. Neither number matters on a young project and both matter enormously on cutover day, when you assumed you could re-run the dump twice in an afternoon.
So take a practice export a week before you actually need one. You'll find out how big your data really is, how long the email takes, and whether the dump restores cleanly — while you still have room to fix things.
What the export does not include
Storage bucket files. The dump is schema and data only; anything your users uploaded is downloaded separately from the Cloud tab under Storage. On a media-heavy app this is the bulk of what you actually care about.
Edge function code. That lives in your project's repository, not in the database, so it comes across with your codebase rather than the dump.
Project secrets. API keys, signing secrets, webhook secrets — none of them are exported, by design. Write down which secrets exist before you migrate, because rediscovering them from broken runtime errors afterwards is miserable.
Row-level security policies come across with the schema, but verify them on the other side rather than assuming. A policy that silently didn't apply is the most expensive kind of migration bug.
The passwords gotcha
This is the one that catches everybody. Your auth users export, but their passwords don't come across in a usable form. Which means the morning after you migrate, every single existing user cannot log in.
The fix is a password reset flow, built and tested before you cut over, plus an email to your users telling them what's happening so a reset link doesn't read like a phishing attempt. If you use magic links or social login, you're mostly spared — those users just sign in again.
Plan the migration for a quiet window and be ready to answer support the same day. It's a one-time cost, but it's a real one.
Restoring into your own Supabase
Order matters. Create the project, load the schema, then the data, then re-create anything the dump didn't carry: RLS policies verified one table at a time, storage buckets and their files re-uploaded, edge functions deployed, secrets re-entered.
Then flip the environment variables in your app. In a Lovable project the code keeps pointing at Supabase either way — only the URL and the keys change, which is why the app itself usually needs no rewriting.
Then smoke-test everything with real intent: sign up, log in, reset a password, upload a file, run a payment, trigger a webhook. Not the happy path you remember, the whole surface. Keep the old Cloud instance alive until you've done it.
Removing Cloud is permanent
When you remove Lovable Cloud from a project, the instance is deleted and it cannot be undone. There's no grace period and no recovery.
So the sequence is: export, restore, verify against the new backend for a few days with real traffic, and only then remove. The overlap costs you almost nothing and buys you the ability to change your mind.