Lovable migration
Move your app off Lovable to code you own — with or without AI tools
Lovable got you a working product fast. Now you want the repository, the database, the domain and the deploy in your own hands, and a codebase a normal engineer can work in. We migrate Lovable apps to custom code — written by our team, with Claude Code and Cursor where they help, never where they hide — and we keep the app running while we do it. We moved our own site off Lovable in September 2026.
The audit tells you what is actually locked in. The call tells you what it takes to get it out.
Why people leave
What Lovable does not carry across on its own
Exporting the code is the easy part — GitHub sync has done that for a year. What stays behind is everything the code points at.
The database is Supabase, shaped for the demo
Row-level-security rules written by a generator, tables built for the first screen, and no migrations history you can trust. Moving the data is a project; moving it without downtime is the job.
Images and files live on Lovable's CDN
Every upload went to a bucket you do not own. Ours had 33 brand images that existed nowhere else. Leave the project before copying them and they are gone.
The domain and the deploy are theirs
yourapp.lovable.app is Lovable's hostname. Bookmarks, SEO, cookies and email links all point at it. The cutover has to be planned, not clicked.
Secrets sit in the browser bundle
Generated apps call the database from the client, so the key that opens it ships to everyone. The fix is a server between the browser and the data — which is why 'export and host it elsewhere' is not enough.
Auth is welded to Supabase
Sessions, Google sign-in, password resets and the users table are one thing. They have to be re-created on the new side and swapped without logging everyone out.
Nobody can explain the code
Prompts produced it; no one designed it. Before it can be maintained it needs a data model somebody chose, boundaries somebody drew, and tests somebody wrote.
What you get
A codebase, a database and a deploy that are yours
We leave behind a system a hired engineer can take over on Monday. The stack is mainstream on purpose.
Your repository, your history
Code in your GitHub organisation from day one, with commits that say why, and a README that a new engineer actually reads.
A real backend and API
The browser talks to an API; the API talks to the database. Access rules live in tested code, not in a policy a generator wrote. Node/TypeScript or Ruby on Rails — your call, our recommendation.
Your data, moved without downtime
Exported, reshaped where the schema needed it, imported, verified against the live app, and cut over with one DNS change. The old system stays up as a fallback for a week.
Auth that survives the move
The same users, the same Google sign-in, sessions re-issued on the new side — nobody signs up twice.
Assets and uploads under your control
Every image and file copied to storage you own, served through your domain, with the URLs the search engines already know redirected.
Hosting you can leave too
Docker, a plain server or a cloud you already pay for, CI that deploys on push, backups you have watched restore, and a runbook. No proprietary layer, including ours.
How the migration runs
Four steps, and the app stays up throughout
We migrate in slices, riskiest first. Your users keep using the Lovable app until the new one has proved itself beside it.
- 01
Audit and inventory
One to two weeks. The free audit first; then we read the exported code, map every table, every bucket, every third-party key, and write down what survives and what gets rebuilt. You get the plan and a fixed price.
- 02
Backend and data first
The API, the data model with the traps closed, the access rules with tests, and the migration script that moves the data. Run against a copy until it is boring.
- 03
Front end reconnected
Your React UI keeps its flows and its look; it stops calling Supabase and starts calling your API. Where Claude Code or Cursor speed this up, we use them — and review every line as if a junior wrote it.
- 04
Cutover and fallback
Assets copied, redirects in place, DNS flipped when you say so, the old app kept for a week. Then the runbook, the handover session, and a roadmap for what to do next.
We did it to ourselves first
goluxgroup.com ran on Lovable and Supabase until September 2026
The public site and the client portal behind it were built with Lovable. We moved them to a Rails API and a server we own, kept the Google sign-in and the data, and cut over with a single DNS change. Every trap on this page is one we found in our own project.
- 143
- Supabase row-level-security policies rewritten as tested application code
- 312
- API tests that fail if an old access rule stops holding
- 33
- brand images that existed only on Lovable's CDN
- 1
- DNS change to cut over, old site kept as fallback
Is this the right page?
For founders who have decided, or nearly decided, to leave
This is for you when
- The app has users, revenue or a contract that depends on it
- You want the code, data and domain in accounts with your name on them
- A customer or investor has asked who controls production
- Feature work on Lovable has become slower than it was
- You want to keep using AI tools to build — on a foundation that is yours
Not yet, when
- You are still validating the idea — stay on Lovable, ship, and run the free audit when the first customers arrive
- You want to stay on Lovable and build better there — see Lovable development help instead
- The app only needs its risks fixed, not a new home — the two-week hardening sprint does that without a migration
Questions
Migrating off Lovable, answered
- Can you migrate from Lovable to a stack other than React?
- The front end is usually worth keeping — it is the part Lovable does well and the part your users know. The backend is where the choice is: Node/TypeScript when your team will be JavaScript people, Ruby on Rails when you want the most product per engineer-hour. We recommend, you decide.
- Do we have to leave Supabase too?
- No. Supabase as a managed Postgres behind your own API is a fine setup. What has to go is the browser talking to it directly with generated policies. Some clients keep Supabase; some move to a managed Postgres elsewhere. The audit settles it.
- Will you use Claude Code or Cursor to do the migration?
- Where they are faster and the output is reviewable, yes — scaffolding, tests, repetitive conversions. Where judgement is the work — the data model, access rules, the cutover — a senior engineer does it by hand. Every line, whoever or whatever wrote it, is reviewed before it ships.
- How long does a Lovable migration take?
- The audit and plan: one to two weeks. A focused migration of a typical Lovable SaaS — auth, data, API, cutover — six to twelve weeks, with the app live throughout. Bigger products go in slices so value ships continuously.
- What does it cost?
- The audit is free. The plan comes with a fixed price for the migration, and the price of the two-week hardening sprint counts towards it if you start there. Our project calculator gives a range in five minutes.
- Can we keep shipping features on Lovable during the migration?
- Yes, within reason. We freeze the data model, not the product; features that touch tables we are moving wait a sprint. Everything else keeps going, and we carry it across.
- What happens to our Lovable project afterwards?
- Keep it until every asset is copied and the redirects have run for a month — we learned that one the hard way. Then archive it. Nothing in the new system depends on it.
- What if we do not want to leave after all?
- Then we say so on day two of the audit. Sometimes the right answer is the hardening sprint on Lovable-hosted code, or Lovable development help to build better there. We would rather keep a founder than sell a migration.
Other paths from here
- The free production-readiness auditSee what is actually exposed before you decide anything. Sixty seconds.
- MVP hardening sprintFix the risks in two weeks without a migration. Counts towards one later.
- Lovable development helpStaying on Lovable? Product, design and architecture help to build it right there.
- Claude Code app reviewBuilt with Claude Code instead? Architecture review and optimisation for AI-written codebases.
- From vibe-coded MVP to productionThe full story, for any AI builder.
- How we run projectsEvery migration runs in Golux Club: tickets, approvals, one record you can see.
Next step
Bring us the Lovable project. We will tell you what it takes to own it.
Free audit first, then a written plan with a fixed price. No obligation, and the app stays up either way.
