Moving a Lovable Cloud app to a Supabase project you own is not just changing a database URL. Lovable now provides a full database export, including account records and password hashes. But files, Edge Function code, secrets, sign-in provider settings and API keys still need separate work. That is why a developer’s migration quote can be much larger than the cost of exporting the database.
For initial budgeting, I would use these illustrative engineering allowances, not market averages or fixed quotations:
| Project condition | Initial migration allowance | What the work usually involves |
|---|---|---|
| Prototype, no real users or critical data | $800–$2,000 | Recreate a clean backend, connect the app, test core flows |
| Small live app with users, uploads or integrations | $2,000–$6,000 | Data transfer, authentication, storage, functions, rehearsal and cutover |
| Business-critical or complex multi-role app | $6,000–$15,000+ | Dependency audit, substantial migration work, testing, rollback planning and production support |
These are my planning bands for scoping a professional engagement, not surveyed prices or a promise that your project fits a band. They assume you are preserving a usable application, not paying to rebuild it. New hosting, Supabase usage, third-party services and ongoing maintenance are separate.
First decide whether you need to leave Lovable Cloud
You may not need a migration at all. Lovable’s built-in backend can be appropriate for a product that is working, has manageable costs and does not need independent infrastructure control.
A move becomes worth evaluating when you need your own Supabase billing and dashboard, direct database operations, a separate deployment pipeline, more control over backup and monitoring, or a business requirement about where and how the system is operated. Lovable documents the differences between its built-in backend and an external Supabase project.
Important distinction: exporting a Lovable app’s code to GitHub is not the same as moving its backend. If your goal is simply to let a developer maintain the code, start with my Lovable GitHub ownership guide. You may be able to keep the backend where it is.
What actually moves, and what needs separate work?
Lovable’s database export documentation was checked in October 2026. It says the export includes the database structure, data, user accounts and password hashes. It is a PostgreSQL archive restored with pg_restore. It does not include everything required to run the product.
| Product layer | What to plan for |
|---|---|
| Tables, records and user accounts | Export and restore; compare row counts, relationships and sample records |
| Passwords and active sessions | Password hashes are included; existing signed-in users must sign in again after the switch |
| Uploaded files | Download and transfer storage objects; preserve paths and access rules |
| Edge Functions and jobs | Identify source code and scheduled work; redeploy and test against the new environment |
| Secrets and external APIs | Re-enter values securely, rotate where appropriate, and verify connections |
| Social login and email | Reconfigure OAuth providers, redirect URLs, email delivery and templates |
| Payments | Update callback/webhook endpoints and verify paid-state transitions and retries |
| Frontend and domain | Update backend configuration; test a preview before switching production |
Lovable currently limits its built-in database export to databases using up to 15 GB, an archive file of up to 5 GB, and one request every 24 hours. Larger databases require a different plan with Lovable support. These are platform limits, not migration-service pricing.
What should a developer’s quote actually include?
1. A paid assessment before any production change
The developer should identify the current Lovable backend, repository, database schema, number of users, storage, functions, auth providers, payment flows, domain and hosting. They should establish whether your app is an older React/Vite project or a newer TanStack Start application, because hosting requirements differ. Lovable’s external hosting guide covers that distinction.
A useful assessment ends with a migration inventory, exclusions, known risks, acceptance tests and a cutover plan. If a developer quotes only for “export and import” without seeing those dependencies, the quote is incomplete.
2. A rehearsal on infrastructure you control
Restore a copy into a new Supabase project, set up the required services and run the app against it without moving live users yet. Compare data and test the actual workflows. A successful import is not proof that the product works.
In my own work with Supabase, payments and Cloudflare, I have found that the hardest failures often sit between systems: a browser says payment succeeded but the database did not update; a user can log in but cannot read their own record; a deployment is green but still points at the old environment. A migration needs to test those boundaries, not just confirm that tables exist.
3. A controlled production cutover
For an app with live users, the quote should cover how to prevent new writes from being lost between the final export and the switch. That may mean a short maintenance window or a more involved synchronization approach, depending on the product.
The developer should also identify a rollback point, the person responsible for the domain and backend settings, how errors will be monitored, and what happens if the new environment fails. Do not remove the old backend immediately. Lovable warns that removing its built-in database is permanent and also deletes its stored files.
The acceptance tests I would insist on
Before paying the final migration balance, ask for evidence that:
- An existing user can sign in using the same password, and social login works where applicable.
- Two different users cannot read or edit one another’s private records.
- Role-based permissions work for both normal and administrator accounts.
- Uploaded files open correctly, including private files and signed access.
- Database record counts and a sample of important relationships match.
- Payments are verified by the server, and duplicate notifications do not grant access twice.
- Email, background jobs and server functions operate in the new environment.
- The live application points to the new backend and a fresh deployment can be reproduced.
- Errors, backups and the handover process are documented.
Supabase’s Row Level Security documentation explains why database-level access checks matter. For a deeper review, see my AI-built app authorization testing guide.
How to compare two migration quotes
Ask both developers to quote the same scope, not merely a number of days. A meaningful proposal should say whether it includes user accounts, file storage, Edge Functions, OAuth, email, payment webhooks, staging, cutover support, post-launch fixes and ownership transfer.
A $1,000 quote that only restores tables may be more expensive in practice than a $3,000 quote that also tests sign-in, payments and the production switch. Equally, a $10,000 proposal to rebuild a working interface may be unnecessary if the real job is only a backend migration.
Keep the new Supabase organization, GitHub repository, domain and payment-provider accounts in your business’s control. Grant developers appropriate access instead of transferring permanent ownership.
Should you migrate, keep Lovable or rebuild?
Keep Lovable Cloud when it meets your requirements and the migration has no clear operational payoff. Migrate the backend when you need independent control and the existing product is worth preserving. Consider a partial rebuild only if the assessment shows deeper problems with the application’s data model, authorization, payment rules or maintainability.
If you also want to move the frontend to Cloudflare, that is a separate deployment scope. My Lovable to Cloudflare Workers guide explains why the frontend runtime matters.
For a broader finishing or repair budget, see what it costs to hire a developer to finish a Lovable app.
If you already have users, data or payments in a Lovable project and need a responsible migration plan, tell me about the product. Share the current stage, backend, integrations and what you want to own. I can help define what should move, what should stay and what must be proven before launch.