Mercaz runs school operations for thousands of families: enrollment, records, payments, communication. The whole platform was built fast on Lovable, and it worked. Then the team asked a simple question: "Can we get a copy of our database?"
The answer, effectively, was no.
The problem nobody warns you about
Lovable Cloud is a managed backend. That word "managed" does a lot of work. It means Lovable provisions the Supabase project for you, and it means Lovable holds the credentials. You can build on your data all day. You cannot take it with you.
For a hobby project, fine. For a school platform holding records for 5,000 students, that's an existential risk wearing a friendly UI.
Every consultant they spoke to before us said the same thing: rebuild from scratch, re-import what you can export by hand, and ask every family to create a new account. Months of work, guaranteed data gaps, and 5,000 password-reset emails to parents.
We took a different route.
What we actually moved
The final inventory, verified row by row on both sides:
- 800 database tables
- 1,200 row-level security policies, recreated and tested
- 8,000 stored files
- 5,000 student accounts. Every single login kept working, and every record came with it.
- 0 minutes of downtime
The interesting part isn't the size. Moving data between two Postgres databases is a solved problem. The interesting part is doing it when the source platform is built to stop you.
How you get data out of a platform that hides the keys
I'm not going to publish a step-by-step bypass guide, partly because the surface changes constantly and partly because half the value is knowing which of the six approaches fits your situation. But at a high level, the work looks like this:
1. Map everything before touching anything. You cannot verify a migration you haven't measured. We built a complete inventory of tables, policies, functions, storage buckets and auth users before moving a byte.
2. Extract through the front door, creatively. Even locked-down platforms have to let your own app read its own data. Between the client APIs your app already uses, edge functions, and Supabase's own tooling, there is always a legitimate extraction path. Finding it is the craft.
3. Rebuild security, don't just copy it. 1,200 RLS policies is where most migrations quietly go wrong. Policies that reference platform-managed roles won't survive a naive copy. Each one gets recreated against the new project and tested with real user tokens.
4. Preserve auth, or the migration failed. If your users have to reset passwords, you didn't migrate, you relaunched. Supabase auth can be moved so that existing credentials keep working. This is the single most-skipped step in DIY attempts.
5. Run both systems in parallel, then cut over quietly. The new environment ran alongside the old one, syncing, until every checksum matched. We switched traffic on a quiet evening. School opened normally the next morning. Nobody noticed, which was the whole point.
What this means if you're on Lovable Cloud right now
You don't have to leave. Lovable is genuinely good at what it's for. But you should know, today, what your exit looks like, because the best time to plan a migration is before you urgently need one. Pricing changes, feature ceilings and due-diligence questions all arrive on their own schedule, not yours.
If you can't answer "can we get a full copy of our database this week?", that's the sign.
We migrate live apps off Lovable Cloud, Bubble, and other closed platforms onto infrastructure you own, with zero downtime and users keeping their logins. If you're weighing it up, the audit that starts every migration is free, and it will tell you honestly whether you should move yet.
