How to migrate off Lovable, Bolt or v0, step by step.

Migrating off an AI builder means getting the code into a GitHub repo you own, rebuilding the services the builder quietly ran for you (database, permissions, environments, backups), and deploying to infrastructure you control. A small working system makes that move in 2–4 weeks for ₪3K–18K, penetration testing included.

This is the migration chapter of our complete guide to taking a Lovable prototype to production. The guide covers the four milestones every project passes through; this article is the technical path inside them.

01Get the code into a repo you own

The first step is the same on every builder: connect GitHub and make sure the repo sits under your account, not the platform's. All three major builders allow it, each with its own catch.

Lovable has two-way GitHub sync, but by its own documentation it edits and syncs one branch at a time, so treat the synced branch as a handoff point rather than a workflow. Bolt connects to GitHub or downloads the project as a zip, and either way you get code that needs Node.js and your own editor to run. v0 exports code and syncs with GitHub as well, and Vercel states plainly that it doesn't own the code generated from your prompts. Whether the export makes the product practically yours is a separate question; the five checks we run are in who owns the code your AI builder wrote.

02Know what the export leaves behind

The export is your application code. It is not your application. What stays behind on the platform: your live data (Bolt, for example, copies your table structure when duplicating a project, but not the data in it), your secrets and API keys, the permission checks, and the hosting itself.

The reason is simple: builders run those parts on their own infrastructure so that a prototype works instantly. The migration is mostly the work of rebuilding exactly those invisible parts under your control, and that's why downloading the zip takes an afternoon while the migration takes weeks.

03Rebuild in this order

Six moves, in a fixed order, because each one is tested against the one before it:

• Map the system: every table, secret, integration and scheduled job the app touches, written down before anything moves
• Move the data: a real database with versioned migrations, then automated backups with point-in-time recovery
• Enforce permissions on the server: row-level security and server-side authorization, so the browser is never the only gatekeeper
• Split environments: separate dev and production with CI/CD, so a bad change gets rolled back instead of debugged live
• Add monitoring: error tracking and alerting, so drift is caught by a system instead of by a user
• Cut over: DNS, acceptance testing with real accounts, and a penetration test before release

04Why can't I just stay on the builder?

You can, and for a demo you should. The problems start when real users and real money arrive.

Permissions in builder-generated apps usually live at the browser level, with no server-side control over what a function is allowed to do. That demos perfectly, and it is easily penetrable. The specific holes are documented in security holes we keep finding in AI-generated apps. Cost is the quieter failure: one client's automated app, left unsupervised for a day with no spending caps, produced an AI bill of over $1,000. The prototype worked. The guardrails didn't exist.

There's also a slower reason. As long as deploys, data and the domain run through the platform, you're renting the product, whatever the export button says.

05What the move costs, and how long it takes

A small working system comes off the builder in 2–4 weeks at ₪3K–18K, which is our Decouple & Stabilize tier. Larger platforms run 2–5 months, depending on integrations. Every delivery carries a 14–30 day bug-fix warranty, and the full tier breakdown is on the pricing page.

The work runs through four milestones with a sign-off at each: spec, design, development, delivery. Fity, a WhatsApp bot that helps fitness coaches manage more trainees online, made exactly this move; it arrived as one monolithic file that kept breaking and left as a secured app with a proper backend, frontend and database. Because working code existed, we rebuilt on their base. That's the difference between a migration and a rewrite, and the price follows that difference in scope.

Straight answers to the questions founders ask before starting a migration are on the FAQ page.