What "migrating" can mean
When someone tells us they want to migrate off Lovable, we have learnt to ask which of four things they mean, because each leads somewhere different.
The first is moving the hosting. The app keeps its code and its data and simply runs somewhere else. This is the smallest move, and for a static front end it can be an afternoon.
The second is moving the backend: the database, the user accounts, the uploaded files, the functions that run on a schedule. This is where the real work lives, and it is the one most people mean.
The third is owning the process: being able to change the app without Lovable's editor, through a repository, a review and a deployment you can explain to someone else. This can be done while the app still runs on Lovable, and it is often the right first step.
The fourth is a rebuild. Sometimes the generated code has drifted so far from what the business needs that starting again, with the old app as a very precise specification, costs less than untangling it. A few builders offer no code export at all, which makes this the only route.
Which of these is yours? It is worth answering before reading on, because the cost and the timeline differ by an order of magnitude between the first and the fourth.
Why building on Lovable was a reasonable call
A year or two ago the choice was between a builder that could produce a working app in a weekend and a development quote that started at five figures and ended months later. Picking the weekend was sensible. The app exists, it has users, and those users have taught you things about the business that no specification would have. That knowledge is worth more than the code, which can be rebuilt.
The feeling that comes with outgrowing a builder tends to be a kind of embarrassment, as if the right move had been obvious all along. From where we sit it looks like a good decision that has done its job, which is what early decisions tend to do.
What usually moves cleanly
The code is the easy part. On most builders, Lovable among them, the front end can be synced to a repository or downloaded, and what you get is an ordinary web project in a mainstream framework. A developer can usually have it running on a laptop within the hour. The database schema usually comes along as migration files, which are the recipe for recreating the tables rather than the tables themselves.
The design can stay where it is. One approach we use often is to keep the builder as the design surface, so the people who made the app keep making its screens the way they are used to, while the backend becomes something you own. The builder's backend is replaced by a mock inside the editor and by the real thing in production.
What needs its own plan
State is the hard part, and three kinds of state in particular. User accounts come first: if people sign in with a password, the hashes live in the builder's authentication service, and whether they can move without everyone resetting their password depends on the platform and on that service. Uploaded files come second: they sit in a storage bucket that no code export touches. Secrets come third: the API keys for email, payments and AI models are kept out of every export on purpose, which is correct, and which means someone has to collect them.
Then there is everything Lovable connected for you. A webhook from a payment provider points at a URL on Lovable's domain. A scheduled job runs on Lovable's scheduler. Each of these is small on its own and easy to miss as a group. We keep a one-page list for every migration, and it is usually longer than the client expected and shorter than they feared.
The questions worth asking before launch day
Security is the part that generated apps tend to get wrong in the same few ways. An automated scan of about a thousand AI-generated apps across Lovable, Bolt, Replit, Vercel and others, published by Stefan Lederer of securityscanner.dev in April 2026, reported that 183 of its 190 critical findings were misconfigured row-level security on Supabase databases, which in practice means any signed-in user can read other users' rows. The same scan flagged 38 apps with API keys sitting in the JavaScript bundle, and a few API endpoints with no authentication at all. One scan is one scan, and the figures will have moved since it ran. The pattern, though, matches what we find when we open a generated codebase for the first time.
Three checks cover most of it, and none of them needs a migration to run: searching the loaded JavaScript for the word "key" in the browser's developer tools on the live app, signing in as one user and trying to fetch another user's record by changing an ID in the address bar, and listing every API route the app has and asking, for each one, who is allowed to call it. If those three come back clean, the app is in better shape than most. If they come back with findings, it is better to know while the app is still on Lovable than on the first morning it is on infrastructure you are responsible for.
What leaves Lovable with you
Lovable's own documentation is unusually clear on this, which makes the planning easier. On every plan, including the free one, a project can be connected to a repository on GitHub, GitLab or Bitbucket, and Lovable keeps the two in sync in both directions. Paid plans can also download a one-time snapshot of the codebase as a zip. Either way, what you get is the application source, the configuration files and the database migration files stored in the project. Lovable states plainly that neither route includes the records in your database or the files in storage.
Which stack you receive depends on when the project was created. Projects started from 13 May 2026 are built on TanStack Start and need a host that can run a server. Older projects are React with Vite and build to a folder of static files that any CDN can serve. The difference matters when you pick where the app will live next.
The backend is the part that needs its own plan. Lovable Cloud is Supabase underneath, and it does not move on its own: the documented path is a new Supabase project of your own, the migrations applied to it, and the data exported from the old one and restored into the new one. At the time of checking, Lovable Cloud offered a database export that includes user accounts, which is the piece people most often forget until the week of the cutover. The app then needs two environment variables changed, VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY, and a rebuild, because those values are baked in at build time.
One line from their documentation is worth keeping in mind as you decide: "Lovable cannot monitor or debug infrastructure it does not control." That is a fair description of the trade. Once the app runs somewhere you chose, the monitoring, the patches and the backups are yours, or they are whoever you ask to look after them.
How we tend to approach it
Our default, when a client wants to own the result, is a Go backend on PostgreSQL, deployed to a cloud region in Singapore, with the builder kept as the place the front end is designed. Go and Postgres are boring in the best sense: most developers you hire later will know them, and both are easy for an AI assistant to read and change, which matters more now than it did two years ago. The front end keeps a mock data mode so the builder's editor still works, and a real mode that talks to the new API. The cutover happens once the real mode has run alongside the old backend for long enough that nobody is nervous.
We still get the timing wrong on one part more than any other: user authentication. Moving accounts is rarely hard technically, and it is almost always the step that produces the support emails. We now plan for a week of those where we used to plan for a day.
A scene, to make it concrete
Picture a nine-person logistics firm in Jurong. The operations lead built a delivery-tracking app on Lovable over two weekends, and the drivers have used it every day for eight months. The trigger for the conversation is a tender: a prospective customer's security questionnaire asks where the data is stored and who has access to it. The honest answer involves a vendor's data centre in another country and an admin login shared by three people. The app is doing its job, and the questionnaire now needs an answer the current setup cannot give.
In that situation the migration is mostly the second kind: move the data and the accounts to a database in Singapore, put the API behind a login with roles, and leave the screens exactly where they are. The drivers would not notice anything, and the questionnaire would get a different answer. The firm is hypothetical; the shape of the situation is one we have met more than once.
Questions to take into your next conversation
- What changed, specifically, that made leaving Lovable feel necessary this month and not six months ago?
- Which part of the app do you change most often, and who changes it?
- Where does the data live right now, and who could answer that without checking?
- If Lovable's editor disappeared tomorrow, what would you miss most?
- Who will get the alert when the app is down at two in the morning?
If it would help to think these through with someone outside the team, we offer a short discovery call for exactly this, and we are glad to say if staying put is the better answer.
Leaving a different builder? Bolt · Emergent · Replit · Riff · Zite