By Mehdi HassanLovable is a fast way to get an app in front of users. The question comes later, when a team needs to own the code or the marketing pages need to rank. This guide covers what you get out of Lovable today, how routing and rendering change, and how to bring Supabase and auth with you. It's part of our guide to outgrowing a website builder.
What does a Lovable export include in 2026?
A Lovable export gives you the full source code of a React app, synced to a Git repository you own, plus the database migration files that define your schema. It doesn't include the data itself, uploaded files, or the settings that live on Lovable's side.
Which stack you get depends on when the project was created. Lovable's documentation says TanStack Start became the default for new projects on May 13, 2026. Older projects run on Lovable's React and Vite stack, typically with TypeScript, Tailwind CSS, shadcn/ui components and React Router. Check your package.json: if you see vite and react-router-dom, you have a single-page app; if you see TanStack Start, you already have server rendering.
Part of the app | Comes with the code export? | How to move it |
|---|---|---|
React components and pages | Yes | Git sync or zip download |
Database schema | Yes, as migration files | Run them on the new database |
Database rows | No | Export the data separately |
Uploaded files (storage) | No | Download and re-upload |
Auth users and settings | No | Move with the backend, reset redirect URLs |
Edge functions | Code yes, secrets no | Redeploy and re-enter secrets on the new host |
Git sync works with GitHub, GitLab or Bitbucket on all plans, according to Lovable's docs. With GitHub, Lovable creates a private repository in the account you choose and syncs one branch both ways. The zip download of the codebase needs a paid plan.
Do you need Next.js, or is Lovable's TanStack Start upgrade enough?
If your only problem is search visibility, try Lovable's in-place upgrade to TanStack Start first. Move to Next.js when you want to stop building in Lovable altogether and put the app in a framework your team, CMS and hosting are already built around.
For older React and Vite projects, Lovable says it serves pre-rendered copies of published pages to verified search engines and social preview bots, while other crawlers see very little content. The TanStack Start upgrade renders full HTML on the server for everyone, and Lovable lets you revert it from version history. That solves the rendering problem without a migration.
- Upgrade inside Lovable if you want to keep building with Lovable's agent and mainly need pages that render on the server.
- Move to Next.js if a development team now owns the product, you want a CMS such as Payload in the same app, or your marketing site already runs on Next.js.
- Rebuild the marketing site separately if the app is fine where it is and only the public pages need design, content and SEO work.
The third option is underrated: founders usually want the landing page to rank, not the dashboard. A separate site on Next.js, Framer or Webflow is often cheaper than migrating both.
How do you migrate from Lovable to NextJS step by step?
You migrate from Lovable to Next.js by first getting the existing app running inside Next.js as a client-only app, then moving routes and rendering over one piece at a time. The official Next.js guide to migrating from Vite follows the same incremental approach, and it's the right starting point for older Lovable projects.
Take ownership of the code
Connect Git sync, confirm the repository sits in your company's account, and decide when to stop editing in Lovable. Two-way sync plus refactoring means conflicts.
Inventory the backend
List tables, row-level security policies, storage buckets, edge functions, auth providers, secrets and every third-party service the app calls.
Wrap the app in Next.js
Install Next.js, turn index.html into a root layout, and load the existing App component through a catch-all route with server rendering switched off. The app should run unchanged.
Rename environment variables
Variables prefixed VITE_ become NEXT_PUBLIC_ if the browser needs them. Anything secret stays unprefixed and is only read on the server.
Move routes to the App Router
Recreate each React Router route as a folder with a page file, starting with public pages. Swap Link and navigation hooks for Next.js equivalents as you go.
Server-render the public pages
Make the homepage, pricing, blog and other indexable pages server components with real metadata. Keep interactive pieces as small client components.
Move auth to cookie-based sessions
Replace the browser-only Supabase client with server and browser clients that share a cookie session, and protect routes on the server.
Test, redirect and cut over
Crawl both versions, map any changed URLs to redirects, run the main user flows end to end, then switch the domain.
How do React Router routes map to the Next.js App Router?
React Router routes map to folders in the Next.js app directory: each route becomes a folder with a page file, shared layouts become layout files, and URL parameters become bracketed folder names. Most of the work is mechanical, which is why AI coding tools help here.
Lovable (React Router) | Next.js App Router | Note |
|---|---|---|
Route in App.tsx | Folder with page.tsx | One folder per URL segment |
Shared layout with Outlet | layout.tsx | Wraps every page below it |
/blog/:slug | app/blog/[slug]/page.tsx | Params arrive as a prop |
Link from react-router-dom | Link from next/link | Uses href instead of to |
useNavigate | useRouter from next/navigation | Client components only |
Catch-all 404 route | not-found.tsx | Returns a real 404 status |
Helmet or document.title | metadata or generateMetadata | Rendered into the HTML |
Components that use state, effects or browser APIs need the use client directive. Lovable apps are client code throughout, so expect to add it widely at first and remove it as data fetching moves to the server.
What happens to Supabase and auth when you leave Lovable?
Your app can keep using the same backend after the move, so the frontend and the database don't have to migrate on the same day. What changes is how the Next.js app talks to Supabase, and where the backend lives if you're on Lovable Cloud.
There are two cases. If you connected your own Supabase project, it's already yours: point the Next.js app at it and you're done with hosting. If the app uses Lovable Cloud, the built-in backend, Supabase's own documentation says there's no automated way to transfer it to your Supabase account. You create a new project, run the schema migrations from the repo, export and import the data, re-upload storage files, redeploy edge functions and reconfigure auth. Moving only the Postgres database, Lovable's docs warn, leaves auth, storage and edge functions behind.
On the Next.js side, use Supabase's server-side package, which creates a browser client and a server client that share the session through cookies. Next.js 16 calls the file that refreshes sessions before each request proxy.ts, the file previously named middleware. Then add the new domain to your auth provider's allowed redirect URLs.
Hypothetical example: a SaaS MVP with a landing page and a dashboard
For example, suppose a founder built a scheduling MVP in Lovable before May 2026: a landing page, pricing, a blog with five posts, and a logged-in dashboard, all on Lovable Cloud.
A sensible plan would rebuild the public pages as server-rendered Next.js pages with a CMS. The dashboard would move across almost unchanged as client components behind a server-side auth check. The backend move to the founder's own Supabase project would come later, once the new frontend is stable.
How do you protect SEO and rendering during the move?
Protect SEO by server-rendering every page you want indexed, keeping URLs identical where you can, and redirecting any URL that changes. A Lovable single-page app sends crawlers a nearly empty HTML shell, so the move should improve how crawlers read your pages.
- Metadata per page. Give each public page its own title, description and social image through the Metadata API.
- Sitemap and robots. Generate them from your routes and content with sitemap.ts and robots.ts.
- Redirects. Map every changed path in next.config, and keep old paths working for at least as long as they appear in search results.
- Performance. Use the Next.js image and font components, and check field data after launch; our guide to Core Web Vitals on Next.js and other platforms lists the usual fixes.
If the public pages need a CMS, add it during the move rather than after. We run Payload inside Next.js on our own site, and our notes on setting up Payload for a marketing site cover the decisions.
Should you migrate a Lovable app yourself or hire a team?
Migrate yourself if the app is small, you're comfortable reading React and SQL, and no paying users depend on it yet. Bring in a team when real customers, payments or sensitive data are involved, because the risky parts are access rules and auth, not the routes.
A team also helps when the move is a product step: a design system, a marketing site that converts, and code more than one developer can change, as in our MVP design service. Our website design process shows how we sequence words, design and code, and if you want a sense of what one focused week can ship, read what a trial week can realistically deliver.
