Webflow is a fine tool. We've shipped marketing sites on it. We've recommended it to clients whose project didn't need anything else. It's faster to set up than a custom build, the visual editor is real, and the hosting is one click.
It's also a tool you can outgrow. When you do, the migration is a real piece of work, and the timing is more important than the migration itself.
This post is about both: the signals that say it's time, and a walkthrough of a migration we did recently.
When Webflow is the right answer
Before talking about leaving, it's worth being honest about staying. Webflow is the right answer when:
- The site is mostly marketing pages (10–25 pages), updated occasionally by a designer or marketer.
- You don't need complex content modelling. Pages have predictable structure.
- Editors are comfortable in a visual editor and not comfortable in a CMS like Sanity or Contentful.
- Page-level performance is fine, not exceptional, and that's acceptable.
- You're not building anything resembling a web application alongside the marketing site.
If all of these are true, building custom is overkill. Webflow ships in less time, costs less to maintain, and editors stay productive.
Five signals you've outgrown it
Webflow starts hurting when one of these is true:
1. The CMS is the bottleneck.
Webflow's CMS works for simple content (blog posts, case studies, team members). It struggles when content models get nested or relational. If your editors are pasting structured data into rich-text fields because the schema doesn't support it, you've outgrown the CMS, not the visual editor.
2. The site needs a real app sitting next to it.
Customer login? Dashboards? Server-side logic? Webflow doesn't do this. You can patch it with third-party tools and Memberstack-style add-ons, but each patch is a thing to maintain. A marketing site that's growing into a product needs a runtime, not a static-export-plus-add-ons.
3. Performance has plateaued and you've hit the page-weight ceiling.
Webflow ships every animation library, every interaction script, every dependency on every page. You can hand-tune some of it. You can't get the kind of performance that comes from a custom build with route-level code splitting. If your Lighthouse score is stuck around 70 and you've optimised everything you can, the platform is the floor.
4. SEO control isn't enough.
For most marketing sites, Webflow's SEO controls are sufficient. When they aren't (custom JSON-LD per page type, dynamic sitemap rules, hreflang for ten locales, structured data validation at build time), you outgrow the tool. The escape hatches Webflow offers (Embed blocks for custom code) are real but fragile. Eventually you're maintaining a parallel custom system inside Webflow, which is the worst of both worlds.
5. The team is now technical and Webflow's pricing per editor stings.
Webflow's pricing scales by editor seat. When your team is mostly engineers who'd prefer to edit content in code or in a Studio next to the codebase, the per-seat pricing stops making sense. The savings on hosting alone often pay for the migration within a year.
What you migrate to
For most sites moving off Webflow, the stack we recommend is:
- Next.js (App Router) as the framework. Server components for marketing pages, client components for the parts that need interactivity.
- Sanity as the headless CMS. Better content modelling than Webflow's CMS by an order of magnitude, with an embedded Studio that editors actually like.
- Tailwind for styling, Framer Motion for animations.
- Vercel for hosting. Or Cloudflare Pages, or your own infrastructure.
This isn't the only stack. Astro is good for content-heavy marketing sites. Remix is fine. Plain static site generators (Hugo, Eleventy) are excellent if your editors are happy in markdown. But Next.js + Sanity is the default we reach for, because it scales from "marketing site" to "marketing site plus a customer dashboard" without re-platforming a second time.
A migration that ran on three weeks
A few months ago we migrated a 22-page marketing site off Webflow. The client was a B2B SaaS company; their team had grown from two to fifteen, and the marketing site was now blocking the product roadmap (they wanted to add an authenticated customer dashboard that Webflow couldn't host).
Week one: audit and content extraction.
We started with a Webflow export. The HTML/CSS export is real but messy. We didn't try to keep the markup. We kept the content.
The CMS content (blog posts, case studies, team) we exported via Webflow's API into JSON, then transformed into Sanity-compatible documents. About 80 documents total. Took half a day with a Node script. We checked the resulting Sanity documents into Studio and the team validated them.
The static pages (homepage, services, about, contact, etc.) we treated as a content rewrite. The old Webflow versions had accumulated copy decisions from three different writers over four years. We took the chance to clean up the messaging during migration rather than after.
Week two: rebuild the marketing surface.
The team designed the new pages in Figma. We built them in Next.js. Two engineers, parallel work. By end of week we had the homepage, four service pages, about, contact, and the blog index live on a staging URL.
The pace was deliberately faster than a from-scratch project because we weren't rediscovering the IA. The IA was decided. We were re-implementing it on a better foundation.
Week three: SEO migration and cutover.
This is the part most migrations get wrong. The old site had four years of accumulated backlinks pointing to specific URLs. If any of those URLs changed without a redirect, the SEO ranking would drop.
We mapped every old URL to its new equivalent. About 30 of them changed structure ("/blog/2022/post-slug" became "/blog/post-slug" because the dated path no longer made sense). For each, we wrote a 301 redirect rule.
Then we set up:
- The dynamic sitemap (regenerated on content change via Sanity webhook)
- JSON-LD per page type (Organization, Service, BlogPosting, FAQPage)
- Per-page metadata via a
createPageMetadata()utility, with canonical URLs and language alternates - Tag-based revalidation in Next.js so content edits in Sanity went live within seconds, no rebuild needed
Cut over on a Wednesday morning. The old site went down at 9:00, the new one up at 9:00:30. We monitored ranking for the next two weeks. Three URLs lost a couple of positions in the first week and recovered by the end of week two. Nothing else moved. Migration successful.
What changes
- Editorial: editors use Sanity Studio instead of Webflow editor. After a 30-minute walkthrough, the team preferred it. Sanity's content modelling means structured data goes in structured fields, not pasted into rich-text.
- Engineering: the site is in a git repository, deployed via Vercel from
main. Pull requests for content changes are a thing (if you want them). Most edits stay in Sanity. - Performance: Lighthouse Performance went from 68 to 96. Page weight roughly halved. The hero image is the only thing that loads above the fold; the rest is code-split and lazy-loaded.
- Cost: hosting dropped from Webflow's per-seat pricing to Vercel's usage pricing. For a 22-page site with moderate traffic, that's a saving in the low four figures annually.
What doesn't change
- The site still looks the same to visitors. We rebuilt the design pixel-for-pixel where it was good, and improved it where it wasn't. The brand didn't shift.
- SEO ranking. With careful URL mapping and redirects, the migration was invisible to Google.
- Content quality. We did rewrite some copy during migration, but that was a choice, not a forced consequence of the platform change.
When you stay on Webflow
Migrations aren't free. If your situation is:
- The site is mostly marketing pages and a small CMS
- Editors are non-technical
- Performance is acceptable
- You don't have a product growing next to it
Then Webflow is still the right answer. The pain of migration only pays off when you have a reason to leave.
If any of the five signals above are true for your site, the migration window is now rather than later. Each year you wait, the redirect map gets longer and the content gets staler. The migration is a project. The cost of not doing it is a slow tax on every future product decision.
If you're staring at the signals and want a second opinion, start a conversation. We'll tell you honestly whether to migrate or stay, and if the answer is migrate, we'll quote it for real.