BACKEND MIGRATION
Move from Lovable Cloud to your own Supabase project
A backend migration brings your application’s records and services into a Supabase project you manage. First identify your current backend. Then plan the database restore, separate file transfer, authentication configuration, and application switch as one coordinated change.
Check which backend you have
Open your project’s Cloud settings. A Lovable-managed database and user interface indicates Lovable Cloud. A named Supabase project with links to its dashboard indicates a project you manage in Supabase. Check the actual connection rather than assuming every Lovable app has the same backend.
If the connected Supabase project is already yours, you may only need a hosting change. Confirm the account and project before creating another database.
Inventory what needs to move
Lovable’s database export includes structure, records, user accounts, and password hashes. It does not include storage files, Edge Function code, or secrets. Those need separate handling. Check the current export limits and prerequisites before scheduling the move.
| Component | Migration work |
|---|---|
| Database and user records | Choose a supported restore path for the export and destination. |
| Application and function code | Review the repository and deploy the required runtime code. |
| Uploaded files | Transfer file contents and verify access rules and links. |
| Secrets and provider settings | Configure destination credentials and authentication providers separately. |
| External integrations | Update callbacks and test the app’s actual dependencies. |
Choose a restore path before making changes
Identify the destination project, export format, and permissions first. Follow the current official restoration procedure for that combination. Replaying schema migrations and restoring a complete database backup are different approaches; do not run both indiscriminately against the same destination.
Rehearse on an isolated destination before switching a live app. Record what you restored, what needed manual configuration, and which checks passed. If an import fails, keep the source intact and investigate the failure before retrying destructive steps.
Passwords and active sessions are different
Lovable documents password preservation when restoring its export into Supabase, but users must sign in again after the switch. Provider settings and API keys need configuration at the destination. Test every sign-in method you actually use rather than treating imported user rows as proof of working authentication.
Include password recovery, OAuth redirects, and account permissions in the rehearsal. Use representative test accounts; checking only an administrator account can hide access problems faced by ordinary users.
Move files and configure secrets separately
Use the Storage view to identify buckets and download the required files. Check both file contents and accessibility: a readable public image does not prove a private document is protected correctly. Preserve the relationship between records and their file paths.
Keep a list of configuration names for each environment. Server secrets belong in the destination’s secret configuration, not a browser bundle or public repository. Replace credentials where appropriate and check that functions read the intended values.
Plan for users and writes during the switch
A database copy represents a point in time. Decide how to handle changes that arrive afterward, including new accounts, uploads, payments, and webhook deliveries. Establish whether a maintenance window is needed and who approves the switch.
A recovery plan must account for writes made at the destination. Simply pointing the app back at an older database can discard changes or repeat external actions. Define the conditions for stopping, recovering, and resuming before moving traffic.
Suggested verification checklist
These are checks to perform on your own app, not a claim that a migration has been tested for you. Use expected outcomes and keep the results with the migration notes.
- Compare representative records, counts, relationships, and important history.
- Exercise each sign-in method and account-recovery flow.
- Check permissions with two ordinary accounts, including denied access.
- Open public files and confirm private files remain private.
- Run important functions, payment webhooks, email paths, and scheduled work using safe test settings.
- Check for calls still going to the old backend.
- Test the published app at its final hostname, not just a local preview.
Common blockers and when to get help
Missing export access, mismatched provider redirects, absent files, and incorrect environment settings can all stop a move. Separate those problems rather than repeating the import and hoping the app starts working.
Official guidance and third-party tools can support a DIY move. We have not validated third-party migration tools, and this site does not provide an automated migrator. Request help when you need someone to work through the dependencies, scope, and cutover with you.
Keep the source available through verification and recovery planning. Lovable’s removal action is irreversible; do not use it as the first step in a migration.
Official sources
Product instructions were checked against these documents on 2026-10-15. This is documentation research, not a claim of testing on your app.