Framer to Code: Moving a Framer Site to Next.js

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

Using an AI Coding Agent to Speed Up the Rebuild

An AI coding agent such as Claude Code, Anthropic’s command-line coding tool, can take on much of the mechanical work in a Framer to Next.js rebuild. It is not a converter: it will not turn a Framer URL into a codebase on its own. A developer directs it, reviews what it writes and owns the result.

Where It Helps

• Design tokens: read the colours, type ramp and spacing from the Framer project and have the agent write the Tailwind config or CSS variables.

• Scaffolding: give it the Framer page list and ask for empty App Router routes that mirror the existing URL structure.

• Page rebuilds: hand it each page as a screenshot, Figma export or live URL, with the shared components already in context, then review and correct the output.

• Content modelling: describe the CMS collections and have it generate the Sanity schemas, GROQ queries and typed helpers.

• Animations and redirects: it can port Motion code from Framer Code Components and draft the redirect map for next.config.js.

Where It Does Not

• Design decisions: if the Framer design has bugs or is not final, the agent will rebuild them faithfully.

• Content migration: it can write the import script from Framer’s CMS into Sanity, but someone still has to run it and check every record.

• QA: generated code can look right and still reference a class or import path that does not exist. Every page needs a human review.

• Shipping: Git history, code review, deploys and the DNS cutover stay with your team.

This approach works best when the Framer design is final, the target stack is decided and someone on the team is comfortable reviewing generated code. If the site is mid-redesign, or nobody can review the output, sort those out first.