Webflow to Payload: when to move off the visual builder

Teams rarely leave Webflow because it stopped working; they leave because they outgrew it. A marketing site that began as a handful of pages turns into a content operation with structured data, several editors, and real SEO stakes, and the visual builder that made the first version quick starts to get in the way. Moving to Payload is an infrastructure change rather than a redesign: the content model moves into code, you take over the hosting, and the editorial workflow runs on a platform you own. This piece covers why teams make that move, how the migration works, what it costs, and when staying on Webflow is the better call.

We are an official Payload partner, so we know that side best, and we will say plainly where Webflow is still the right tool.

Why teams move off Webflow

Webflow is a strong visual website builder, and for a brochure site or an early marketing page it is hard to beat: you design in the browser, publish in a click, and never think about hosting. The friction shows up later, as the site becomes a content operation.

The content model is the first limit. Webflow’s CMS is configured through the Designer, and its collections work well for straightforward content, but the structure lives inside Webflow rather than in your codebase, and a schema change carries no review or version history. Relationships exist through reference and multi-reference fields, yet querying across them is shallow, and every plan caps how many items and collections you can hold.

Hosting and ownership are the second. Webflow runs the hosting for you, which is convenient until you need control over caching, data residency, or the ability to run the CMS next to the rest of your stack. The code export gives you rendered HTML and CSS, not the CMS itself, so you cannot take the platform with you.

Cost is the third, and it grows in an awkward direction. A Webflow site with the CMS runs on the Premium plan at $25 a month, and as the team and its governance needs grow, Webflow moves you onto its platform plans: the Team plan is $2,500 a month on an annual contract and includes ten seats, and Enterprise is a custom quote. The bill rises with the tier you need and the number of people who touch the site, rather than with the value the site produces.

Payload was designed to answer each of those limits. Its content model is a set of TypeScript files in your repository, reviewed and deployed like any other code, with full relational data on PostgreSQL and no item caps. You self-host it wherever you like and own it under the MIT licence with no per-seat charge. Since version 3.0 it installs directly into a Next.js application, so the CMS and the site share one codebase.

Webflow and Payload at a glance

	Webflow	Payload
Hosting	Managed by Webflow, automatic	Self-hosted (Vercel, Cloudflare, AWS, and others)
Content model	Configured in the Designer GUI	Defined in TypeScript, version-controlled
Relational data	Reference and multi-reference fields, with item and collection caps	Full relational (PostgreSQL or MongoDB), no item caps
Editorial UX	Polished visual editor with on-page editing	React admin panel, customisable with development
Licensing and cost	Subscription: Premium site $25/mo (with CMS); Team plan $2,500/mo for 10 seats	MIT, free core, no per-seat fee; pay for infrastructure
SEO control	Meta, Open Graph, canonicals, and sitemap handled for you	Built in Next.js, with full control
Extensibility	Webflow features plus custom-code embeds	Fully code-extensible, and the platform is yours
Animations	Webflow Interactions, built visually	Rebuilt in React (Motion) or CSS
Best for	Design-led marketing sites, small teams, no engineering	Structured content, relational data, teams with engineering

Two rows carry most of the decision. The content model and the licensing lines are where the platforms diverge most, and the editorial-UX line is where Webflow keeps a real advantage, since its visual editor is more approachable out of the box than a code-configured admin panel.

What changes: the content model

The move is worth making only if you use it to fix what a visual builder could not do, so do not copy Webflow’s structure across one-to-one. Webflow’s CMS often stores a page as flat fields, a hero headline, a hero body, a hero image, and so on, which makes rigid templates that need a developer whenever a layout changes. In Payload you model pages as reusable blocks instead, and editors compose a page from a library of block types in any order.

A collection is a TypeScript file that declares its fields, relationships, and access rules:

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: { useAsTitle: 'title' },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'author', type: 'relationship', relationTo: 'authors', required: true },
    { name: 'categories', type: 'relationship', relationTo: 'categories', hasMany: true },
    { name: 'body', type: 'richText' }, // Lexical
    { name: 'layout', type: 'blocks', blocks: [/* your section types */] },
  ],
}

Webflow’s reference and multi-reference fields become Payload relationship fields, so a post’s author becomes a relationship to the authors collection. Rich text is the one field that needs care: Webflow exports it as HTML, while Payload stores it as Lexical, a typed JSON tree, and converting between the two is the fiddliest part of the content work.

How the migration works

The migration runs through a familiar shape, and scoping it early matters more than the code.

It starts with an audit of what you have. Webflow exports each CMS collection as a CSV, with media referenced by CDN URL and rich text as HTML, and you pull the list of indexed URLs from Google Search Console at the same time, because that list is the basis of the redirect map. This is also the moment to prune the dead content that does not deserve to move.

The media moves next, handled by a script that downloads each asset from Webflow’s CDN, uploads it to your storage (Cloudflare R2, AWS S3, or Payload’s own storage), and records a mapping from old URL to new so that references can be rewritten in the content.

The content comes last, and rather than re-key it by hand you run a script that reads the CSV and writes through Payload’s Local API, which sits in the same Node.js process as the application and talks to the database directly, without HTTP requests or rate limits. Keying each record to its Webflow slug lets the import upsert, so it can run repeatedly as content changes before cutover:

import { getPayload } from 'payload'
import config from '@payload-config'

const payload = await getPayload({ config })

for (const row of webflowRows) {
  const data = { title: row.name, slug: row.slug /*, ...other mapped fields */ }

  // Upsert on slug so the import can be re-run safely
  const { docs } = await payload.find({
    collection: 'posts',
    where: { slug: { equals: row.slug } },
    limit: 1,
  })

  if (docs[0]) {
    await payload.update({ collection: 'posts', id: docs[0].id, data })
  } else {
    await payload.create({ collection: 'posts', data })
  }
}

The HTML-to-Lexical conversion sits inside that loop. Payload ships an official converter (v3.28 and later) that handles the common cases, with images needing a little extra handling, so plan for time to wire it up and test it against the real markup in your export.

With content in place, the front end is rebuilt in Next.js, and because Payload 3.0 runs inside the same application you can query content through the Local API in Server Components rather than over the network. A few things do not carry across and have to be rebuilt: the SEO metadata that Webflow generated for you (titles, Open Graph tags, canonicals, and sitemaps), any Webflow Forms, and Webflow Interactions, which do not export and are recreated with Motion or CSS.

The last piece is SEO continuity: every indexed URL either keeps its path or gets a redirect to the new one. In Next.js a permanent redirect returns a 308, which Google treats like a 301, and large redirect sets are better handled at the CDN or in middleware than in the config file. Cutover is then staged: lower the DNS TTL ahead of time so the old value expires before you switch, freeze editing, run the import one last time, deploy, and keep the Webflow site reachable at its original subdomain as a reference until the new one has settled.

What it costs

On cost, the change replaces recurring Webflow site and seat charges with a free, MIT-licensed CMS and the infrastructure you run. Editors no longer carry a per-seat fee, which is where the saving grows for a larger team. The offset is engineering: Payload expects a team that can own a self-hosted stack, and editors used to Webflow’s visual canvas need some time on Payload’s admin.

When to stay on Webflow

Webflow is the platform to keep when the site is design-led and small, when the team has no engineering capacity to own a self-hosted stack, and when the content is simple enough that references and item caps never bite. A marketing team that publishes a handful of pages, values the visual editor, and leans on Webflow’s built-in animations gains little from Payload and takes on cost and engineering it does not need.

The case for Payload starts when content becomes structured and relational, when editor seats multiply and their cost climbs, when you need the CMS inside your own infrastructure, or when the site is really an application that a visual builder cannot hold. That is the point where owning the content model in code pays for the move.

How WAYF can help

WAYF is an official Payload partner and Top Contributor, building Payload and Next.js platforms for marketing-led teams and enterprises. If you are weighing a move off Webflow, we will look at your content, your editorial team, and your growth plans, and tell you whether Payload earns the change or whether Webflow still fits. For our content platform services, see wayf.ai/services, and see our work for platforms we have built.

FAQ

1. Why do teams move from Webflow to Payload?

   Usually for some mix of reasons: they want the content model in code and under version control rather than configured in a GUI, relational data without Webflow's item and collection caps, ownership and self-hosting instead of renting, and an end to per-editor-seat costs. Teams already on Next.js have one more reason, since Payload runs inside the same application.

2. How long does a Webflow to Payload migration take?

   It depends on the number of collections, the volume of content, how much custom animation the site uses, and whether it runs multiple locales, so we scope a timeline per project rather than quote a standard one. The HTML-to-Lexical rich text conversion is usually the least predictable part.

3. How does the cost compare?

   Webflow is a recurring subscription. The CMS runs on the Premium plan at $25 a month, and larger teams move to the Team plan at $2,500 a month for ten seats, or a custom Enterprise plan. Payload's core is MIT-licensed and free, so you pay only for the infrastructure you run, with no per-seat charge. For a small site the difference is modest; for a larger editorial team it grows.

4. Should you use PostgreSQL or MongoDB with Payload?

   PostgreSQL is the stronger default for a Webflow migration, because most Webflow content is relational and Postgres handles that natively. MongoDB suits content that is genuinely document-heavy with few cross-collection relationships, which is the less common case here.

5. What happens to Webflow animations?

   Webflow Interactions do not export. The code export gives you the rendered HTML and CSS but not the interactions runtime, so animations are rebuilt in the new stack with Motion (formerly Framer Motion) or CSS. Simple fades and slides rebuild quickly; complex scroll-sequenced work takes real design and development time.

6. How do you protect SEO during the move?

   Build the redirect map from Google Search Console before any front-end work, and preserve URL slugs wherever you can, since identical paths need no redirect. Rebuild the meta titles, descriptions, canonicals, Open Graph tags, and structured data in Next.js, since Webflow generated these for you, and submit the new sitemap to Search Console on the day of cutover.

Sources

• Webflow, plans and pricing (May 2026)
• Webflow, import and export CMS Collection content
• Payload CMS, Local API reference
• Payload CMS, converting HTML to Lexical
• Payload CMS, Next.js integration
• Next.js, redirects configuration