How to move a website off Webflow to Claude Code, GitHub and Vercel

I have been a heavy Webflow user for years, built a lot on it, and this spring I moved four of my own sites off it. All of them run on Next.js and Vercel now, built with Claude Code, with the code in GitHub. The largest one was about 200 pages and took five days at two to three hours a day. This is how it went, in the order you would do it.

It is not a case for leaving Webflow. The last section says who should stay, and I mean it. It is a record of what the move involves when it fits.

Should you move off Webflow at all?

If you are a solo builder or a small team and you work with AI tools every day, the case is strong: cheaper to run, faster to ship, the code is yours. If a team without engineers has to run the site, or you are a large company with roles, staging and approvals to think about, stay on Webflow. Those are different problems with different constraints.

My own reasons, for four sites: the Webflow plans stacked up across them, the friction of updating had kept me from touching one site for twelve months, and with an assistant in the loop I try things I would never have bothered prototyping before. That is a real list for one person with several small sites. It is not the list of a marketing team of eight.

What does the migration actually involve?

Four jobs: get the content out, build the new site, move every page across at the same URL, and switch the domain. Claude Code did most of the heavy lifting on the first three. The site I timed had close to 200 pages and about 1,300 visits a month from search, so redirects mattered more than design.

• Day one and two: new repo, Next.js scaffold, design tokens and the page components, deployed to Vercel from the first commit so every change had a preview link.
• Day three and four: content. Almost no manual work on the move itself. I had to tweak things here and there and redo a few parts the assistant decided to skip.
• Day five: redirects, the SEO layer, the domain switch, and a last pass over what the old site had that the new one did not.
• Most of the hours went on design and structure, because the assistant made it cheap to keep pushing until I was happy with it. Two years ago that was the part I gave up on.

How do you get the content out of Webflow?

CMS collections export from Webflow as CSV files, one per collection, with the rich text as HTML in a column. Static pages export as HTML carrying Webflow's own class names, which is rarely worth keeping, so they get rebuilt from the live site instead. That is where the assistant earns its keep: point it at the published page and the new component set, and it produces the page in code.

The step people skip is the inventory. Before anything is rebuilt, pull the old sitemap and make a list of every URL that exists. That list is the migration. Every item on it either lands at the same address on the new site or gets a redirect, and at the end you tick it off line by line. Without it you find out what went missing from Search Console, a month later.

How do you set up the new stack?

A repository on GitHub, a Next.js app in it, and a Vercel project connected to the repository. From then on every push gets its own preview link and the main branch is the live site. Claude Code does the building from a terminal opened in that folder.

The one file worth writing before the first prompt is the instructions file the assistant reads on every run. Mine says what the site is, where the old content lives, which URLs must survive, and what it is not allowed to invent. I wrote more about what belongs in that file separately. For a migration, this is the shape.

1# Migration rules
2
3- The old site is the source of truth for content. Never rewrite,
4  shorten or "improve" copy while moving it. Move it, then we edit.
5- urls.txt lists every URL on the old site. Every one of them must
6  resolve on the new site: same path, or a 301 in redirects.
7- If a page or a field cannot be migrated, say so in MIGRATION-LOG.md.
8  Do not silently skip it.
9- Images keep their alt text. Dates keep their original published date.
10- One component set (see /components). No one-off styles per page.

How do you keep vibe coding from going wrong?

Small commits, a preview link for every one, and a rule that the assistant reports what it skipped instead of moving on. The failure mode is not broken code. It is content that silently went missing, a field the assistant decided was optional, a page it summarised instead of moving. All of that is invisible until you go looking.

• Move the content first, exactly as it is. Improve it afterwards, in separate commits, so you can see what changed.
• Check the ones the assistant found hard. Long articles with embeds, pages with forms, anything with a table. Those are where it skipped parts on mine.
• Keep the design in one component set from the start. The assistant will happily build every page its own way if you let it, and the site stops feeling like one site.
• Read the diff before you merge, even when it looks boring. Especially when it looks boring.
• Keep the code understandable. If you cannot follow the structure, the next assistant session cannot either, and you have rebuilt Webflow lock-in with extra steps.

What about redirects and the domain?

Every old URL either lives at the same path on the new site or gets a 301 redirect to its new home, in a redirects file the assistant can generate from the URL list. Keep the same domain if you can. I did not: I moved from a domain with a dash in it to the version without, because the dash had bothered me since day one, and I own both.

Changing the domain and the platform on the same day means that if traffic drops you cannot tell which move caused it. I accepted that for a personal site with 1,300 visits a month. I would not do it on a client site. Do one, wait, then do the other.

The last step is the launch pass every site should get anyway: metadata, sitemap, robots, structured data, one H1 per page. The site launch playbook is the list I run.

What did you gain?

Speed of shipping, above everything. The parts of the old process that had stopped me updating the site for a year are gone, and I have published more since the move than in the twelve months before it. The other gains, in the order I noticed them:

• A far better design than I managed two years ago. I am no designer, but with an assistant it is cheap to keep iterating until it looks right.
• Better SEO and answer-engine markup: structured data, key takeaways, summaries and author sections as components, so every article gets them.
• Internal linking is much easier, and it re-runs whenever new content lands.
• Page speed went from middling to a 99 score, and accessibility improved with it. Not Webflow's fault. It was just easier to fix with the assistant controlling the code.
• Hosting costs dropped to close to zero. Four sites on one setup instead of four subscriptions.
• The sites became fully workable by the assistant. New pages, meta, content updates, all through Claude, because it is all files now.

What did you lose?

The ability to hand the site to someone who does not write code. There is no dashboard for anyone else, no visual editor, no roles. That is fine for my own projects and a real trade-off for client work, which is why I still recommend Webflow for teams that need to run a site without an engineer.

• Staging, roles, guardrails and approval flows are built into Webflow. In a code stack they are not free.
• Forms, CMS, hosting and search came in one bill. Now each is a choice, and some are duct tape.
• Security and compliance were handled. Now they are mine.
• It took a while to stop missing the visual editor. I do not miss it now, but I did.

So is Webflow dead?

No. Webflow leaned into enterprise a year or two ago, and at the time I disliked it. Today it looks like the smartest call they made. A large company with a real web team has every reason to stay, and Webflow is shipping AI features weekly, including its own MCP server, which is in the library with what it can change.

What changed is that solo builders and small teams have an alternative that did not exist two years ago. None of it fixes a site that does not explain what it does or help a visitor with their problem. That part is the same on either stack.

There is something oddly nice about knowing every line of your site came out of conversations. Strange times, good times.