Last month, our team officially churned off of Webflow. The whole vellum.ai website now runs on Next.js, Sanity, and Postgres. Our marketing team ships updates in minutes. We saved $30k a year on the Webflow bill alone, and that wasn't even the biggest unlock.
The biggest unlock was speed. Spinning up a showcase page used to take days or weeks waiting on design and engineering. Now anyone on GTM can vibe-code one in half a day. Our content lead has 10x-ed his GEO article velocity. Our engineers can jump into the website without context-switching into a different tool.
This is the post I wish I'd had six months ago when I was staring at our Webflow setup wondering if a migration was even feasible. So here's the full story: what was broken, why we did it now, the stack we chose, what we got wrong, and the real bottleneck nobody talks about.
Why Webflow stopped working for us
When you're a five-person marketing team at a fast-moving startup, the website is supposed to be your fastest experimentation surface. Ours had quietly become our slowest.
A few specific things kept biting us:
- Shipping a new page took days or weeks. Every page needed design review, then a developer to wire it into the Webflow CMS, then QA. By the time we shipped, the campaign brief was stale.
- Programmatic SEO was painful. We couldn't spin up template-driven pages quickly. Anything beyond a handful of static pages required hacky CMS workarounds.
- We hit Webflow's ceiling on animations and interactions. We wanted shared logic between the website and the app, custom components, real state. The platform fights you on all of it.
- Engineers couldn't easily contribute. Our website lived in a different universe from our codebase. If a backend engineer wanted to fix a typo, they had to learn Webflow's UI first.
- The website was disconnected from the product. We couldn't easily personalize CTAs based on what a user was doing in the app. The marketing site and the product behaved like two different companies.
- Marketing and PLG experiments were tooling-blocked. Every "what if we tried this" turned into a Jira ticket.
Each of these felt manageable in isolation. Together, they meant our website was a bottleneck on every growth experiment we ran.
Why we did this now (and not six months ago)
The honest answer: vibe coding tools finally made the migration math work.
Six months ago, doing this with engineers would have been a one-quarter project. Today, with Claude Code, Devin, v0, and Lovable in the mix, especially when paired with a real codebase and proper infra, a marketer can do most of the work.
We prioritized this migration for two reasons:
- It was a speed unlock for Vellum. Every week we stayed on Webflow was a week our experimentation cycle was capped.
- It was a real case study we could share. AI is making technical migrations newly accessible to non-engineers. That's a story worth telling.
If you're a growth leader sitting on a Webflow stack right now, the timing is fine. The tools are good enough.
The stack we picked
We did real cost vs performance analysis before committing. Here's where we landed:
- [Claude Code](https://claude.com/product/claude-code) + [Vellum](https://vellum.ai) for the migration itself. Claude Code did the heavy lifting on code generation. Vellum gave each of us a personal assistant with our preferences and access baked in.
- [Sanity](https://sanity.io) as our headless CMS. We evaluated Contentful, Strapi, and Payload. Sanity won on developer experience, the Studio editing UX for non-engineers, and how well it played with a Next.js frontend.
- Next.js for the web app. Boring, battle-tested, and the AI tools know it cold.
- [PostgreSQL](https://www.postgresql.org) as our database for anything we wanted to persist server-side.
- Vellum to push code changes via GitHub. Each marketer has their own assistant that can open PRs against our website repo.
The principle: pick stacks the AI tools already know. If your stack is unusual, you give up the agentic velocity. We picked the most predictable, well-documented options at every layer.
The migration: one week, mostly handled over a weekend
This is the part that surprised me.
Our CTO, Noa, migrated almost all of our existing content into Sanity over a single weekend. His description: he was watching TV, clicking "approve all" on suggestions from a coding agent that was reading our Webflow export and mapping it to our Sanity schema. It was not glamorous. It worked.
For the rest of the team, the question wasn't "can we do this?" It was "what's my job during this migration?"
If you're the marketer leading a Webflow → headless migration, your job is to be the one who notices the invisible things. The engineers will assume those things just work. Webflow handled them automatically, so nobody on your team has had to think about them in years. Now they're suddenly your problem.
The invisible work that becomes yours
This was the section I needed most going in and couldn't find anywhere. Here's the checklist we ran through, with what we did for each.
- robots.txt. Webflow generates this for you. In Next.js, you write it yourself (or use a route handler). We wrote ours by hand to control crawler access page by page.
- Sitemap generation. Same story. We built a dynamic sitemap that pulls from Sanity at build time so every new page is automatically included.
- 301 redirects. This is the big one. Every URL you change is an SEO hit if you don't redirect it. We exported every URL from Webflow, mapped it to its new home, and configured redirects in Next.js. Skipping this will tank your rankings.
- Metadata and Open Graph tags. Webflow auto-generates these. We had to define our meta strategy as fields in Sanity and render them in Next.js layouts. We caught a few pages mid-migration where OG images were broken in social shares.
- CDN and image optimization. Next.js has its own image component, but you have to actually use it. We migrated to
next/imageeverywhere and configured remote patterns for Sanity's image CDN. - Canonical URLs. Easy to forget, painful when wrong. We set explicit canonicals on every page template.
- Schema markup. JSON-LD for articles, products, FAQ pages. We rebuilt this from scratch and validated it with Google's Rich Results Test before launching.
- Analytics and tracking events. Every event tag on the old site had to be reimplemented. We took the opportunity to clean up dead tags.
- Form handling. Webflow forms are free. Now you need a backend. We routed forms through a Next.js API route into our existing CRM.
- Staging and preview environments. Webflow has staging built in. We set up Vercel preview deployments tied to PRs.
- Preserving old URL paths. Where we could keep URLs identical, we did. Where we couldn't, see "301 redirects" above.
I used Claude Code to walk through each of these. It would read the relevant part of the codebase, tell me what was missing, and write the fix. The first week post-migration is the critical one. Monitor everything. Watch your rankings, your traffic by page, your conversion rates. Catch problems before Google notices them.
How we ship now
Once we were live, the second migration started: changing how our team works.
Two things made this work:
1. AGENT.md files in the repo. Every directory that a marketer might touch has an AGENT.md that tells coding agents about our conventions, our preferred patterns, what to avoid, where to look for similar examples. This is the difference between an agent that ships pages that look like ours and an agent that ships pages that look like everyone else's.
2. Every marketer has their own Vellum assistant connected to Sanity. Their assistants know our content patterns, our brand voice, our taxonomy. When a marketer says "draft me a showcase page for X," the assistant pulls the right templates, suggests the right copy, and can open a PR.
The result: a showcase page used to take a week. Now it takes half a day. Thanks to Marina (@marinatrajk) for proving this out on the first ones.
GTM team members who write copy can vibe-code experiment pages. Engineers can jump directly into website updates without context-switching, which means we're shipping PLG improvements almost daily.
And because the website and the product share infrastructure now, we can do things we couldn't before. Our main homepage CTA is fully dynamic: it knows the name of your Vellum assistant when you're logged in, and personalizes the call to action accordingly. Marketing site and product are blurring into one continuous experience.
What's still hard (the real bottleneck)
Time for the part I haven't seen anyone admit to.
Transferring your data is easy. Coding agents do that well. Matching your existing design is hard.
Recreating a polished design from a reference takes a lot more work than people expect. Claude Code, Claude Chrome, the visual tools. They're not yet great at replicating an existing design pixel-perfectly. They get the structure, they often nail the components, but the spacing, the micro-interactions, the small things that make a site feel intentional? That's where you still need a designer in the loop.
For us, the bigger ongoing bottleneck has been building a consistent process for shipping design updates at scale once we've migrated. Ad-hoc design tweaks from five different vibe-coded pages start to drift fast. We're working on internal processes for design system governance that we'll share more about soon.
If you're doing this migration: budget more time for design replication than you think you need.
What we preserved (the part that scared me most)
The migration didn't tank our SEO. That was the metric I was most worried about going in.
Our LLM leaderboard tool gets about 80% of our organic traffic. If that page lost rankings, the migration would have paid for itself in lost lead value alone. We preserved its URL, redirected every supporting page correctly, and watched rankings hour by hour for the first week. We had some hiccups (a few canonical issues on launch day) but we caught them fast.
Sanity has been a delight to work in. Our content lead Nick (@grim_tonal) has 10x-ed his GEO article shipping velocity. He told me he used to dread publishing days. Now he ships before lunch.
This isn't a paid Sanity ad. We just genuinely love it.
The takeaway
If you're a marketing leader on Webflow and you've been wondering whether a migration to a real stack is feasible: it is. Now is the right time. The AI tools have caught up. Your job is to plan the invisible work, partner closely with an engineer for the parts that need one, and budget extra time for design.
The unlock isn't just the saved subscription cost. It's the speed. It's having your engineering team able to contribute to the website without leaving their tools. It's marketers writing PRs. It's a marketing site that finally feels like a piece of the product, not a billboard sitting next to it.
Go take a look at vellum.ai. Click around. Notice how fast the pages load, how the design feels, the little interactions on the way through. That's the result of the migration. Tell me what you think.
