To move a published Framer website to Next.js, convert its public URL, inspect the generated App Router project, test its interactions, then deploy it on your own host. FNJ's Framer to Next.js converter handles the first step. The rest of the migration is a launch process, not just a ZIP download.
This guide explains what the current export contains, where Framer's runtime remains, and what to check before moving your domain. If you need plain static files rather than a Next.js app, use the Framer to HTML converter.
What you are converting
Framer does not provide a built-in Next.js source export. The published website is the input: public pages, their rendered HTML, assets, metadata, and interaction scripts. You do not need to hand over a Framer project password or API key for a public-site conversion. You do need an FNJ account to save and run conversions.
The generated output is a deployable Next.js App Router project, with route files for the discovered pages and the supporting package and configuration files. It keeps Framer's runtime to preserve authored motion and interactions. That also means its performance characteristics and some external runtime dependencies can resemble the original site. Conversion does not magically turn a complex animated site into a tiny JavaScript-free page.
Convert Framer to Next.js in four stages
1. Publish and inventory your pages
Publish your latest Framer changes and open the public URL in a private browser window. Note the homepage, nested pages, CMS-generated routes, and any path not linked from the main navigation. A crawler can only discover routes exposed through public links; if a page is unlinked or private, verify how you will handle it before you migrate.
2. Generate and review the project
Enter the public URL in the Next.js converter, choose the Next.js output, and let it discover the linked pages. Review the preview and page list. Download the project and read its included README. A successful generation tells you the files were produced; it does not prove every third-party integration works on a new domain.
3. Build and test locally
Use the build instructions supplied with the export. Run a production build, then open the site in a browser and test direct URLs as well as navigation clicks. Compare phone and desktop layouts with the published Framer site. Tap menus, scroll through animation-heavy sections, play media, and submit a synthetic form. Our Framer-to-Next.js interaction QA checklist gives a route-by-route test plan.
4. Deploy, then switch the domain
Deploy to a preview URL on a host that supports your generated Next.js project. Test the preview before changing DNS. Check titles, descriptions, canonical URLs, internal links, and important old paths. If your URL structure changes, make one-to-one redirects rather than sending every old page to the homepage. Google's hosting-move guide recommends preparing and testing the new host first, then monitoring traffic after the DNS switch.
What happens to animations and mobile components?
The Next.js output keeps the Framer runtime instead of trying to recreate each hover state, menu transition, or animated illustration from scratch. This gives it the best chance of matching the published design. Still, test the site you actually generated. Custom code, third-party embeds, network calls, and responsive edge cases can fail for reasons that a matching screenshot will not show.
For a speed-focused static export, HTML mode removes that runtime and rebuilds common appear and scroll animations using lightweight CSS and a small observer script. Complex runtime-only behavior can differ. See what happens to Framer animations after export for a deeper explanation.
What changes after you leave Framer?
Ownership of the deployed files is only part of the move. Make a separate plan for services that were previously tied to the original platform:
- Forms: verify where a test submission goes on the new domain. Reconnect the form if it used a service you are leaving.
- CMS content: the conversion reflects published pages at conversion time. Plan how new entries will be published later.
- Analytics and embeds: check consent, domain allowlists, and whether the scripts still load.
- Search: inspect canonicals, sitemap, redirects, and Search Console after launch.
- Editing: maintain the generated files with Git or use FNJ's supported editing workflow; do not assume a future change in the Framer editor automatically updates an exported deployment.
This is why the Next.js launch checklist covers more than the build command.
Next.js or HTML?
Choose Next.js when preserving authored interaction behavior and working in a Next.js project matter most. Choose HTML when you want a simpler static deployment and can accept that some runtime-driven effects may be rebuilt or simplified. Both should be tested on your own site. An aggregate Lighthouse claim cannot tell you whether your particular menu, video, or form will work.
If you are comparing output types, read the HTML versus Next.js decision guide. Then convert your published Framer URL and make the preview and interaction checks part of your release process.