Framer to Code: How to Move a Framer Site to a Real Next.js Codebase

Teams reach us at three moments:

1. Marketing wants custom logic Framer's Code Components can't reach.

2. The site needs typed content, workflows, or integrations that Framer's CMS was never built for.

3. Performance, SEO, or engineering ownership becomes non-negotiable and Framer's hosting stops cutting it.

At that point, "Framer to code" is not a plugin. It is a migration. Here is how it actually works.

What Framer gives you

Framer's export options are limited on purpose. Framer is a hosted platform. It gives you:

• Visual output on framer.com hosting

• A CMS with basic collections

• Code Components (React components you can drop into a Framer page)

• A publish button

What you cannot get:

• A downloadable Next.js codebase of your site

• Full control of routing, middleware, or the head tag

• TypeScript-typed content models with editor previews

• Server-side logic, protected routes, gated content, or custom auth flows

• Deploy previews from a Git branch

For a marketing site, none of that matters. For anything more, all of it matters.

What "Framer to code" actually means

You are not exporting Framer. You are rebuilding the site in a real stack. Almost always:

• Next.js (App Router, TypeScript) for the front end

• Sanity or Contentful as the headless CMS so editors keep an editor UI (see Contentful vs Sanity for how to choose)

• Vercel for hosting, previews, and edge middleware

• The same Figma / Framer design source carried across pixel-for-pixel

The design does not need to change. The system underneath does.

The migration in five steps

1. Audit the current Framer site. Every page, every CMS collection, every form, every embedded script, every animation. Screenshot the ones you cannot lose.

2. Model the content properly. Framer collections are flat. Sanity schemas are typed and referenced. Turning "blog post" into a schema with an author reference, a category taxonomy, a hero image with alt text, and structured SEO fields is where the leverage happens.

3. Rebuild the pages in Next.js. Reuse the design tokens (colours, spacing, type ramp) as Tailwind config or CSS variables. Rebuild sections as React components. Keep the visual output identical. (If you want the AI-accelerated version of this step, see Framer to Claude Code.)

4. Move animations to Motion (formerly Framer Motion). The library is open source, works in any React app, and is the same engine Framer uses under the hood. Every animation carries over.

5. Cut over with a redirect map. URLs match one-for-one. 301 redirects for anything that changed. Verify in Search Console before flipping DNS.

What you gain

• A codebase your engineers own and can extend

• Content that is typed, versioned, and previewable per branch

• Deploy previews for every marketing change

• Server-side rendering, ISR, and edge middleware when you need them

• No hosting ceiling

• Faster Core Web Vitals (Framer is fine; Next.js on Vercel is usually faster)

What you lose

• The Framer visual editor. Editors move to the Sanity Studio instead, which is closer to Notion than to a design tool.

• The ability for a non-technical designer to move an element and republish. Content edits are easy. Layout edits go through code.

That trade is usually the reason teams migrate. When product and marketing move quickly, layout-by-drag stops being a feature and starts being a bottleneck.

When you should not migrate

If your Framer site is a brochure with a contact form and a blog with fewer than 20 posts, and no one on your team writes code, stay on Framer. It is genuinely good at that job.

Migrate when:

• You need logic Framer's Code Components can't hold

• You have content models with references, taxonomies, or per-locale variants

• You need protected routes, gated content, or user accounts

• Your marketing team needs faster iteration than "log into Framer and drag"

• SEO or performance is a growth lever you cannot afford to leave to a hosted platform