How to write a Framer migration case study

A good Framer migration case study tells one client's story with numbers you measured: why they left Framer, what was moved and how, what changed afterwards, and what it took. Measure before you migrate (URLs, Core Web Vitals, traffic, build of the old site) so the "after" means something, get the client's written approval to publish, and report what went wrong as well as what went right. Use the template below and fill it only with facts you can show.

This guide is for agencies, freelancers and creators who move Framer sites to code and want to publish the work, as a portfolio piece, a sales asset or content that ranks. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer.

Why write one?

Buyers searching for "Framer to Next.js" or "leave Framer" are trying to judge risk: will my site look the same, will I lose rankings, how long will it take? A case study answers those questions with a real example, which is more convincing than a service page. It also gives you a page that can rank for specific searches (a site type plus a framework, for example) and a link to send in proposals.

Before you start: get permission

Ask the client before the project starts, not after. Agree in writing on:

• whether you may name them, or must anonymize;
• which numbers you may publish (traffic and revenue figures are often sensitive);
• whether you may show screenshots of their site and code;
• who approves the final text.

If they say no, you can still write an anonymized version ("a B2B SaaS marketing site with 40 pages") with their approval.

What to measure, and when

Measure the same things before and after, under the same conditions. Before the migration:

How to audit a website before migrating has a fuller inventory, and comparing PageSpeed before and after explains how to compare lab scores fairly.

After launch, measure again: the same PageSpeed pages, Search Console after enough time has passed (at least a few weeks, ideally the same period length as before), and form delivery.

The template

Copy this structure. Each section has a purpose; skip none, but keep them short.

1. Summary (3–4 sentences)

Who the client is, what they moved from and to, and the main result, in plain words. This is also your page's first paragraph, the part answer engines and skimmers read.

[Client] moved their [type of site, N pages] from Framer to [framework] in [time]. We converted the published site, reviewed every page at three widths, and launched with all URLs unchanged. [One measured result, with the measurement named.]

2. Why they left Framer

The real reason, in the client's words if possible: a backend feature, hosting control, a developer joining, cost structure, ownership. Be fair to Framer; most clients leave because their needs changed, not because Framer is bad.

3. The starting point

The site as it was: pages, CMS collections, locales, forms, animations, code components, integrations. Numbers from your "before" measurements.

4. The approach

What you chose and why: framework (Next.js, Astro, Vite or another), where assets live, how CMS content is edited now, where it's hosted. If you used Deframer, say so plainly and accurately: the site was converted from the published site, with the client's verification, then reviewed and adjusted.

5. What took work

The honest part. Which pages needed fixes, which notices you resolved, what didn't convert as-is (a third-party embed, a code component's types), what you changed on purpose. Readers trust a case study more when it shows the problems. Migration problems and fixes can help you name them precisely.

6. Launch and SEO

How you cut over: redirects, metadata, sitemap, DNS. What you checked on launch day. The migration checklist is a good reference to cite.

7. Results

Before and after, side by side, each with how it was measured:

Leave out any row you can't measure honestly. A blank is better than a guess.

8. What the client can do now

The capability the move unlocked: a feature shipped, a developer onboarded, content in a headless CMS, an AI-assisted editing workflow.

9. Time and effort

Hours or days per phase, if you can share them. This is what prospective clients most want to know.

10. Client quote (only a real one)

A sentence the client wrote or approved. Never write one for them.

Claims to avoid

• Invented or rounded-up numbers. If you didn't measure it, don't publish it.
• Speed claims from one run. Lab scores vary between runs; report the median of several, with the date.
• "Pixel-perfect" or "identical". Converted sites are close to the original, not guaranteed identical; say what you checked.
• Implying Framer endorsement, or that a tool is official. Deframer isn't affiliated with Framer.
• Ranking promises. Report what happened to this site, not what will happen to the reader's.
• Client details they didn't approve.

Make it rank

• Title on the specific case: "Moving a 60-page SaaS site from Framer to Next.js", not "Our latest project".
• Answer first: the summary is the first paragraph.
• Question headings where natural: "Did they lose rankings?" "How long did it take?"
• Tables and steps: easy for readers and answer engines to quote.
• An FAQ at the end with the questions prospects ask you on calls.
• Link to the underlying guides so the case study is the start of a reading path.

Framer migration content for creators covers ranking and distribution more broadly.

If you're a creator rather than an agency

A case study of your own site works the same way and needs no client approval: migrate your own Framer site, measure before and after, and publish the result. If you link to Deframer with an affiliate link, disclose it near the link. The affiliate program pays 50% of lifetime deals and 40% of credit packs bought through your link within 30 days.