Export the code and read it
Sync the Lovable project to GitHub or download it, then inventory what it does: pages, sign-up and login, uploads, emails, payments, and the backend project behind the data calls.
Declare the backend in stack.json
Handlers become functions when the code is Go and workers when it is JavaScript or TypeScript — generated apps are the latter. Records become tables, uploads become buckets, and anything scheduled becomes a workflow.
Export the builder’s backend data
Export the underlying database — usually Supabase Postgres — as CSV or JSON, reshape rows to the declared keys, and load. Copy stored files into buckets and verify counts with the live app’s numbers.
Cut over the domain and accounts
Move the domain to the KERNSTACK gateway after a preview rehearsal, with the password-reset flow ready for existing users. Keep the Lovable project published until traffic drains, then cancel it.
First, find out what the builder actually built
A prompted app hides its own architecture, so the migration starts with an inventory, not an export button. Connect the project to GitHub or download the code and read it: which pages exist, what the sign-up flow stores, where uploads go, which emails and payments fire, and which backend project answers the data calls. In most Lovable apps that backend is a Supabase project the builder provisioned — which means the database, storage, and auth moves follow the Postgres export path, with the same honest caveats about SQL queries and unexportable password hashes.
Treat the prompt history as a diary, not a specification. The code is the specification. Where prompts and code disagree — and after fifty edits, they will — the code is what your users run, and it is what you re-declare.
- AI features inside the generated app keep working: point them at the inference catalogue or a declared custom endpoint instead of the builder’s keys.
- Anything the builder’s hosting did invisibly — redirects, file serving, scheduled jobs — must be named explicitly as gateway routes and workflows.
- Domains connected inside Lovable move by DNS change at cutover; nothing about the domain is locked to the builder.
The app keeps running while it changes owners
Nothing in this migration requires the live app to come down. The generated interface keeps being served by the builder while the KERNSTACK project is declared, loaded with exported data, and rehearsed on a preview target. Cutover is a domain move plus the account step: users keep their records, and because a builder-managed backend rarely exports passwords, most teams fold a friendly password reset into the switch.
What changes after cutover is who can change the app and how. Edits stop being prompts accepted sight unseen: agents draft code and stack.json changes in a sandbox, a person reads the plan, and production takes the approved version. That checkpoint — not the hosting — is the actual product difference you migrated for.
Resource-by-Resource Mapping from Lovable
- Generated frontend (React/Vite-style app) →
gateway prefix route: The exported interface code builds and serves from the project. It is ordinary web code; the builder was never load-bearing for the screens themselves. - Builder-provisioned backend (usually Supabase) →
tables, buckets, workers: Postgres rows export and reshape into keyed tables, storage files copy into buckets, and server logic becomes nodejs workers. SQL-heavy queries face the same key-design decision as any Supabase exit. - Sign-up and login from the builder template →
gateway sign-in flow: User records move; passwords managed by the builder’s backend do not export. A reset-first-login flow is the standard cutover, communicated in the release notes. - In-app AI calls →
inference catalogue or endpoints: Replace builder-held API keys with catalogue models — text-embed-v1 at 3 credits per 1,000 tokens, sentiment-multilingual-v1 at 2 — or a custom inference endpoint you declare. - Scheduled or background behaviour →
workflows: Anything the generated app triggered on a timer or after an event becomes a declared workflow step calling workers, visible in the project plan. - Prompt history →
documentation, not configuration: Prompts explain intent; they do not migrate. The running code and the new stack.json are the specification afterwards — which is the point of moving. - Builder hosting and publishing →
gateway routes in your project: Redirects, headers, and file serving become route configuration you can diff. The domain moves by DNS whenever you are ready.
Frequently asked questions
With the code export and an hour of reading. Generated apps are conventional: a frontend, a backend project, a handful of integrations. List the user-visible behaviours — sign up, upload, pay, receive email — and trace each to code and data. That list is your migration plan; the prompts are not.
They can keep directing the work in plain language — agents draft the changes. The difference is the checkpoint: a named person reads the plan and approves it before production changes. Teams usually experience this as keeping the speed and losing only the surprises.
For the typical generated app — one backend project, a few tables, uploads, a payment and email integration — days, most of them spent on the inventory and the account cutover rather than mechanics. Apps whose builder-backend grew SQL-heavy queries inherit the Supabase timeline as well.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.