The code is the easy part. What traps most people is everything the app leans on that never lived in the repository in the first place.
The usual version of this: the app works, users are on it, and then you need a real domain, a backup you control, or a buyer asks where it runs — and it turns out the answer is “inside somebody else’s account.”
What Lovable actually gives you
More than people expect. Lovable can sync your project to your own GitHub repository, and what lands there is an ordinary front-end project — usually React with Vite. You can clone it, install dependencies and build it locally. Nothing exotic, no proprietary compiler.
So if all you have is a static front end with no backend, you are close to done: build it, put the output behind any host, point DNS at it. Most people are not in that situation, because the moment an app has logins or saves anything, it has a backend — and on Lovable that backend is Supabase.
The job
Four migrations, not one. They fail differently.
01
The front end
The React build. Genuinely straightforward — this is the part everyone assumes is the whole task.
02
The database
Postgres underneath Supabase: your tables, your rows, and the row-level security policies that decide who can read what. The policies matter as much as the data.
03
Authentication
Your existing users, and specifically their password hashes. Get this wrong and every user is locked out on cutover day.
04
Storage and functions
Uploaded files live in object storage, not in the database. Server-side functions run on the vendor’s runtime and need somewhere new to run.
The two at the top cross over with ordinary tooling. The three below them are where migrations actually fail — none of them travel in a database dump.
Two honest paths
Path A — run Supabase yourself
Supabase is open source and ships a self-hosted stack. You stand it up on your own server, restore your database into it, and point the app at the new URL. The application code barely changes, because it is still talking to the same interfaces.
This is the shortest route, and it preserves auth cleanly — your users and their hashes come across with the rest of the database. The cost is that you now run several services instead of one, and they are yours to keep alive, patch and back up.
Path B — replace Supabase with a plain backend
Keep the front end, put ordinary Postgres behind it, and write a small server that owns the database access. Fewer moving parts, and nothing vendor-shaped left in the stack.
The catch is auth. Moving password hashes into a different auth system is the part that quietly goes wrong, and if it cannot be done cleanly your users get a forced password reset — survivable, but it is a conversation you want to have before cutover, not during.
Row-level security also needs re-thinking rather than copying: rules the database used to enforce now have to be enforced by your server, and “we’ll add that later” is how data leaks between accounts.
Where migrations actually go wrong
Storage gets forgotten. A database dump does not contain uploaded files. The app comes up looking healthy and every avatar and attachment is a broken link.
Secrets were only ever in the vendor’s dashboard.API keys for payments, email and third-party services are not in the repository. Inventory them before you cut over.
Nobody tested the restore. A backup you have never restored is not a backup. Do it once, on purpose, before you need it.
DNS was flipped before the new stack was verified. Bring the new environment up on a temporary hostname, click through it as a real user, and only then move the domain.
Webhooks still point at the old URL. Payment providers and integrations keep calling the vendor’s endpoint until you go and change them.
Before you cut over
Full database dump taken, and restored somewhere at least once
Storage bucket contents copied and spot-checked
Every secret and API key accounted for outside the vendor dashboard
A real login tested end to end with an existing user account
TLS working on the new host before DNS moves
A rollback you could execute in ten minutes
Or have it done
This is a day of work if you have done it before and a long weekend if you have not. We do it for a living: your code in your repository, your database on your server, your domain and certificates in your account, plus a pipeline so the next deploy does not need us.
From $600 — about a day of work once we have access. Worth knowing in advance: on most jobs the engineering is short and the waiting is long, because it takes time to find who holds the server credentials. Gather those first and the whole thing compresses.
If we look at your app and think it cannot be moved cleanly, we tell you that instead of taking the job.
Tell us what you built and where it runs. You get back whether it can be moved, what the real scope is, and a fixed price — usually within one business day.