Back to Build and deploy

Move off Lovable or Framer to your own code.

A Lovable project is already React code you can sync to GitHub, so moving it is mostly about hosting, assets and dependencies. A Framer site doesn't export production code, so moving it means rebuilding the pages while keeping every URL, title and redirect intact.

Build and deploy · 8 min read · Updated 2026-10-10

Protect search rankings first

Whichever platform you're leaving, the rankings belong to URLs. Crawl the live site before changing anything and keep the list as your checklist.

  • Every live URL, its title, meta description and canonical.
  • Existing redirects and any URLs that receive backlinks.
  • Structured data, Open Graph images and the sitemap.
  • Analytics and Search Console access, so you can compare before and after.

Moving from Lovable

Lovable already writes standard React code, so the move is mostly about getting that code into a setup you control.

  1. Connect the Lovable project to GitHub and clone the repository locally.
  2. Install dependencies and run the dev server and a production build to confirm it works outside Lovable.
  3. Find assets served from Lovable-only paths. When we moved this site, one project screenshot loaded from a Lovable asset path that returns 404 on any other host; we downloaded the original and committed it to the repository.
  4. List the Lovable services the code depends on, such as transactional email, and plan replacements or keep the Lovable project running.
  5. Deploy to your new host, check every URL from your crawl, then move the domain.
Lovable keeps syncing with the GitHub repository while the project is connected, so edits from either side end up in the same code. Decide who owns changes after the move.

Moving from Framer

Framer publishes sites but doesn't hand you production code to host elsewhere, so the move is a rebuild. Treat the live site as the specification.

  1. Export or copy CMS content out of Framer into structured files your new site can read.
  2. Rebuild templates and pages in code, matching the URL structure exactly.
  3. Carry over titles, descriptions, canonicals and structured data page by page.
  4. Download images at full quality and serve them from your own build or storage.
  5. Add 301 redirects for any URL that has to change.

Switch over safely

Changing where a domain points is the riskiest step. Do it in this order to avoid downtime and lost rankings.

  1. Test the new site on its preview URL against your crawl list.
  2. Lower the DNS TTL a day before the switch.
  3. Move the domain, then re-crawl the live site and check status codes.
  4. Submit the sitemap in Search Console and watch indexing and errors for a few weeks.
  5. Disconnect the old platform's custom domain so two hosts aren't serving the site.

Questions

Not if every URL, title and canonical stays the same, or redirects with a 301 when it must change. Most migration losses come from changed URLs without redirects.

Framer doesn't provide production code to host elsewhere, so plan for a rebuild that matches the existing pages and URLs.

The front end does. Anything that relies on Lovable-hosted services, such as their email sending or asset paths, needs checking and may need replacing.

Want it built for you?

We design, build and ship custom-coded sites with search built in from day one.

See the service

Related guides

Deploy a vite React site to Vercel from GitHub

Push the project to GitHub, import the repository into Vercel, confirm the build settings and add your domain. Every push to main then deploys to production and every other branch gets its own preview URL.

Fix 404s on deep links for a React app on Vercel

A single-page React app handles routes in the browser, so the server has no file for a path like /contact and returns a 404 when someone opens it directly. Add a rewrite that serves index.html for every unknown path.

Build a website with Claude code: Brief to launch

Claude Code works best as a fast pair of hands guided by a clear brief, small reviewable steps and real checks: type checking, tests, screenshots and a human reading every claim. Version everything in Git and let Vercel preview each change.