Migrating Off Lovable: Six Separate Migrations

You are a solo founder with real users on a Lovable app. A developer or migration service said the move was done, but a login, image or webhook has since broken and you cannot tell whether the move failed or was only partial. This article gives you a six-layer check so you can name what moved and locate the symptom. App Rescue Desk is independent and is not affiliated with Lovable or Supabase.

“The database moved” and “the code is on GitHub” sound conclusive. Neither statement covers the editor, deployed frontend, identity or operations, so several layers can remain untouched.

TL;DR

• Treat leaving Lovable as six migrations: editor, code, runtime, data, identity and operations.
• Git sync carries code. A Lovable Cloud database export excludes storage files, Edge Function code, secrets and usable user passwords; the Supabase CLI’s default dump excludes managed auth and storage schemas. Neither path covers all six layers.
• Use the six-layer check to identify what still depends on Lovable and which layer owns the failure.

What you see after a migration that was really six migrations

A database restore or connection attempt can produce one of these documented messages:

ERROR:  permission denied to grant role "postgres"
DETAIL:  Only roles with the ADMIN option on role "postgres" may grant this role.

constraint x for relation y already exists

psql: error: connection to server at "aws-0-us-east-1.pooler.supabase.com" (44.216.29.125), port 5432 failed: error received from server in SCRAM exchange: Wrong password

These strings are reproduced from Supabase’s CLI backup and restore documentation and Dashboard restore documentation, checked 2026-08-10. The role error belongs to the CLI restore path. Supabase describes the “constraint … already exists” family as expected during a legacy Dashboard full-dump restore, so that message is not automatically evidence of a failed migration. The SCRAM message concerns database connection authentication rather than dump contents.

Other failures may have no useful restore-time error. Existing sessions may stop working, image URLs may return 404, or a webhook may stop firing without a frontend error. Those symptoms are leads, not proof of a specific cause.

These signatures come from different layers. No database retry can address all of them. Product behavior below is dated because both platforms can change.

What everyone checks first — and why it is the wrong layer

Three reasonable retries target different boundaries:

1. Re-run the database export or dump. The result depends on the source. Lovable’s Cloud export documentation, checked 2026-08-10, says the database export contains structure and data but excludes storage files, Edge Function code, project secrets and usable user passwords. The Supabase CLI reference, checked 2026-08-10 for CLI 2.x, says its default db dump excludes managed schemas including auth and storage. Another run of the same process cannot add categories that process does not carry.
2. Rotate the Supabase keys again. Rotation changes a credential; it does not change which project URL the frontend, function or webhook calls. Also distinguish current publishable/secret API keys from legacy anon/service_role keys and JWT signing keys. They are not one interchangeable object. See Supabase’s API key documentation, checked 2026-08-10.
3. Redeploy the frontend. Lovable documents its projects as Vite applications whose VITE_ variables are embedded at build time. Rebuilding with unchanged VITE_SUPABASE_URL and publishable-key values embeds the same backend target again. Changing those values requires a rebuild and redeploy for the documented static-frontend path. See Deploying and hosting outside Lovable, checked 2026-08-10.

Each retry can repair its own layer. It becomes a dead end when “migration” is treated as one object rather than six independently owned parts.

The six layers when migrating off Lovable, and why each moves on its own

For a Lovable app using Lovable Cloud or Supabase-compatible backend services, six layers are a useful working decomposition, not a universal software taxonomy. Each layer has its own owner, transport and failure signature. The layers are independently movable; changing one does not certify the others.

The editor is the layer you can keep

The editor is Lovable’s AI build workspace. It is distinct from the Git repository, the deployed frontend and the built-in backend.

Owning code does not require abandoning that workspace. Lovable’s deployment and ownership documentation, checked 2026-08-10, says the production frontend or backend can move elsewhere while Lovable remains in the development workflow. Conversely, syncing a repository does not remove the editor or the built-in backend.

The current controls are documented. Git sync is managed under Project settings → Git. Lovable Cloud lifecycle controls are under Cloud tab → Overview → Advanced settings. Remove Lovable Cloud permanently deletes that Cloud instance and cannot be undone. Export the database and download required storage files before using it.

Recording that you intentionally kept the editor is a valid outcome. Deleting Cloud is not required merely to own the code.

The code moved; the repository was never going to carry the rest

Code is the source and migration files synchronized with GitHub or GitLab. Lovable’s Git sync documentation, checked 2026-08-10, says each project links to one repository, Lovable edits and syncs one branch at a time, and the repository contains code and database migration files but never database data.

Git can therefore preserve code history without acting as a database transport. A commit does not, by itself, transfer current table rows, auth users, deployed secrets or a running webhook.

Use repository presence as evidence for the code layer only. The export gives you the code layer; it does not certify the other five.

The runtime is a separate switch with build-time variables

Runtime means the host serving the frontend, the domain routed to it and the values used when the frontend was built. Those items determine what answers when a user opens the app. They are separate from the source repository.

Lovable’s external deployment guide, checked 2026-08-10, says Lovable projects are Vite applications and that VITE_ variables are embedded at build time. A frontend can therefore be deployed to a new host while its built assets still point at the old backend. Changing those values requires a rebuild and redeploy for the static-frontend paths documented there.

Record the host, domain, VITE_SUPABASE_URL, publishable-key source and backend project ID used by the deployed build. A wrong backend reference is a deployment-configuration failure. It does not prove that database rows failed to move.

Data is not one migration either

Data includes roles, schema definitions, table rows and storage objects. These parts use different transports, and the source path matters.

The current Supabase CLI backup guide, checked 2026-08-10 for CLI 2.x, uses three supabase db dump invocations for roles, schema and data. The CLI reference says managed schemas including auth and storage are excluded by default. If you customized those schemas, the backup guide says to restore their changes separately.

Lovable Cloud’s database export, checked 2026-08-10, follows a different boundary: it exports database structure and data, but not storage files. It is limited to 5 GB and one request per 24 hours. Download the export and storage files before removing Cloud, because exports stored there are no longer accessible afterwards.

Supabase’s Dashboard restore guide, checked 2026-08-10, likewise says restored bucket metadata can appear while the S3-backed files are absent. A schema restore can therefore complete while images still return 404. That is a storage-object lead, not evidence that table rows vanished.

Identity moves on different mechanics from data

Identity includes auth users, password material, sessions, signing keys and application relationships pointing at user IDs. Application rows may restore while their sign-in identities do not.

There are two materially different cases:

• Moving from Lovable Cloud: Lovable’s Cloud export documentation, checked 2026-08-10, says user passwords are not exported in a usable form. Migrated users therefore need a password-reset flow.
• Moving between Supabase projects you control: Supabase’s auth-user migration documentation, last edited 2026-04-08 and checked 2026-08-10, says the auth tables can include users and hashed passwords. For the legacy JWT-secret path described there, a different secret invalidates existing tokens, while reusing the original secret preserves them. Updating that legacy JWT secret also regenerates the legacy anon and service_role keys.

Supabase is moving toward publishable/secret API keys and asymmetric JWT signing keys. Do not apply the legacy-secret statement to every project without checking its current signing-key configuration. See JWT Signing Keys, checked 2026-08-10.

A foreign key is a constraint linking one row to another. A user UUID in application data is useful only if the destination identity mapping and application relationship still agree on that ID. Row counts alone do not reveal a broken relationship.

Sessions should therefore not be assumed to survive a project move. The answer depends on whether the source is Lovable Cloud, which documents a password-reset path, or a Supabase project whose signing-key continuity is deliberately preserved.

Operations is not fully captured by a database dump

Operations covers Edge Functions, secrets, database webhooks, auth settings, API keys, Realtime settings, extensions, publications, read replicas and backup ownership. Some operational definitions touch the database, but a database restore does not fully recreate the operating state.

Supabase’s Dashboard restore guide, checked 2026-08-10, lists Edge Functions, auth settings and API keys, Realtime settings, database extensions/settings and read replicas as items that require recreation or setup. Its CLI restore guide separately tells operators to enable database webhooks, non-default extensions and required Realtime publications.

Supabase’s Edge Function environment-variable documentation, checked 2026-08-10, lists project environment values including SUPABASE_URL, current publishable/secret-key dictionaries and legacy SUPABASE_ANON_KEY/SUPABASE_SERVICE_ROLE_KEY. It also says .env files must not be committed. Supabase’s API key documentation says elevated secret or legacy service_role credentials belong only in backend components and explains replacement if one is compromised.

A webhook that quietly stopped firing is therefore an operations lead even if its table restored.

How to confirm which layers you actually moved

Use this checklist only on accounts and projects you own. Record the date beside every result. The linked locations and configuration boundaries are documented, but the checklist has not been reproduced end-to-end on a paired throwaway Lovable Cloud and Supabase project.

[UNVERIFIED: reproduce all six rows on a paired throwaway project before publication. Exact menu labels and false-pass behavior should be rechecked.]

Passing all six confirms only the states inspected today. A dashboard entry does not prove that a webhook receiver behaves correctly, and sampled checks do not validate all application logic.

How to move the layers that are still Lovable’s

Move only failed rows, ordered by dependency. Before changing production data or identity, take a restorable backup, record its location and keep the existing route available until its replacement passes. If the source is Lovable Cloud, download the database export and required storage files before any Cloud removal.

1. Editor — record the decision. Record the Git and Cloud control state and date. Do not click Remove Lovable Cloud at this stage; that action permanently deletes the Cloud instance. The expected result is a written decision to keep the workspace or remove it later.
2. Code — confirm ownership and sync. Put the repository under the intended account and confirm the synced branch. Verify the path with a documentation-only commit. Retain the previous repository and branch read-only as rollback where your provider and ownership setup allow it. The expected result is a repository and branch that the intended account controls.
3. Data — inventory and verify separately. Inventory roles, schema, rows and storage objects. Use the migration path that matches the source: Lovable Cloud export or Supabase project backup. Verify schema, sampled totals and actual file access separately. Keep the timestamped source backup; a conflicted restore is outside this checklist. The expected result is an explained match for each required data category.
4. Identity — choose and test the source-specific path. Determine whether the source requires a password-reset flow or supports a Supabase auth-schema migration. Confirm how user IDs map before changing live auth. Test sign-in or reset and one known user-linked row in a non-production pairing. Supabase says there is no one-size-fits-all script for migrating only the auth schema. Keep old auth available until the target test passes where the source platform permits that overlap. The expected result is a tested account and relationship on the target.
5. Operations — recreate and exercise each dependency. Recreate inventoried functions, server-side secrets, webhooks, extensions, publications, Realtime settings and backup ownership. Exercise each with an owned test event. Retry and deduplication behavior is sender-specific, so verify the webhook sender’s documentation before changing its route. The expected result is an owner and an exercised target test for every required item.
6. Runtime — repoint only after the dependencies pass. Change the backend URL and project values only after data, identity and operations pass. Rebuild and deploy. Verify the domain, normal sign-in and one owned webhook event. Retain the previous deployment and its secret-free configuration record as the rollback reference. The expected result is that the live domain reaches the intended host and target backend.

Only after the replacement passes and required exports are downloaded should you consider removing Lovable Cloud. That removal is the documented point of no return for the Cloud instance.

Blast radius: changing or revoking a signing key invalidates tokens signed only by that key; the exact effect depends on whether the project uses the legacy JWT secret or current asymmetric signing-key rotation. Rerouting a webhook changes the delivery path, while retry and duplicate-delivery behavior depends on the sender. This sequence does not validate application logic, repair a failed pg_restore, reconcile writes made to both projects during cutover or prove every external integration works.

How to stop this recurring — one owner and one date per layer

Keep a living ownership record beside the repository. This turns production independence into six statements that can be rechecked after a deployment or account change.

Update a row whenever its account, project reference, signing/API-key owner or route changes. A single completion date hides these distinctions.

When this is bigger than it looks

For a Production Independence Assessment, we first inspect the live dependency in reverse migration order: what the runtime is actually calling, whether identity moved with its user relationships, then whether operations moved at all. The output is a written statement of where each layer is served from today, the evidence for that answer and what remains. It is a map, not a repair.

A reader who can complete the six-layer check can produce most of that record themselves. An assessment is useful when the answer must survive a cofounder’s or acquirer’s questions. The comparison is concrete rather than universal: Lovable’s managed arrangement consolidates development and infrastructure, while an independently owned destination account puts its backend URL, keys and operating settings under your control at the cost of owning the corresponding operational work.

Performing the remaining migrations is development work, not assessment — the desk maps and sequences the layers; it does not rebuild the app or run the cutover as a build project.

Leaving Lovable is six migrations, not one. The production question is who owns each layer when one of them changes, not merely whether the app works today. Separating the six layers tells you which migrations you still owe. It does not tell you how long each one takes on your app — that depends on how much logic sits in your Edge Functions and how many of your tables point at user IDs.

If you want the six layers written down as six answers rather than assumed, the Production Independence Assessment states where each layer is served from today and what moving the rest would involve — scope and price agreed before anything in production changes.