How to Migrate Off Webflow or Framer to Custom Code (2026)

The short answer: Move your marketing site off Webflow or Framer when the site has to do things a visual builder was not built for: custom tools, logged-in or product data, programmatic pages, or changes made by AI agents. The safe way is a rebuild, not an export. Inventory every URL, scrape the live site into a style guide and content files, rebuild it in Next.js or Astro with a coding agent like Claude Code, keep every URL or 301 it, then switch DNS and watch Search Console for two weeks. Most teams in 2026 report one to two weeks of work. Stay on Webflow or Framer if your marketing team edits the site weekly, nobody owns a codebase, and the site is a brochure.

We moved humblytics.com twice. First from Webflow to Framer, then from Framer to a custom Next.js site that we edit through Claude Code. This guide is everything we learned, plus what fifteen other companies published about doing the same thing on X, LinkedIn and their own blogs.

It is long on purpose. Skip to the part you need:

• Our migration: Webflow to Framer to custom code
• Who else has done this (15 public examples)
• Pros and cons
• When to migrate and when to stay
• Choosing your new stack
• How to approach it, step by step
• The full migration checklist
• Why custom code fits agents, tools and AI search
• Resources
• FAQ

Our migration: Webflow to Framer to custom code

Why we left Framer

On December 16, 2025 we decided to rebuild humblytics.com in custom code. Three reasons, in the order they mattered:

1. We wanted the product on the page. Humblytics is an analytics and A/B testing tool. Screenshots were not enough. We wanted working product components on the marketing site that visitors could click, and that is hard to build inside Framer.
2. We wanted agents to do the work. Coding models had become good enough to rebuild what a designer had made for us in Framer. Once the site was code, Cursor and Claude Code could write posts, make images and create pages for us. Framer had no way in for them at the time.
3. We wanted to stop paying for the canvas. We were paying roughly $100 to $200 a month for builder seats and plans. We chose to spend more time and tokens once to rebuild, instead of paying every month for the tool.

The new repository got its first commit on January 2, 2026. Launch target was January 19.

How we did it

Before writing any code, we built a migration kit with Firecrawl, an API that scrapes websites into clean markdown. Every document in the kit came from the live Framer site:

1. Style guide. Firecrawl read the existing site and produced a style guide from the colors, type, components and spacing it found, so the new site kept the same feel.
2. Sitemap. Every live URL, so every slug survived the move and we kept the search traffic attached to it.
3. Navigation map. Every link in the header and footer.
4. Homepage spec. Every section, what it was for and where it linked. The page was converting well, so the new one kept its structure even though it was not a 1:1 copy.
5. Brand asset sheet. Logos, images and icons.
6. Copy document. All homepage and card copy, scraped, so nothing was retyped.
7. Blog migration tracker. A big share of our traffic came from blog posts. We listed every post URL and scraped each one into a content file before the move.
8. Positioning document. We were changing direction at the same time, toward AI-run testing. Claude helped us write a positioning doc from the old copy and the new roadmap, and that markdown file became the brief the coding agent read.

Then we gave Claude Code the kit and the migration plan and rebuilt the site page by page: home, pricing, partners, blog.

What it looks like now

As of November 5, 2026, the site is:

• Next.js 16, React 19 and Tailwind 4, hosted on Render.
• 140 blog posts as markdown files in the repository. There is no separate CMS. The coding agent is our CMS.
• Designed in Paper, a design tool with an MCP server, so the agent reads and writes the same design boards we do.
• 1,177 commits since January 2.
• 166 redirect rules in next.config.ts, covering every URL we renamed, merged or retired.

Three months in, we posted on X that the move let us grow top-of-funnel traffic and leads 6x, because we could ship pages at a speed and scale the builder did not allow. The bigger change is how work happens. A new comparison page, a pricing change or a free tool is a prompt and a reviewed diff, not a ticket.

What we got wrong

The move was not clean, and the mistakes are more useful than the wins:

• We left images on Framer's CDN. Pages kept pointing at assets hosted by Framer. Three months later our server ran out of memory on Render and we had to strip the dead Framer CDN images out. Self-host every asset before launch.
• We deleted pages that ranked. In a cleanup we hard-deleted our Framer and Webflow audience pages. Both ranked for "framer A/B testing" style queries. We had to point redirects at the closest live pages in a June SEO recovery pass. Check Search Console before you delete anything.
• Redirects pile up. Every restructure since launch added rules. 166 is a lot. Keep one list, make every rule a single hop, and review it each quarter.
• Design drifts without a source of truth. Agents ship fast and invent spacing. We fixed this with a written design system file (DESIGN.md) the agent reads before every change, and Paper boards that the code must match.

Who else has done this

These are companies and founders who wrote publicly about leaving Webflow or Framer, mostly in 2026. Numbers are theirs, as posted.

The counterpoints worth reading

Not every story points one way. Read these before you commit:

• Teams also move onto Framer. Framer lists Loops and bunq as teams that moved from Webflow to Framer to publish faster with less developer help (Framer).
• A Framer rebuild can be faster. After ColdIQ's post, Gizem Onan rebuilt their homepage in Framer with Framer's agents and reported that the Framer version beat the live custom site in her performance tests (LinkedIn). Custom code is not automatically faster. It is faster if you build it to be.
• The saved hours can come back. Sofian Bettayeb cut a build from 50 hours to 15, then lost the 35 hours to four broken deploys, an indexing disaster and a browser path bug. His site was a React single-page app with no prerendering (LinkedIn).
• Markdown does not scale forever. Sanity's Knut Melvær replied to Cursor's move that markdown files work for small content sets and become a maintenance problem at scale (via OLDaily). Cursor needed no CMS. ColdIQ, with 4,000+ pages, kept one.
• Team size predicts the stack. Erfan checked 2,945 YC startup sites: Next.js is the top choice for teams of five or fewer (42%, Framer 6%), while Webflow leads once a company passes 16 people (31%), around when marketers get hired (X).

Pros and cons of leaving Webflow or Framer

The honest summary: custom code removes the ceiling and adds a list of chores. Agents now do most of those chores. They do not decide which chores exist, which is why the checklist below matters.

When to migrate and when to stay

Migrate when three or more of these are true

• The site needs things a builder fights: product demos, calculators, free tools, gated content, live data from your app or billing system.
• You want programmatic pages (integrations, comparisons, templates, locations) by the hundred.
• You want AI agents to create and change pages, not just suggest copy.
• Engineers avoid the site because they will not work in a visual builder.
• You pay for add-ons (localization, A/B testing, extra CMS items or seats) that code would replace.
• Your marketing and product share a design system, or should.
• Someone on the team will own the repository and review changes.

Stay when any of these are true

• Nobody will own a codebase or review a pull request.
• Marketers edit the site every week and will not use an agent or a CMS.
• The site is a brochure that changes twice a year.
• You use native Webflow ecommerce or memberships heavily.
• You are mid-launch or mid-rebrand. Do not change platform and positioning in the same week unless, like us, you have a reason to.

The middle path

If you are not ready, put agents on the builder first. Webflow's official MCP server works on all site plans, and Framer 3.0 lets Claude Code and Cursor work on a project through the Framer CLI (we covered it in Framer 3.0 explained). One team rebuilt a landing page with Claude Code and the Webflow MCP and never left Webflow (LinkedIn). It is a good way to learn whether your team actually works through agents before you move the whole site.

Choosing your new stack

Pick one option per row. Coding agents know all of these well.

Two rules from the examples above. First, render on the server. AI answer engines like ChatGPT read the raw HTML and do not run JavaScript, so a client-only single-page app can look almost empty to them (Erfan's check). Second, write a rules file (CLAUDE.md or AGENTS.md) on day one. Vellum credits per-folder AGENT.md files for keeping agent-built pages on brand.

How to approach the migration, step by step

The pattern across every successful example is the same: port first, redesign second. QA Wolf made it their one rule. We broke it on purpose by changing positioning at the same time, and we paid for it in extra review.

Phase 1: Inventory (day 1)

Build the list of everything that has to survive.

1. Every URL. Combine your live /sitemap.xml, the Pages report in Google Search Console, and your top landing pages from analytics. Search Console catches URLs the sitemap forgot.
2. Every existing redirect. Webflow keeps them under Site settings, Publishing, 301 redirects. Framer keeps them in site settings. They stop working the day you leave the platform.
3. Every form. Fields and where each submission goes.
4. Every script. Analytics, pixels, chat, consent banner, A/B testing, affiliate tracking.
5. SEO baseline. Titles, meta descriptions, canonicals, Open Graph images and schema for each page. Export clicks and impressions per page for the last 90 days.
6. Performance baseline. Run PageSpeed Insights on your top ten pages and save the numbers.

Phase 2: Extract (day 1 to 2)

Get the content and design out in a form an agent can use.

• Webflow. Code export gives HTML, CSS, JavaScript and assets on paid Workspace plans only, and excludes CMS content, ecommerce, extra locales and working forms (Webflow help). Export each CMS collection to CSV, or pull it through the Webflow Data API for richer fields. Treat the HTML as a blueprint, not a codebase: it holds your exact spacing, colors and type scale.
• Framer. There is no code export. Scrape the published site. We used Firecrawl to turn every page into markdown and to write the style guide.
• Both. Download every image and file. Do not leave anything pointing at the old CDN.

Prompt we used to start, adapted:

Use Firecrawl to map every URL on [site]. Then:
1. Write STYLE_GUIDE.md from the colors, fonts, spacing and components you find.
2. Write SITEMAP.md with every URL and its page title.
3. Write NAV.md with every header and footer link.
4. For the homepage, write HOMEPAGE_SPEC.md: each section, its purpose, its links.
5. Scrape every blog post into /content/blog/[slug].md with title, description,
   date and body. Download every image into /public and rewrite the links.
Do not invent anything. If a field is missing, leave it empty and list it.

Phase 3: Build the shell (day 2 to 3)

1. Start a fresh Next.js or Astro project. Write CLAUDE.md: stack, folder rules, design tokens, what never to do.
2. Build the shared parts once: layout, nav, footer, global styles.
3. Match the homepage to the pixel. Give the agent a screenshot of the live page at 390, 1280 and 1440px and have it compare its own screenshots until they match. Cursor and Monologue both used this browser-in-the-loop approach.

Phase 4: Port every page (day 3 to 7)

Port the smallest template first to prove the pattern (QA Wolf started with the changelog), then templates, then one-off pages. Keep every URL. Import content from your extracted files, not by retyping.

Phase 5: Rebuild what the platform did for you

This is the part people forget. Vellum's list matches ours:

• robots.txt and a sitemap generated at build time
• Metadata, canonical tags and Open Graph tags on every template
• Structured data, checked in Google's Rich Results Test
• Forms posting to your CRM
• Image optimization
• 301 redirects

Phase 6: Verify, then launch

Run the new site on a preview URL and check it against the Phase 1 inventory. Every old URL must return the page or a single 301, never a 404. Then switch DNS and keep the old plan active for a few weeks in case you need to roll back.

Phase 7: Watch for two weeks

Check Search Console every day for the first week. A small dip while Google recrawls is normal. A cliff on one page means a redirect broke.

The full migration checklist

Copy this into your repository as MIGRATION.md and have the agent tick items off as it works.

Before you start

• Decision written down: why you are moving and what success looks like
• One owner for the repo and every pull request
• Analytics baseline saved: traffic, conversions and sign-ups per page for 90 days
• Search Console: clicks and impressions per page exported
• PageSpeed scores saved for the top ten pages
• Old platform plan kept active until at least two weeks after launch

Inventory

• Every URL from the sitemap, Search Console and analytics, in one list
• Every existing redirect copied out of the old platform
• Every form, its fields and its destination
• Every third-party script (analytics, pixels, chat, consent, testing, affiliates)
• Every CMS collection and its fields
• Every page's title, description, canonical, OG image and schema
• Inbound links to top pages (so you never change those URLs)

Extraction

• CMS collections exported (CSV or Data API)
• All pages scraped to markdown
• Style guide written from the live site
• Every image, video, font and PDF downloaded and self-hosted
• Rich text converted to markdown, platform-specific markup stripped

Build

• CLAUDE.md or AGENTS.md with stack, rules and design tokens
• Layout, nav and footer built once and shared
• Pages server-rendered or statically generated (check with JavaScript off)
• Every template matched against screenshots at mobile, tablet and desktop
• Interactions and animations rebuilt, with reduced-motion support
• Forms wired to the CRM or email tool and tested end to end
• Consent banner behaves the same as before, where you need one
• Analytics and testing script installed in the global head
• 404 page that links to the homepage and top pages

SEO and AI search

• Every old URL returns 200 at the same path or a single-hop 301 (Next.js permanent: true sends a 308, which Google treats the same)
• Titles and descriptions match the old site unless you changed them on purpose
• Canonical tag on every page, pointing at itself
• sitemap.xml generated from your content and listed in robots.txt
• Structured data validated
• Internal links point at final URLs, not at redirects
• No link or image still points at the old platform's domain or CDN
• An llms.txt file and a plain-text answer near the top of key pages, if you care about AI answers
• curl each key page and confirm the title and body text are in the raw HTML

Launch day

• Domain verified in Search Console before the DNS switch
• DNS pointed at the new host, checked in a private window
• Every URL in the inventory tested against the live site
• New sitemap submitted in Search Console
• Forms submitted once each in production
• Analytics receiving pageviews

After launch

• Search Console checked daily for a week, then weekly for a month
• Traffic and conversions per page compared with the baseline at 14 and 30 days
• PageSpeed rerun on the top ten pages
• Old platform plan cancelled only after the numbers hold
• Redirect list reviewed every quarter; chains collapsed to one hop

Why custom code fits custom tools and agents

This is the real reason to move in 2026. Cost and speed are side effects.

Your site becomes a product surface. On a builder, a calculator or a live product demo is an embed fighting the platform. In code it is a component. Our homepage audit card scans a visitor's URL, shows its score in under a second, then drafts A/B tests one by one. Our free tools and integration setup guides are pages in the same repo as the marketing site. None of that was practical in Framer.

Your site becomes something agents can operate. Everything is a file and every change is a diff. That means an agent can:

• write and publish a blog post from a brief, with images
• spin up a landing page for a new ad campaign
• generate a comparison or integration page from structured data
• fix a broken link at 2am and open a pull request for a human to approve

Lee Robinson merged a fix to cursor.com from a cloud agent on his phone the day after his migration (source). At Vellum, each marketer's assistant can open pull requests against the website repo.

Your site plugs into the rest of your stack. With the site in code, the same terminal that edits it can reach your CRM, your ad accounts, your analytics and your email tool through APIs, MCP servers and skills. We run our go-to-market from Claude Code: the agent reads traffic, drafts a test, edits the page and ships it, and a person approves each step.

The loop closes when the agent can measure. An agent that ships pages without data is guessing. Give it analytics and A/B testing it can call directly, and it can see which page lost visitors, draft a change, run it as a test, and report the result in revenue. That is what we built Humblytics for agents to do, and it works the same on Webflow, Framer or custom code. On a Next.js site the script goes in app/layout.tsx. You can connect your agent here.

Resources

Official documentation

• Webflow: export your site code (plans and exclusions)
• Webflow Data API reference
• Webflow MCP server overview
• Framer 3.0 release (agents, branching, external agents through the CLI)
• Framer: Webflow to Framer guide, if you decide to stay on a builder
• Google: site moves with URL changes
• Google: redirects and Google Search
• Next.js: redirects in next.config
• Astro: migrate an existing project

Tools

• Claude Code, Cursor or Codex to do the build
• Firecrawl to map and scrape the live site
• Playwright for screenshot comparisons the agent can run itself
• PageSpeed Insights and Rich Results Test for checks
• Sanity, Payload or Keystatic if you need a CMS
• Paper for design boards an agent can read and write

Migration write-ups worth reading in full

• Vellum: how I migrated off Webflow in one week with coding agents
• Lee Robinson: coding agents and complexity budgets
• QA Wolf: why we left Webflow and rebuilt our site with Claude
• ColdIQ: why we left Webflow
• ZenML: how I rebuilt zenml.io in a week with Claude Code
• Monologue: how I built the new website in less than seven days

Related Humblytics guides

• Best analytics for Framer sites
• Best analytics for Webflow sites
• Webflow A/B testing: the complete guide
• How to run A/B tests in Framer

FAQ

Can I export my Webflow site to Next.js?

Not directly. Webflow's code export gives static HTML, CSS and JavaScript on paid Workspace plans, without CMS content, ecommerce, extra locales or working forms. Use the export as a design reference, bring CMS content across as CSV or through the Data API, and rebuild the site in Next.js.

Can I export my Framer site?

Framer has no code export. Scrape the published site into markdown and a style guide, download every asset, and rebuild. A tool like Firecrawl does the scraping; a coding agent does the rebuild.

How long does a migration take?

The public examples in this guide range from three days (Cursor) to about a week (Vellum, QA Wolf, ZenML, Monologue) to 1.5 weeks (Yuma AI). Agencies quote three to eight weeks for larger sites. Plan for the last 20% (matching details, redirects, forms, SEO) to take most of the time.

Will I lose my SEO rankings?

Not if you keep every URL or 301 it in one hop, keep your titles and metadata, render pages on the server, and keep the domain. Google treats a same-domain move with unchanged URLs as a hosting change. Expect a small dip while it recrawls, and check Search Console daily for the first week.

Is it cheaper?

Usually on platform fees. Vellum reported $30k a year saved. You take on hosting, tokens and review time instead, and someone has to own the repository. If nobody will, the savings are not real.

Do I need a CMS after I leave?

Only if people who will not use an agent need to edit content, or you have thousands of entries. Cursor and QA Wolf use markdown in the repo. ColdIQ and Vellum use a headless CMS. We use markdown and let Claude Code be the editor.

Next.js or Astro?

Astro for a pure content site. Next.js if the site needs React, server logic, or shares code with your product.

---

Sources: our own repository history, migration notes and meeting records (December 2025 to November 2026), and every public post linked above, retrieved November 5, 2026. Numbers from other companies are as they reported them.