Leaving Lovable: what do you actually need to take with you?

Your code is on GitHub. What about everything else?

You built your app with Lovable. It works, people use it, and you want to keep developing it elsewhere. Perhaps with a developer. Perhaps to gain more control over hosting.

You connect GitHub, retrieve the files and open the project. Everything is there. Everything that looks like code, anyway.

But what about the documents your customers uploaded? User accounts? The service sending emails? The payment that activates a subscription?

An application is code, data and services working together. To move it, you need to know where each part lives.

Here is the inventory to make before touching the running product.

First, what exactly do you want to leave?

There are three separate decisions: changing your coding tool, moving your app’s pages, and moving the services that store data and manage users.

Lovable lets you move these parts separately. You can, for example, host the interface elsewhere while keeping the Lovable Cloud backend. Lovable’s hosting options documentation.

Next, identify your setup: Lovable Cloud or an external Supabase project you already control. These are distinct configurations, even though Cloud uses Supabase technology. Lovable Cloud documentation.

If you keep your own Supabase project, its data does not need to move simply because you change editors. Write down what stays and what moves. That can make the job considerably smaller.

1. The code and what it takes to run it

GitHub sync lets you retrieve your code and work on it outside Lovable. It works both ways: changes to the synced branch can flow back into Lovable. GitHub integration documentation.

Check that the repository belongs to an account or organization your business controls. Being able to read the code and being able to administer its repository are different levels of access.

Then ask for a simple demonstration: can someone retrieve this repository on another machine and run the project using written instructions?

Those instructions should explain how to install the project, start it, build its production version and supply its configuration. Keep the business rules, important decisions and known bugs too. The next developer should not have to reconstruct six months of conversations from a screen.

If you also want to change the stack, write that decision down first. Getting the existing app running elsewhere gives you a baseline for what comes next.

2. The database, including its rules

Imagine an app for quotes. Retrieving the rows from the customer table is not enough. You also need the quotes, their links to customers, access rules and the structure holding everything together.

For Lovable Cloud, a full database export is available in advanced settings. It includes structure and data, but excludes stored files, server function code and secrets. The documentation also sets size and frequency limits: check them before scheduling the switch. Exporting Lovable Cloud data.

After importing, ask for these checks:

• Counts match: the expected number of customers, quotes and orders.
• Relationships hold: every quote still belongs to the right customer.
• Permissions work: Alice cannot read Bob’s data.
• A new record can be created, edited and read back.

A database imported without errors still needs to be checked inside the app. That is where you see whether your product has actually recovered its data.

3. User accounts and sign-in

An email address in a table does not guarantee its owner can sign in.

In Lovable Cloud’s documented migration process, passwords cannot be recovered for reuse: plan a password reset flow. Sign-in providers such as Google also need reconfiguration. Lovable’s backend migration guide.

That does not mean everyone should create a new account. You need to preserve identities and their links to existing data, then prepare the appropriate sign-in process for each method.

Test with an account created before migration: it should recover its documents, team and permissions. Check registration, password recovery and invitations too. If users need to do something, prepare the explanatory email before the move.

And if you keep your existing authentication service, do not reset everyone’s password by default: this work depends on what you actually move.

4. Files your customers uploaded

Avatars, photos, PDF contracts and attachments deserve their own inventory.

A database can contain a file’s address without containing the file itself. That is like keeping the label from a moving box while leaving the box in the old house.

For each storage area, check files, paths and permissions. After copying, open an old document through the app, then upload a new file and download it.

Test with another user too. A private contract must stay private. If file addresses change, check links already saved in the database or sent to customers.

5. The services that keep your product running

Your interface can look perfect while no emails go out and no subscriptions activate.

List every service: payments, email, Google sign-in, error tracking, AI features and automations. For each, record who owns the account, who pays, which access is required and where it is configured.

Secrets belong in a secrets manager. Your inventory records their names and locations, not their values. Plan to configure them again or issue replacements through the provider.

For server processes, check where the code runs and what triggers it. A daily reminder should run on the new setup without being sent a second time by the old one.

For payments, distinguish the provider’s account from your app. If you keep the same Stripe account, start by checking how customers and subscriptions map to your users. Then check webhooks: the messages that tell your app a payment or subscription change happened.

The useful test covers the whole chain: event received, subscription updated, correct access granted and no duplicates. The same principle applies in my analysis of an AI-generated Stripe checkout.

6. The domain and the keys to the house

Open the account managing your domain name. Check that you can change its settings and recover account access without depending on a contractor.

Keep the existing settings, especially email records. Changing where your website points should not remove your email configuration.

On the new host, test an internal page by opening its address directly, then refreshing it. Check sign-in links and links sent by email too. The homepage alone does not prove the move is complete.

Finally, decide who receives alerts, checks backups and responds to failed deployments. You can assign these jobs to managed services or a person. They simply need an owner. The production deployment guide covers these basics.

Switching over: rehearse before moving customers

Set up a validation copy separate from production. Disable real email sends, payments and automatic jobs during rehearsals.

Then replay the journeys that matter: an existing user signs in, finds their subscription, opens a document and creates a new record. Repeat with a second account to check permissions.

On migration day, explicitly handle what changed since the initial copy. If a customer placed an order in the meantime, it must reach the new database. Depending on your app, that requires a short pause on writes or a synchronization process prepared in advance.

Plan the rollback too. If the new app has already received orders, restoring the old app without reconciling the data can make those orders disappear from users’ view.

Keep the old environment available while validating the transition, with its automations controlled. Removing Lovable Cloud is permanent; download the required exports before deleting anything. Cloud removal documentation.

Your checklist before leaving

You can start this inventory while staying on Lovable. It will also help when bringing in a developer or having your application audited.

The export capabilities mentioned here were checked against official documentation on September 18, 2026. Consult the linked pages when migrating: features and limits can change.

Want to prepare your Lovable app for the move?

I can review how your product is built, identify what still depends on Lovable and suggest a migration sequence that fits your users. Let’s talk about your project.

For more practical guides on running a product built with AI, subscribe to the newsletter.