Lovable to Next.js: Complete Export and Migration Guide (2026)

1. Before You Start: Should You Actually Migrate to Next.js?

What it looks like: You want SSR, better SEO, or a framework you can hand to a traditional dev team. Lovable doesn't export Next.js natively, so you're planning to export the code and migrate it yourself.

The 2026 wrinkle: Projects created in Lovable after April 2026 ship on TanStack Start -- a full-stack React framework with server-side rendering built in, not Vite SPA. If your project is post-April 2026, open your package.json and check for @tanstack/react-start. If it's there, you already have SSR. Migrating to Next.js from TanStack Start is a framework swap, not a quick fix.

Migrate to Next.js if:

• Your project is pre-April 2026 (Vite + React) and you need SSR or SSG
• Your team has an existing Next.js monorepo and consolidation makes sense
• You need Next.js-specific features: ISR, server actions, or App Router middleware
• You're replacing Lovable-managed Supabase with a self-hosted instance and need server-side auth

Don't migrate if:

• You're post-April 2026 on TanStack Start -- you already have SSR
• Your SEO issue is thin content or missing meta tags, not rendering -- that's fixable without a framework swap
• The migration timeline exceeds your launch deadline by more than a week

2. What Lovable Actually Gives You When You Export

What it looks like: You click "Export to GitHub" in Lovable and get a repository. The stack depends on when the project was created.

Pre-April 2026 projects (most existing projects): React + Vite + TypeScript + Supabase. Client-side routing via react-router-dom. No SSR. All Supabase calls are in the client -- the supabaseClient is instantiated with createClient() using VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY env vars.

Post-April 2026 projects: TanStack Start + Vite + TypeScript + Supabase. Server-side rendering already active. If you export one of these and try to migrate to Next.js App Router, you're doing a full framework swap between two SSR systems.

What you will find in the export either way:

• Supabase calls scattered across components -- not centralized in one service layer
• Auth state managed via Supabase client-side listeners
• CSS using Tailwind with a tailwind.config.ts that references specific content paths
• Shadcn/UI components in src/components/ui/
• Dependency versions that were current at generation time -- which may not be the latest

3. The 5 Things That Break in Every Lovable to Next.js Migration

3a. Supabase Auth Breaks First

What it looks like: Users can't log in after migration, or they get logged in but the session doesn't persist across page loads. In the console: AuthSessionMissingError or silent redirect loops.

Why it happens: Lovable generates Supabase auth using @supabase/supabase-js with a browser client. Next.js requires @supabase/ssr for server-side session handling. The two packages handle cookies differently -- the browser client can't read the httpOnly cookies that Next.js server components expect.

How to fix it:

1. Replace @supabase/supabase-js browser client with @supabase/ssr: npm install @supabase/ssr. Do not run both packages simultaneously -- they conflict.
2. Create two separate client utilities: one for Server Components (createServerClient) and one for Client Components (createBrowserClient).
3. Add middleware to middleware.ts that refreshes the session on every request.
4. Update Supabase dashboard: Authentication > URL Configuration: add your new Next.js domain to Site URL and Redirect URLs.

When to call an expert: If you're seeing different auth behavior between local and production after fixing the above, the issue is usually Vercel's edge runtime stripping cookies. That's a 30-minute fix in isolation but hard to diagnose without seeing the full middleware chain.

3b. Environment Variables Break on CI

What it looks like: The app runs locally but the Vercel/Netlify build fails with process.env.VITE_SUPABASE_URL is undefined or auth silently fails in production.

Why it happens: Lovable uses VITE_* prefix for env vars (Vite convention). Next.js requires NEXT_PUBLIC_* for client-accessible vars. In 2026, Supabase also deprecated the legacy anon key format in favour of sb_publishable_xxx keys -- if your Lovable project pre-dates this, the key format itself may be changing under you.

How to fix it:

1. In your Next.js project, rename all VITE_SUPABASE_URL to NEXT_PUBLIC_SUPABASE_URL and VITE_SUPABASE_ANON_KEY to NEXT_PUBLIC_SUPABASE_ANON_KEY.
2. Do a global search for any other VITE_ prefixed variables in the codebase and rename them.
3. Add all renamed variables to Vercel's environment variables dashboard before deploying.
4. If you're using Supabase's new publishable key format, update the key value too -- not just the variable name.

3c. File-Based Routing vs. React Router

What it looks like: All your routes are defined in a single App.tsx with <Routes> and <Route> components. Next.js App Router expects a app/ directory with page.tsx files.

How to fix it:

1. Map each <Route path="/x"> to an app/x/page.tsx file. Remove react-router-dom from dependencies after the migration.
2. Replace all useNavigate() calls with Next.js router.push() from useRouter().
3. Replace all <Link to="/"> with Next.js <Link href="/">.
4. Move any layout wrapping (nav, footer) to app/layout.tsx.

3d. Case-Sensitive Import Paths Fail on Vercel

What it looks like: The build works locally on macOS but fails on Vercel's Linux build server with Module not found: Can't resolve './Components/Button'.

Why it happens: macOS file system is case-insensitive by default. Linux is not. Lovable sometimes generates imports like import Button from './Components/Button' while the file is actually at ./components/button.tsx.

How to fix it: Run a recursive search on your src/ directory for import paths and fix any where the capitalisation doesn't match the actual filename. Enable TypeScript's forceConsistentCasingInFileNames: true in tsconfig.json to catch this class of error at compile time.

3e. Supabase RLS Is Still Off

What it looks like: After migration, authenticated users can read and write each other's data. No error -- it just silently works when it shouldn't.

Why it happens: 89% of Lovable apps we've audited have Row Level Security disabled on their Supabase tables. The migration to Next.js doesn't enable it -- you have to do it explicitly in Supabase dashboard before going live.

How to fix it: In Supabase dashboard > Table Editor > each table > RLS > Enable. Then add at minimum: USING (auth.uid() = user_id) for user-owned rows.

4. Step-by-Step Migration

This sequence minimises back-tracking. Don't skip to step 4 before step 2 is working.

1. Export and bootstrap: Export from Lovable to GitHub. Create a new Next.js 14+ project with App Router: npx create-next-app@latest my-app --typescript --app. Don't start copying files yet.
2. Get it running locally first: Clone your Lovable export. Run npm install && npm run dev. Fix any dependency errors before migrating anything.
3. Copy UI components: Move src/components/ui/ (Shadcn) into the Next.js project first -- these are framework-agnostic and usually move cleanly.
4. Migrate routing: Convert each React Router route to an app/ page file. Don't connect to Supabase yet.
5. Fix the auth layer: Install @supabase/ssr, wire up the server client, browser client, and middleware. Test login before anything else.
6. Migrate Supabase data calls: Move supabase.from('table').select() calls into Server Components where they can run server-side, keeping only truly interactive calls in Client Components.
7. Fix imports, env vars, and TypeScript: Run npx tsc --noEmit. Fix every error -- don't ignore them. Deploy to Vercel preview (not production) and verify the build passes.
8. Enable RLS: Before pointing your domain at the production build, enable Row Level Security on all tables.

5. When Self-Migration Stops Making Sense

Most of the issues above are solvable with the steps provided. Some situations signal that continued self-migration has diminishing returns:

• Your Supabase schema is complex -- multiple tables with inter-table RLS policies, custom auth claims, or database functions that reference specific auth.uid() patterns don't migrate cleanly with find-and-replace
• You're on a launch timeline -- every week the migration extends is a week your app isn't generating revenue or attracting investors
• You need SSO, custom JWT claims, or webhook-driven auth -- these require server-side patterns that are significantly different from Lovable's client-only approach
• Your team doesn't have Next.js experience -- App Router is genuinely different from Pages Router and from Vite SPA; the learning curve is real

6. Migration Path Comparison

Related Guides

• Lovable app won't deploy to production -- fix guide 2026
• Lovable troubleshooting guide: 10 most common errors
• Lovable app rescue and completion -- when you need more than a migration guide

FAQs