When to Move Off Lovable, and How to Do It Without Losing Data

It is time to move off Lovable when the way you build, not the tool itself, has become the risk: several developers need to change the code at once, schema changes keep hitting live data, you need a staging environment, compliance asks for controls you cannot show, or running costs and limits no longer fit. Moving off rarely means starting again. The usual options are to export to GitHub and keep building there, to harden the app in place, to move only the backend, or to rebuild only the layer that cannot be fixed. Lovable documents how to move the code and the Cloud backend, and if you follow its steps and rehearse on a copy, users keep their accounts and passwords. Two cautions before you start: a move does not fix problems that live in the code, and moving the backend is, for now, one-way.

This page is the decision and the migration plan. The general pre-launch fixes are in taking a Lovable app to production, and the launch go/no-go is in is Lovable production-ready?.

At a glance

Signals that it is time

None of these on its own means leave. Two or three together usually do.

• More than one person changes the code. Lovable edits and syncs one branch at a time. With several developers, you need branches, pull requests and reviews as the normal path, not the exception.
• Schema changes keep landing on real data. Lovable's database docs say every draft uses the same database as the published app. Once that has caused one incident, you need a staging database.
• You cannot reproduce production. If nobody could rebuild the schema from the repository, because changes went in through prompts and the SQL editor, the app is fragile whatever tool it is in.
• Fixes break other features. A pattern of regressions after prompts means the app needs tests on its core paths, run before every deploy.
• The permission model has outgrown simple policies. Teams, organisations, shared records, admin roles and audit trails are possible on Supabase, but they need someone designing and testing them deliberately.
• Compliance or customers ask questions you cannot answer. Who can access production, where data is stored, how long backups are kept, who reviewed a change. Lovable keeps about 14 days of daily database backups; some contracts need more, or need proof. Lovable's FAQ also says it is not HIPAA-compliant and that its standard terms exclude health records, card data and financial account numbers.
• Running costs or limits do not fit. Lovable's credits documentation says hosting, the backend and AI features in your app draw on the same credit balance as building, and that Cloud apps pause when it runs out. At some traffic levels, a separately billed host and database are simpler to budget.
• You need work Lovable is not suited to. Long-running background jobs, heavy data processing or integrations with awkward protocols are easier in a normal codebase.

Signals that are not reasons to leave: the code looks unfamiliar to a developer, a single bad generation, or a feeling that "real" products are not built this way. Fix the specific problem first.

What a move fixes, and what it does not

Moving is expensive enough that it is worth checking the problem will actually go away.

If most of your problems sit in the "no" rows, harden in place first. A move copies those problems to a new address.

The options

1. Export to GitHub and keep building there

Connect GitHub sync, clone the repository, and make developers' work go through branches and pull requests. Lovable can stay in the loop for interface changes: commits pushed to the synced branch flow back into it. Cautions from Lovable's docs: do not delete the GitHub repository, because that stops the sync and reconnecting creates a new repository; a transfer to another owner keeps syncing only if your workspace has a GitHub connection for that owner; and if GitHub rejects Lovable's push, for example because of branch protection, Lovable pushes its work to a lovable-sync branch for you to merge.

Good fit: the app is sound and you mainly need a proper workflow. Cost: low; mostly setting up CI and branch protection.

2. Harden in place

Keep Lovable and Lovable Cloud, and fix what makes it fragile: correct and tested row-level security, secrets moved to the server, payments confirmed by verified webhooks, schema changes recorded as migrations, a second project as staging, usage alerts on credits, and a periodic export of your own. Lovable's own security best practices cover much of this.

Good fit: a small team, modest traffic, and nothing your contracts require that Lovable cannot provide. Cost: the lowest of the real options.

3. Move the backend, keep the front end

Move the data from Lovable Cloud to a Supabase project you own, and optionally host the front end elsewhere, while keeping most of the interface code. Once the backend is yours, you control backups, regions, access, monitoring and staging directly. Lovable's Cloud region cannot be changed after it is enabled, so this is also the only way to move data to a different region.

Good fit: paying users, a growing team, or requirements around data control. Cost: moderate; most of it is planning and rehearsal.

4. Partial rebuild

Replace the layer that cannot be made safe or fast enough, usually data access, permissions and payments, and keep the screens. A full rebuild is rarely justified unless the interface is also the problem or the product has changed direction.

Good fit: a review finds the permission model or data model is wrong at its root. Cost: scoped like an MVP piece of work. If you want a fixed price before committing, a written scope is the way to get one.

Before you migrate: the inventory

Most migration failures are discovered on cutover day because something was never written down. Do this first, while the old backend is still the only one:

1. Accounts in your name. The domain registrar, DNS, Stripe, Google and other OAuth apps, the email provider, analytics, and the new Supabase organisation. Anything registered to a freelancer or a personal email is a cutover risk.
2. Secrets. List every secret the app uses and where it comes from. Lovable's external hosting guide says "secrets stored in Lovable are not part of the export." Plan to issue new values from each provider rather than copy old ones, and rotate anything whose history you are unsure of.
3. Supabase keys. Supabase's API key guide says the legacy anon and service_role keys are being deprecated by the end of 2026. Start the new project on publishable (sb_publishable_...) and secret (sb_secret_...) keys.
4. Edge Functions and server functions. Everything in supabase/functions/, plus, on TanStack Start apps, the server functions that will run on the new host.
5. Scheduled jobs. The guide says to inventory them, check which exist after the restore, and recreate the rest, coordinating with the old backend so a job does not run twice.
6. Connectors and AI calls. The guide says connections are not exported, and app connectors and AI calls keep running through Lovable until you replace them. Managed OAuth and automatic token refresh work only while the backend runs on Cloud.
7. Storage. Buckets, which are public, and roughly how much data each holds.
8. Migrations. Check that supabase/migrations/ rebuilds the schema on an empty project. If changes went in through the SQL editor, this is where you find out.
9. Baseline numbers. Row counts per table, user count, and storage object counts, to compare against after the move.

How to move off Lovable Cloud without losing data

Lovable's Cloud documentation says there is no one-click migration to your own Supabase, and that remixing a Cloud project does not switch backends. Its external hosting guide lays out the route. In outline:

1. Create the new Supabase project in the region you want. If your users are in the EU, choose an EU region.
2. Apply the schema from the migrations in supabase/migrations/ (or drizzle/migrations/), in order. If the migrations are incomplete, fix them before going further.
3. Export the database from More, Cloud, Overview, Advanced settings. The guide says it is a PostgreSQL custom-format .backup archive with zstd compression, restored with pg_restore, not a SQL file, and that a pg_restore build without zstd support "can list the archive but cannot restore its data." Lovable's advanced settings page says exports are limited to databases of up to 15 GB, with export files of up to 5 GB.
4. Restore it into the new project, and test the restore on a throwaway project first. The guide warns not to add --clean without reviewing it, because it drops the objects being restored.
5. Reconfigure sign-in providers and update OAuth redirect URLs for the new backend and any new domain.
6. Copy storage files by downloading them from More, Cloud, Storage and uploading them to matching buckets. Bucket definitions and their policies come across with the migrations; the files do not.
7. Set function secrets, deploy Edge Functions from supabase/functions/ with the Supabase CLI, and recreate scheduled jobs.
8. Test on a separate deployment, then update the Lovable project's environment variables and supabase/config.toml to point at the new backend.

The CLI part, as the guide shows it:

npx supabase login
npx supabase link --project-ref your-new-project-id
npx supabase db push
npx supabase functions deploy
npx supabase secrets set --env-file ./secrets.env

The guide names the variables to update: VITE_SUPABASE_URL, VITE_SUPABASE_PUBLISHABLE_KEY and VITE_SUPABASE_PROJECT_ID in the browser build, SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY and SUPABASE_PROJECT_ID on a TanStack Start server, and project_id in supabase/config.toml. Keep the secrets file out of the repository.

One more Supabase change to expect. Supabase's changelog says new tables in public are no longer exposed to the Data API automatically on projects created since 30 May 2026. A new project therefore needs explicit grants for the tables your migrations create, or the app answers with 42501, "permission denied for table". Put the grants in the migrations, and keep RLS and policies exactly as they were.

What moves and what does not

From Lovable's guide, with the check that proves each item arrived:

The cutover, in practice

The documented steps move the data. The part that loses data is the gap between the export and the switch, when users keep writing to the old database. To close it:

• Rehearse first. Run the whole migration against a copy, time it, and check row counts table by table.
• Freeze writes for the switch. Pick a quiet window, put the app into a read-only or maintenance state, take the final export, restore, and switch.
• Verify before you announce. Sign in as a test user, check the core flows and a payment, and compare counts against the baseline.
• Keep the old backend. Lovable warns that removing Cloud "permanently deletes your Cloud instance and cannot be undone", including exports saved in its storage. Download everything, keep it until the new setup has run cleanly for a while, and remove Cloud last.
• Tell users about the sign-in. One line in an email saves a wave of support requests.

If the cutover fails

Decide the rollback before you start, not during. The simplest plan:

1. Set a time limit for verification, for example two hours after the switch.
2. If a core flow fails and cannot be fixed within it, point the app back at the old Cloud backend, which you have not removed.
3. Writes made to the new backend during the attempt need copying back or replaying. Keeping the window short and quiet keeps that list small.
4. Fix the cause on the rehearsal copy and try again another day.

The first week after

• Watch the Edge Function and database logs daily for errors that did not appear in testing.
• Check that each scheduled job ran once, and only on the new backend.
• Reconcile Stripe: every payment in the week should match an account with the right access.
• Confirm backups are running on the new project, and download one.
• Rerun the two-account test and the Security Advisor.

Moving the front end too

If you also want to host the app yourself, the same guide says older React and Vite apps build to static files that any static host can serve, as long as it falls back to index.html for client-side routes, while TanStack Start apps need a server: a platform that supports them, a container, or your own Node.js server, built with a Nitro preset such as node-server. VITE_ variables are embedded at build time, so rebuild after changing them, and add the new domain to your auth provider's allowed redirect URLs.

Move DNS last. Verify on a temporary URL first. When you switch, remove the records that pointed at Lovable, and check for leftover AAAA and CAA records; Lovable's custom domain guide lists them as common causes of a domain showing the wrong site or failing its certificate, and the same applies in reverse.

Cancel deliberately. Changing hosting or exporting code does not cancel your Lovable subscription or Cloud usage. Lovable's pricing FAQ says that if you cancel, you keep your remaining credits until the end of the billing period, then drop to the Free plan.

Common mistakes

• Moving to fix a problem that lives in the code. Slow queries and missing checks arrive at the new host intact.
• Copying secrets instead of reissuing them. Use the move to rotate.
• Removing Cloud as soon as the new backend works. It cannot be undone, and it deletes exports saved in its storage.
• Restoring with a pg_restore that lacks zstd support. It lists the archive and restores nothing.
• Forgetting scheduled jobs. Either they stop, or they run twice.
• Leaving the domain, Stripe or OAuth app in someone else's name. You find out when you need to change it.
• Skipping the rehearsal. The first run always finds something.

When not to hire us: if you have one developer, modest traffic and no contractual requirements, option 1 or 2 is probably enough, and you can do it yourself with Lovable's guides. Moving for its own sake costs money you could spend on users.

How Easify can help

The €99 Prototype Check has a person review your repository and live app and send, within 48 hours of payment and access, the top security and data risks in writing and a view on which option fits, then a 15-minute call. The €99 is credited against the build if you hire us. For a migration, the next step is the five-day audit, quoted after the check.

For a partial or full rebuild, the MVP Scoping Sprint gives you a written scope and a fixed build price in about two weeks for €900, credited in full against the build if you build with us. A rebuild is scoped like any MVP: typically €5,000 to €25,000 over 4 to 12 weeks, at €25 to €45 an hour with a €1,000 minimum project. If you are wondering how founders pay for that, our guide to MVP grants and funding in Europe covers the main schemes. We deploy client products hosted in the EU. We are based in Budapest and work remotely across Europe on CET, in English or Hungarian, with our engineering team in India; invoices are in euros, issued by our registered entity in India.

If your app came from another builder, compare the routes in Lovable vs Bolt vs v0 for an MVP.