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, permanently, with zero ongoing dependency on Framer.
- 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
If your export path keeps Framer's runtime intact rather than freezing to static HTML, CMS-driven pages will generally keep working exactly as before — because the runtime is still calling out to Framer's CMS API the same way it did on Framer's own hosting. The tradeoff there is the opposite of the static case: you get live content, but you're still dependent on Framer's servers being up and your Framer plan staying active, 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 either path) or "I want zero ongoing Framer dependency" (only the static-freeze path actually delivers that, with the re-export or migrate tradeoffs above).