If your Framer site uses CMS Collections — a blog, a portfolio grid, case studies — exporting it raises a question that's easy to overlook until it bites you: what happens to that content after you leave?
The core tradeoff
Framer's CMS is a live, editable data source. Every CMS-driven page is generated dynamically from it at request time (or via ISR-style revalidation) while the site is hosted on Framer. A static HTML export necessarily freezes that content at the moment of export — every CMS item becomes its own static page, exactly as it looked when you converted. Add a new blog post in Framer after that, and it won't appear on the exported site, because the export isn't watching Framer's CMS anymore.
This isn't a bug in any particular tool — it's the nature of "static." The real question is what you do about ongoing content changes.
Three realistic paths forward
- You're done adding content. If the CMS collection was for a specific project (case studies for a completed portfolio, say) and won't be updated again, a one-time static export is exactly right — you get all the content, with no ongoing dependency on Framer's CMS. (A site converted with FNJ still loads Framer's runtime, though, so the Framer project stays published.)
- You'll keep publishing, so re-export periodically. Works fine for a low-frequency blog (a few posts a month) — just re-run the conversion whenever you publish. Annoying at higher frequency.
- Move the content to a CMS you actually own, and rebuild those pages against it. This is the only real fix if you want ongoing edits without repeated re-exports — options range from a headless CMS (Sanity, Contentful) to something as simple as MDX files in your own repo if the volume is manageable.
What a Next.js export changes
FNJ's Next.js export doesn't change this. Like the HTML and Astro outputs, it keeps Framer's runtime but captures the pages that exist when you convert, so a CMS item you add later has no page in the export until you convert again. Keeping the runtime does mean an ongoing tie to Framer: it loads from Framer's servers, so the Framer project has to stay published (Framer's free plan is enough, within its limits) — which somewhat defeats the point of "leaving Framer" for some people.
There's no universally right answer here — it depends entirely on whether the reason you're exporting is "I want to self-host" (compatible with any of the paths above) or "I want zero ongoing Framer dependency" (no FNJ output delivers that, since all three keep Framer's runtime).
Related conversion check
If your site relies on CMS-generated routes, inventory them before using the Framer to Next.js converter. The exported pages reflect the published content at conversion time; plan separately how new entries will be created after migration.
If the client will keep updating the site after the move, how clients edit a Framer site after export compares the options, from FNJ's visual editor to a headless CMS.
Starting a new site instead? FNJ's AI website builder designs one from a description and a site you like, then gives you the code to host anywhere.
