Lovable to Next.js Conversion Prompts for Cursor

TL;DR: First verify that the export is an older React/Vite project and that a Next.js port solves a measured problem. Then use the planning prompt and one Cursor prompt per migration slice. These templates do not describe a TanStack Start migration.

A Lovable.dev to Next.js conversion prompt should not ask an AI agent to rewrite the whole app in one pass. These copy-paste prompts target older Lovable React/Vite exports. New Lovable projects use TanStack Start with SSR, and older hosted apps are prerendered for verified crawlers, so inspect the package, published HTML, and actual SEO or ownership gap first. If a direct legacy port is justified, use one planning prompt, then narrow slices for auth, billing, one indexable route, and one dashboard route. For the full order of work, read the step-by-step conversion playbook; for deeper Supabase and cutover decisions, read the engineering guide.

A mega-prompt gives an agent too much surface area at once. It can make plausible choices about Supabase sessions, Stripe webhooks, redirects, and metadata without knowing which choices your product depends on. Fill in real routes, tables, providers, and acceptance checks before using the templates below.

Before you prompt: collect the facts

Paste only facts you are comfortable sharing with the AI tool you are using. Do not paste secret values. Use key names, route names, table names, and expected behavior instead.

• Current Lovable repo structure, package manager, and verified framework from its package and router files.
• Published URL and the actual HTML and indexing evidence behind the reason to move.
• List of public routes, protected routes, and dynamic routes.
• Supabase tables used by the app and whether RLS is enabled.
• Auth providers and callback URLs.
• Stripe, Mailgun, OpenAI, or other integrations by name only.
• Public URLs that already rank or receive traffic.
• Commands the repo must pass before a slice is accepted.

Planning prompt: turn the Lovable export into a migration map

You are assessing an older Lovable export for a possible Next.js App Router migration.

Goal:
Create a migration map only. Do not edit files yet.

Current app:
- Framework: [copy verified framework and version from package.json]
- Routing: [copy verified router and route list]
- Reason to port: [measured rendering, ownership, auth, or integration gap and evidence]
- Data: Supabase tables [paste table names, not secrets]
- Auth: [magic link, OAuth providers, roles]
- Integrations: [Stripe, email, analytics, etc.]
- Deployment target: [Vercel, Fly.io, or other]

Target app:
- Next.js App Router
- TypeScript
- Tailwind/shadcn UI preserved where possible
- Supabase SSR for cookie-based sessions
- Server-rendered HTML for public SEO routes

Output:
1. Confirm the source uses the older React/Vite and React Router pattern. If it uses TanStack Start, server functions, or another framework, stop: these prompts are not its migration plan.
2. State whether the supplied evidence justifies a port; if the reason is SEO, compare published crawler-visible HTML and indexing evidence with the desired outcome before proposing a rewrite.
3. Route mapping from the verified source router to App Router paths.
4. Components that can copy across unchanged and those that must stay client components.
5. Supabase calls that should move server-side, with identity and RLS checks.
6. Env vars that may safely become NEXT_PUBLIC_ vs server-only values that need rotation if exposed.
7. Integration callbacks that must be updated before launch.
8. A slice-by-slice migration order where each slice can compile, test, deploy, and roll back.

Constraints:
- Do not expose service-role keys to the browser.
- Do not change public URLs that already rank unless you also propose a 301 redirect.
- Do not migrate dashboards before auth survives hard refresh on the deployed preview.
- Do not assume a Vite app or recommend a port solely because a page is not indexed.

Slice prompt 1: Next.js shell and Supabase auth

Migrate only the application shell and authentication foundation.

Implement:
- Next.js App Router layout.
- Supabase SSR server and browser clients using @supabase/ssr.
- Auth callback route.
- Next.js 16 Proxy for session refresh, using the current Supabase SSR guide.
- Verify identity with getClaims() before protecting pages or reading user data; never authorize from getSession()'s unverified user object.
- One stub protected page that confirms the user session survives hard refresh.

Do not implement:
- Dashboards.
- Billing.
- Admin features.
- Unrelated UI cleanup.

Acceptance checks:
- bun run lint
- bun run test
- bun run build
- Deployed preview supports sign-in, callback, hard refresh, and sign-out.
- Missing or expired session redirects without a loop.
- A forged, expired, or missing session cannot return protected data, including through a cached response.

Rollback:
- Keep the Lovable production app live.
- Document the exact route or DNS change needed to send users back.

Slice prompt 2: billing and webhooks

Migrate only billing and webhook handling.

Implement:
- Next.js route handler for Stripe webhooks.
- Signature verification using the server-only webhook secret.
- Idempotency storage or duplicate-event protection.
- Structured logs for received, ignored, failed, and retried events.
- A local replay fixture for at least one successful event and one duplicate event.

Do not implement:
- New pricing UI.
- New checkout flow unless it is required for the webhook test.

Acceptance checks:
- Webhook route rejects unsigned requests.
- Duplicate event does not double-write.
- Tests cover success, bad signature, and duplicate event.
- Secret names are documented, values are not.

Slice prompt 3: one indexable marketing route

Migrate one public marketing route that already matters for search.

Route:
- Source Lovable route: [old route]
- Target Next.js route: [new route]
- Canonical URL: [final URL]

Implement:
- App Router page.
- Server-rendered body content.
- Metadata API title and description.
- Self-referencing canonical.
- Open Graph tags.
- JSON-LD if the page has visible FAQ, Article, Product, or Service content.
- 301 redirect if the URL changes.

Acceptance checks:
- Googlebot user-agent fetch returns 200.
- Initial HTML contains the H1 and main body text.
- Exactly one canonical points to the final URL.
- Sitemap includes the final URL.
- Old URL redirects in one hop if changed.

Slice prompt 4: one dashboard route

Migrate one authenticated dashboard route.

Route:
- Source Lovable route: [old route]
- Target Next.js route: [new route]

Implement:
- Server component for initial data fetch where appropriate.
- Client component only for interactivity.
- Supabase RLS-safe query using the signed-in user's session.
- Empty, loading, and error states.

Acceptance checks:
- Signed-out user cannot access the route.
- Signed-in user sees only their own records.
- Expired session does not show another user's data.
- Hard refresh preserves the route state or redirects safely.
- Tests cover the data boundary.

Do not ask AI to do this in one pass

A one-pass conversion prompt is tempting because it feels cheaper. It usually creates the expensive failure: a working-looking app with broken auth cookies, unsafe env vars, missing redirects, and metadata that does not match production. A slice prompt is slower in chat, but faster in real delivery because every slice ends in a verifiable checkpoint.

Acceptance criteria for every slice

• The slice has one route or one integration boundary.
• The code compiles and the agreed test command passes.
• The preview deployment exercises the real callback or route shape.
• The prompt names files the agent must not touch.
• The output includes a rollback note.
• SEO-sensitive pages are checked with a Googlebot user agent.

FAQ

What should a Lovable.dev to Next.js conversion prompt include?

It should include route inventory, data entities, auth flows, integrations, deployment target, SEO-critical URLs, acceptance commands, and rollback rules. It should also say what not to change. The strongest prompt is specific enough that the model does not invent your product architecture.

Can I automate the migration with a single mega-prompt?

You can use a single prompt for planning, but not for production migration. Use separate prompts for auth, billing, public SEO routes, and dashboards. Each prompt should end with a build, test, deployed preview, and rollback check.

How do I keep SEO parity during the move?

Preserve ranking URLs where possible. If a URL changes, use a single-hop 301. Match title, description, canonical, Open Graph tags, sitemap entry, and JSON-LD before cutover. Fetch the deployed page with a Googlebot user agent and confirm the body content is in the HTML.

What should I never paste into a conversion prompt?

Never paste secret values, service-role keys, webhook secrets, private tokens, or full magic-link URLs. Use secret names and describe behavior instead. The agent needs to know that STRIPE_WEBHOOK_SECRET exists, not what its value is.

Where to go next

Use the conversion playbook to decide whether the migration is worth doing and what order to run. Read the auth and cutover engineering guide when Supabase RLS, server components, or backend handoff is the real risk. For team coordination, see AppHandoff and Lovable agency services.