Guide

Migrating a Lovable Classic project to TanStack Start - what I learned and what's next

I attempted to migrate carolmonroe.com from Lovable Classic to TanStack Start. The local conversion worked, the deployment didn't. Here's the timeline, what I learned, and why starting fresh on Modern might be the better path.

May 12, 202612 min133 views

Why I wanted to migrate

When Lovable made TanStack Start the default for new projects, I wanted my existing site on the same foundation. carolmonroe.com has 48 routes, a Supabase backend, Framer Motion animations, and a time-aware hero that changes by hour. I wanted real SSR for same-day indexing, dynamic OG tags per blog post, and server-side data fetching.

The good news: Lovable now ships automatic pre-rendering for existing projects, which covers the basic SEO needs. But I was curious about the full migration path - and I wanted to document it for the community.

The timeline

May 11Started the migration using Claude Code. Converted 48 routes from React Router to TanStack Start file-based routing. Replaced 46 files, made 4 context hooks SSR-safe, set up createServerFn for server-side data fetching. The code compiled and ran locally.
May 12Pushed to GitHub. Created a new Lovable Modern project. Imported the converted code. The Lovable agent started fixing platform-specific SSR issues - hydration, SEO per route, authenticated layouts. Published the initial findings as a guide and an open source skill.
May 13Hit deployment blockers. h3 module import errors. SSR worker bundle failures. Tailwind v3 to v4 incompatibilities (Lovable Modern uses Tailwind v4). Multiple rounds of fixes between Claude Code, the Lovable agent, and manual commits.
May 14After 20+ edits, the deployment still isn't working. Stepped back to evaluate the approach. Updated the blog and repo to reflect reality.

What worked

The local conversion part is solid. Claude Code handles the structural work well:

  • Route conversion from React Router to TanStack Start file-based routing
  • Import replacement across all files
  • SSR-safe context hooks (auth, theme, language, time)
  • Server functions with createServerFn for data fetching
  • The project compiles and builds successfully

The knowledge I gained about SSR patterns, anti-patterns, and what breaks during migration is all real and documented in the open source repo.

Where it gets stuck

The gap is between "it builds locally" and "it deploys on Lovable's modern stack." Lovable Modern runs on Cloudflare Workers, and the SSR runtime has constraints that a converted Classic codebase doesn't meet cleanly:

  • h3 module resolution at runtime
  • Worker bundle packaging
  • Tailwind v3 to v4 differences in the SSR pipeline

New projects created directly on Lovable Modern don't have these issues because they start with the right configuration from the beginning.

What's next

The most realistic path forward is probably creating a new project from scratch on Lovable Modern and migrating the content and data over. Start clean with the right stack, the right Tailwind version, the right bundler config - and bring the design, components, and Supabase data into that clean foundation.

I'm still learning about the best way to do this - how much of the design carries over, what the right order of operations is, and how to minimize the rebuild. It's a different approach than converting a codebase, but it might be the smarter one.

The exciting part is that the platform is in a great place right now. With Discoverability (SSR, pre-rendering, Semrush, SEO review), both new and existing projects have real paths to being found on Google and AI search. My existing SPA already benefits from automatic pre-rendering while I figure out the best way to rebuild on Modern.

If you've done something similar

I'd love to hear from people who have:

  • Rebuilt an existing project on Lovable Modern instead of converting it
  • Found a workflow for carrying design and components into a new TanStack Start project
  • Successfully migrated a Classic project to Modern (any approach)

The patterns and anti-patterns from this attempt are in the open source repo. Even though the deployment path didn't work, the knowledge about what breaks and why is useful for anyone thinking about this.

Reach out on LinkedIn or open an issue on GitHub.

Enjoyed this?

Carol Ships: building, shipping, figuring it out.

Have another workaround to share?

Start the thread below!

Comments

No comments yet. Be the first to share your thoughts!