Moving a Live Lovable App: What Happens to Users, Data, and Payments?

TL;DR

• Choose the boundary first: changing how you develop the app, moving its frontend and replacing its backend are separate decisions.
• Test existing customers and their old records. A successful new signup does not prove that accounts, ownership and private files survived the move.
• For the documented Lovable Cloud backend-export path, plan a password-reset flow rather than promising that existing passwords will keep working.
• Keep billing connected to application access. Disconnecting Lovable's built-in payments can leave subscriptions charging while the app stops receiving updates.
• Rehearse changes arriving during the switch and preserve them during recovery. Do not delete the old Cloud instance as an early migration step.

Choose what you are actually moving

Start with a named outcome: another developer can release changes, the frontend runs on your hosting account, or the backend leaves Lovable Cloud. Those are different scopes. Buying all three when only the first is needed adds work without establishing a better result.

Lovable's ownership documentation separates code, frontend hosting, and backend services and data. It explicitly supports hosting the frontend elsewhere while keeping the Cloud backend. Its GitHub integration provides code synchronization, which gives a team another way to work on the app without first migrating customer records.

Identify the actual backend before planning exports. A Lovable app connected to an existing Supabase project is not the same starting point as an app using Lovable Cloud. Record the project identifiers, account owners and services in use. Do not infer them from the name of the tool that built the screens.

Moving the same code to another host also does not, by itself, resolve a structural problem in that code. When the next feature is the blocker, use our fix-or-rebuild decision guide to establish what needs changing. Keep that decision separate from where the existing services run.

Make a migration map before changing accounts

For example, suppose a live document portal uses Lovable Cloud for accounts, records and uploads, plus a Stripe account for subscriptions. The proposed move puts the frontend and backend under the business's own hosting arrangements while retaining that Stripe account. This is a hypothetical planning exercise, not a Caemcore client case.

Fill in the source account, destination account, responsible person and acceptance evidence for each row below. Replace the proposed action when your project has a different boundary. A frontend-only move, for example, may leave the database and uploaded files untouched.

Keep credentials out of this document. Record where protected values are managed and who can install them. A destination that quietly connects back to production is not an isolated rehearsal environment.

What happens to existing logins?

Preserving a user record, preserving their password and preserving an open browser session are separate requirements. Agree which ones the migration promises before telling customers that nothing will change.

For a Lovable Cloud backend migration, the documented export path does not provide usable user passwords. Plan a password-reset flow for migrated password users. That limitation is stated in Lovable's backend migration guide; it is not a claim that every Supabase migration or frontend deployment requires password resets.

When the existing authentication service stays, do not recreate users just because the frontend moved. Verify the retained service from the destination, including a fresh sign-in and account recovery. Record whether users must sign in again instead of assuming their existing session will transfer.

For a new authentication destination, preserve the original user identifiers where supported or maintain a verified mapping to the new ones. Otherwise, a person can successfully sign in and still appear to have no documents because the records point to their old identity. Test account ownership, not just the welcome screen.

Lovable's external-deployment guide requires authentication providers to be configured in the destination, including updated OAuth callback settings. Those provider callbacks and the application's return address are different settings. Supabase's redirect documentation explains how the Site URL and allowed redirect URLs affect confirmation and recovery flows.

Rehearse each sign-in method the app actually offers. For a password user, test delivery of the reset message, its destination and access after recovery. For a social-login user, verify that the returned identity reaches the existing account rather than creating an empty duplicate. Include any additional factors the app requires.

Tell affected customers what action is needed, where it starts and how to get help. Do not ask them to send passwords to the developer. A planned reset is manageable; discovering it after switching the live app leaves both customers and support without instructions.

Move the records and the files, then prove the relationships

A useful import preserves which customer owns which document, which file belongs to that document, and which paid account grants access. Counting rows alone cannot prove those relationships.

For the portal example, record the source document ID, owner, destination ID and file location. Explain every excluded or unresolved record. Inspect known histories and file contents after the trial, including an older upload and a customer with more than one document. Ask the receiving operator to trace a disputed record back to the source.

The current Lovable Cloud database export includes structure and data, but excludes storage files, Edge Function code and secrets. Download the export before removing Cloud, because its stored download will no longer be accessible afterwards. These boundaries come from Lovable's export documentation.

The distinction survives outside Lovable too: Supabase database backups contain storage metadata, not the objects uploaded through its Storage API. A restored file record can therefore point to a file that was never copied.

Request a file-transfer manifest with source path, destination path, size and a content checksum where practical. Verify actual downloads through the application, under both allowed and forbidden accounts. Do not make private buckets public to get the migration demo working. Identify stored URLs that need replacement and decide what should happen to links already sent to customers.

Recreate and inspect the rules around the data as well. Schema files need to match the deployed system; do not assume that every later change was committed. Lovable's migration guide identifies database policies, functions, triggers and manually configured services as parts of the move. Require the destination to demonstrate the intended behaviour, not merely accept an import file.

Keep subscription billing connected to application access

In the hypothetical portal, retain the existing Stripe customer and subscription references and their association with each application account. Moving the code is not a reason to create a second subscription. Confirm the current provider state and reconcile it with the app before switching access decisions.

Billing and access can diverge. Stripe's subscription documentation describes asynchronous events for subscription activity. The migrated application needs to handle the events relevant to its access policy, including renewal, failed payment and cancellation. A working checkout for a new customer does not test an existing customer's next renewal.

Check how Lovable is connected to the payment provider

An app using Lovable's built-in payments has a specific disconnection process. Its payment documentation says disconnecting removes integration credentials and data and attempts to remove Lovable-registered webhooks. The app stops receiving provider events. Existing subscriptions are not cancelled, refunded or automatically explained to customers; recurring billing can continue.

Lovable also describes that disconnection as permanent, with the same original provider account unable to reconnect to the same project afterwards. Do not use it as a reversible preparation step. Establish the replacement event handling and recovery plan before deciding when disconnection is appropriate.

For a custom Stripe integration, inspect its actual credentials, endpoints and code instead of assuming the built-in workflow applies. Record who owns the provider account. Moving to a different payment account or provider is an additional migration, outside the same-account example here.

Transfer responsibility for events

Give each subscription event one accountable processing path during the switch. Running two environments is not inherently wrong, but two independent handlers must not both grant duplicate credits, send duplicate messages or overwrite newer state.

Stripe's webhook guidance documents repeated deliveries, non-guaranteed event ordering and signature verification. Ask how the destination rejects invalid signatures, recognizes an already-handled event and resolves delayed events against current subscription state. Include the processing history or equivalent recovery mechanism in the transition plan; a fresh empty event log can make an old delivery look new.

Reconcile by provider customer and subscription identifiers. Compare the accounts that should have access with the accounts that actually do. A dashboard showing the same number of paid users could hide one missing customer and one incorrectly enabled account.

Rehearse a renewal and a late edit during the switch

Use synthetic customers, files and a payment-provider sandbox. Stripe supports subscription testing and test clocks for time-based behaviour such as renewals. Keep the rehearsal separate from live payment actions and customer notifications.

For the hypothetical portal, prepare a paid test customer, an unpaid customer, an old private document and an existing subscription. The rehearsal should produce evidence for this sequence:

1. Establish the baseline. Record the customer's identity, document and provider subscription references. Confirm the old environment's expected access and retain a known application revision.
2. Perform the trial move. Use the written migration steps. The existing paid customer completes the agreed sign-in or recovery flow and opens the same document. The unpaid or unrelated customer cannot retrieve it through a direct request.
3. Advance the existing subscription. Simulate a renewal and then the relevant failure or cancellation scenario. Confirm that the destination applies the agreed access policy to the existing account without creating another subscription. Replay an event and check that its effects are not repeated.
4. Create a change after the initial copy. Add a test document or correction in the authoritative source while the destination still has the earlier snapshot. Run the proposed catch-up process. Account for that change and its file explicitly.
5. Exercise recovery after new work exists. Once the destination accepts a test edit and a subscription update, simulate the condition that would stop the rollout. Follow the recovery procedure and demonstrate that neither change is silently lost or applied twice.

These checks test the proposed migration boundary, not the whole application's security or every possible outage. Keep failed checks visible with an owner and a next action. Do not close them by showing a successful new signup instead.

Define who can write during cutover and rollback

Choose one authoritative destination for each kind of new write at every stage: documents, account changes, subscription updates and scheduled work. A temporary read-only application window may simplify a move, but it does not stop external payment events arriving. The plan needs a durable way to receive or recover those events and reconcile them.

An initial export is a snapshot, not a continuously updated copy. Lovable currently limits database export requests to one every 24 hours. Check the export's size eligibility and use a rehearsed method for capturing later changes rather than assuming repeated full exports can serve as live synchronization.

Write down the final-copy procedure, the checks before allowing writes, the person who authorizes the switch and the conditions that stop it. Account for browsers or integrations still reaching the old version. Disable or redirect obsolete write paths through the application design rather than assuming a domain change makes every client switch together.

Rollback must cover data and external events as well as code. If the new version changes the schema, ask whether the old version can operate against it. If a subscription renews after the switch, restoring yesterday's database cannot reverse that provider event. The recovery procedure must reconcile the new facts or proceed with a forward correction.

Removing Lovable Cloud permanently deletes its instance and cannot be undone. Keep removal outside the reversible part of the rollout. Retire the old environment only after the agreed checks pass and retained data, pending work and operating responsibility are accounted for.

What should the migration proposal include?

Ask for the completed migration map, the behaviour that must remain unchanged, the trial results and a cutover procedure with recovery conditions. Require explicit treatment of existing identities, files and subscriptions. Keep new features or a visual redesign outside the first move unless they are necessary to make it work.

Price delivery and ongoing operation separately. Lovable's external-hosting guide assigns responsibility for externally hosted backend configuration, monitoring and recovery to the operator. Name who takes those tasks, what the hosting provider covers and what still needs a developer. A lower hosting bill is not a complete operating-cost comparison.

If the existing backend meets the requirements, retaining it can avoid an unnecessary migration. When it genuinely needs replacing, the acceptance point is the existing customer completing the same work on the destination, with a tested path for changes and failures during the move.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Built it on no-code or AI tools and it stopped changing? We start with an audit, not a quote. 30 minutes, free: what we keep, what we rebuild, what blocks launch, the range and the timeline.

You get that whether we work together or not.

FAQ

Can we keep using Lovable for development after moving hosting?

Yes, a Git-connected project can support development in Lovable while deployment happens elsewhere. Agree the active branch, release approval and environment configuration. Lovable documents two-way synchronization, so an edit may reach the shared repository rather than remain an independent experiment. Keep production credentials and deployment controls separate from a convenient preview.

Will customers need to enter their card details again?

A hosting change alone is not a reason to collect payment details again when the existing provider account, customer and subscription remain in use. First verify those relationships and the retained payment setup. Changing the payment account or provider is a separate transfer whose supported process must be confirmed. Do not ask customers to send card details to a developer.

Can we migrate only one group of customers first?

Only if that group has a workable boundary. Identify shared records, organization memberships, background jobs and payment events before choosing it. Document which environment handles each account and how cross-group work continues. If users share projects across the proposed split, a customer-by-customer rollout may be less manageable than moving the shared workflow together.

Should we add new features during the migration?

Keep unrelated changes in a separate release. A new permission model, billing plan or document workflow changes what you are trying to preserve and makes discrepancies harder to explain. Handle necessary fixes through an approved change log and update the rehearsal. Migration and product development can proceed in parallel only with clear version and responsibility boundaries.

Does the developer need to own the new hosting accounts?

Not by default. Ask for business-controlled ownership, billing visibility and recovery access, with the developer invited for the work they perform. Where a supplier-managed service is part of the agreement, document the exit process, transferable data and ongoing dependencies. A working deployment does not settle who can operate or transfer it after the engagement ends.

Sources

• Lovable, Deployment, hosting, and ownership options. Checked 13 September 2026.
• Lovable, GitHub integration. Checked 13 September 2026.
• Lovable, Advanced settings: Cloud export and removal. Checked 13 September 2026.
• Lovable, Deploying and hosting outside Lovable. Checked 13 September 2026.
• Supabase, Redirect URLs. Checked 13 September 2026.
• Supabase, Database Backups. Checked 13 September 2026.
• Lovable, Payments. Checked 13 September 2026.
• Stripe, Using webhooks with subscriptions. Checked 13 September 2026.
• Stripe, Webhooks. Checked 13 September 2026.
• Stripe, Test your integration. Checked 13 September 2026.

The document portal, migration map and rehearsal are hypothetical planning tools, not Caemcore client results. Platform details were checked on 13 September 2026. The Stripe example retains the existing payment-provider account; it does not describe a transfer to a different account or provider.