A Framer-to-Next.js migration is ready to launch only when the exported site behaves correctly at real desktop and phone widths. A successful build and a matching screenshot are useful, but neither proves that a menu opens, a form submits, or an animation completes. This guide gives you a repeatable acceptance test for those details.
If you are still choosing an output, start with the Framer to Next.js converter. FNJ's Next.js mode keeps the published page's Framer runtime and markup so its authored interactions have the closest match. The Framer to HTML converter removes that runtime for a lighter static site and reconstructs common appear and scroll effects. Those are different trade-offs; test the output you intend to ship.
Make a baseline before converting
Open the published Framer URL, not the editor preview. List the routes you expect to keep, including case studies, legal pages, and any landing pages that are not in the main navigation. For each route, record the things a visitor can do:
| Area | A useful acceptance test |
|---|---|
| Navigation | Open and close the phone menu, follow a link, then use Back. |
| Animation | Check an above-the-fold entrance and a below-the-fold scroll reveal. |
| Sticky UI | Scroll past the trigger point and check headers, banners, and floating CTAs. |
| Media | Play a video, pause it, and check its poster and sound controls. |
| Forms | Submit a test message and confirm it reaches the intended destination. |
| Content | Open a CMS-generated route directly, then refresh it. |
| SEO | Compare title, description, canonical, and social preview on important routes. |
Use the same viewport for the original and export. A desktop width around 1440 CSS pixels and a phone width around 390 CSS pixels make a useful first pass. Also test the actual phone if the site depends on touch or hover-like interactions. Record what the original does before you judge the export; otherwise a pre-existing problem can look like a conversion regression.
Why matching HTML is only the first check
Framer publishes server-rendered HTML and then runs JavaScript in the browser. A static screenshot may show the correct closed menu even if the open state fails after a tap. A carousel may render its first slide while its controls do nothing. A sticky element may appear correctly at the top of the page but overlap content after scrolling.
The Next.js export retains Framer's runtime so these interactions can continue to work as authored. That does not replace the need for a browser test on the converted deployment. Third-party widgets, custom code, remote scripts, network calls, and hosting configuration can still affect behavior. Our separate guide explains what happens to Framer animations in each export mode.
Test the generated project, not just the ZIP
- Convert your published URL and review FNJ's preview for missing pages or broken assets.
- Download the Next.js project and follow its included README to install dependencies and run a production build.
- Open the built site in a browser. Visit every important path directly, rather than reaching it only from the homepage.
- Compare the original and converted site side by side at your chosen widths.
- Repeat the interaction checks on a deployment preview before pointing the production domain at it.
The production build matters because it exercises the routing and assets you will actually deploy. A dev server can hide a missing route or configuration error. If the exported route uses a Framer-hosted resource, watch the browser's Network tab rather than assuming every file is local.
Phone menus and floating CTAs
At phone width, tap the menu trigger and verify that the panel opens, contains the right links, closes with the close control, and does not trap scrolling after closing. Then navigate to another page and repeat. If your design uses an island-shaped floating CTA, test where it sits at the top, middle, and bottom of a long page. Check that it remains tappable without covering a form or cookie control.
These tests catch two different classes of issue: whether JavaScript creates an interaction state, and whether the responsive CSS positions it correctly. The mobile menu troubleshooting guide explains why a static HTML capture may not contain the menu's open state at all.
Motion and video
Scroll down slowly and quickly. Check that reveal animations finish in their intended state and that content remains visible if an animation does not run. Test a page reload halfway down the document; some effects only fail when the browser restores scroll position. For video, check playback, poster image, captions if present, and whether an external embed still loads on your new domain.
If exact motion is central to the design, compare the Next.js output first. If load speed is the priority, also generate HTML and compare its rebuilt effects against the original. The right choice depends on your particular site, not a universal Lighthouse number.
Forms, CMS, and third-party services
A form that looks right is not necessarily connected to a working backend. Submit a synthetic test entry and verify delivery. Do the same for newsletter signups, search, booking widgets, checkout links, and anything that calls an external service. A CMS-rendered page should load from a direct URL and still show the right content after a refresh. Keep a note of any content that needs a new source or a manual publishing workflow after leaving Framer.
Check the search-facing details before DNS
For your homepage and several nested routes, view the actual response and compare the page title, meta description, canonical URL, Open Graph image, and internal links. A canonical that still names the old host can undermine a clean migration. Check the generated sitemap and robots rules, then make a one-to-one redirect list for any URL that changes. Google's hosting-move guidance recommends testing the new host before the DNS switch and monitoring the old and new hosts afterward.
A practical launch decision
Use three labels for every item in your baseline: pass, needs adjustment, or not applicable. Do not switch the domain while a critical navigation, lead, or purchase path is still in “needs adjustment.” Save screenshots and a short screen recording of failures; they make support much faster than “the page looks broken.”
For the larger deployment sequence, use the Next.js launch checklist. When you are ready to generate the project, convert your Framer site to Next.js and validate the exact output on your own URL.