Framer lock-in: what you can take with you and what you can't

Framer locks in two things: the code that renders your pages, because Framer has no code export, and the editing experience, because the canvas only exists inside Framer. Almost everything else is portable. Your domain is yours, CMS content can be exported with plugins, images and fonts you uploaded are your files, and your URLs and SEO travel if you plan redirects. The code can be recovered by converting the published site into a project, which leaves the editor as the one thing you truly can't take with you.

This post goes part by part, so you can see exactly what you'd keep if you left, and what to do now to keep your options open. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer.

What does lock-in actually mean?

Lock-in is the cost of leaving. It isn't about whether a tool is good; Framer is very good at what it does. It's about how much work it would take to move if you needed to: because prices change, a client asks for code, a feature needs a backend, or a company policy requires hosting you control.

Measured that way, a platform's lock-in is the sum of what you'd have to rebuild. So go through the parts.

Part by part

Your domain

A custom domain is registered with a registrar, not with Framer. Framer hosts the site at it because your DNS points there. Leaving means changing those DNS records; nothing about the domain itself is locked. Moving a domain off Framer without downtime walks through the cutover.

If you only ever used a *.framer.website address, that one stays with Framer. Move to your own domain early if you might ever leave.

CMS content

Framer's data-portability article says CMS content can be exported using plugins into structured formats such as CSV or JSON (Framer Help). Export every collection, including ones you've stopped using, and repeat after you publish new items. How to export Framer CMS content compares the routes.

A CSV gives you records. It doesn't give you the template pages that display them; that's the code part below.

Assets

Images and videos you uploaded are your files; keep the originals somewhere outside Framer. If you no longer have them, a converter can download every Framer-hosted asset into the project: in Deframer that's the "Assets in the project" option, which copies images, fonts and videos into public/. Fonts bought from a foundry are licensed to you, not to Framer; check the license before self-hosting them (font licensing when you self-host).

URLs and search rankings

Search engines rank URLs, not platforms. If the new site serves the same paths with the same content, rankings carry over; where a path changes, a permanent redirect carries it. The risk isn't lock-in so much as a careless move. Keeping SEO when moving off Framer covers it end to end.

The pages and components: the real lock-in

The design you built in Framer exists as Framer's project data and as the published site that Framer's runtime renders. There's no button to download it as code. This is the part that would cost the most to rebuild by hand: every breakpoint, text style, hover state, variant and scroll effect.

You can recover it as code by converting the published site. Deframer reads the files the published site serves (no editor access needed) and writes a TypeScript project for Next.js, Astro, TanStack Start, React Router or Vite. Components keep the designer's folders, variants and hover states, styles become CSS modules and design tokens, CMS collections become JSON, forms become API routes, and animations run on the open-source motion library. There's no Framer runtime in the result. What you get in a converted project shows the folders.

Converting is free; downloading the code is for your own site or one whose owner allows it, for 1 credit with site verification. The result is close to the original but not guaranteed identical, so it's reviewed page by page.

Code components and overrides

If you or a developer wrote code components or overrides, you likely have the source already. A converter carries them over too: Deframer puts the site's own code components and overrides in src/code/ and marketplace components in src/vendor/, as source. Code components and overrides in Next.js explains where they land.

The editor

This is the part nothing can take with you. Once a site is code, changes are code changes. Some teams add a headless CMS so non-developers can still edit content (adding a headless CMS), but there's no visual canvas for layout outside Framer. If your team depends on that canvas, that is the strongest reason to stay, and a good one.

How to reduce lock-in without leaving

You don't have to leave to stay free. A few habits keep the cost of leaving low:

1. Use your own domain from day one.
2. Export CMS collections on a schedule, and keep originals of assets.
3. Keep a code copy. Convert the published site and commit it to Git after significant changes. Back up a Framer site describes the routine.
4. Keep custom code in a repository rather than only in Framer's settings.
5. Note your redirects and page settings (titles, descriptions, social images) in a document.

When lock-in is worth it

Lock-in is a price, and sometimes the thing you're buying is worth it. A designer who ships changes daily without a developer is getting real value from the canvas. The question isn't "is Framer locked in?" but "would leaving cost more than staying, given what we need next?" Framer vs. Next.js for growing sites helps with that decision.