By Mehdi HassanIs Payload CMS a good replacement for the Webflow CMS?
Payload CMS is a strong replacement for the Webflow CMS for teams that want ownership: your content sits in your own database, the admin is part of your codebase, and there are no item caps or editor seat fees. It replaces Webflow's CMS and editor, while Next.js replaces the Designer and hosting. It's the wrong choice for a team with no developer, because someone has to run it.
We're not neutral observers here. Our own site runs on Next.js and Payload, so the advice below comes from building and running it, not from reading the docs. For the wider move, see our Webflow to Next.js migration guide.
What does Payload actually replace when you leave Webflow?
Payload replaces Webflow's CMS collections, the CMS panel and the Editor. Since Payload 3, it installs directly into a Next.js app, so the admin panel, the API and your website are one deployment.
Webflow feature | Payload and Next.js equivalent |
|---|---|
CMS collections | Payload collections defined in TypeScript |
Collection fields | Field types: text, rich text, relationship, upload, blocks, arrays |
The Editor | Payload admin panel with live preview |
Staging and publishing | Drafts, versions and scheduled publishing |
Asset manager | Upload collections with S3, R2 or similar storage |
CMS API | REST, GraphQL and the Local API |
Roles and permissions | Access control functions per collection and field |
301 redirects | A redirects collection read by Next.js |
The Local API is the quiet advantage. Server components in Next.js query Payload directly in the same process, with no HTTP round trip and full TypeScript types, which makes pages simple to build and fast to render.
How does Payload's live preview compare to editing in Webflow?
Payload's live preview shows the real page next to the edit form and updates as the editor types. It's not Webflow's free-form canvas, because editors fill fields and arrange blocks rather than dragging elements, but it answers the question marketers care about: what will this look like when I publish?
Live preview works by loading your front end in an iframe inside the admin and sending it the unsaved document as it changes. Pair it with drafts and versions, and an editor can change a pricing page, check it on desktop and mobile breakpoints, save a draft for review and publish when it's approved. Every published version is kept, so rolling back a bad edit takes a click.
How do you set up a Webflow to Payload CMS migration?
The migration runs in a fixed order: model the content, build the templates, import the content, then redirect and launch. Skipping ahead to the import before the model is settled is the most common reason these projects stall.
Audit the Webflow CMS
List every collection, field, reference and the pages that use them. Cut collections nobody updates.
Define Payload collections
Write the collections in TypeScript, turning Webflow's flat fields into relationships and blocks where it helps editors.
Build page templates and blocks
Build the Next.js templates and the block components, with live preview wired up for each collection.
Export and transform content
Pull each collection by CSV or the Webflow API, convert rich text HTML into Payload's rich text format and download every image.
Import with a seed script
Use the Local API to create documents in dependency order: authors and categories first, then posts and pages.
Map redirects and launch
Keep URLs where you can, redirect the rest, then check titles, canonicals, sitemaps and structured data before switching DNS.
Images need special care: every image URL in a Webflow export points to Webflow's CDN, so they must be re-uploaded into Payload's storage. Webflow's own CSV import has the same weak spot in reverse, turning rich-text images into placeholders, which is a good reminder to check rich text by hand after any import.
Where should you host Next.js and Payload?
You need two things: somewhere to run the Next.js app and a database. Common choices are Vercel or Cloudflare for the app and a managed Postgres or MongoDB for the data, with images in object storage such as S3 or Cloudflare R2.
This is the part Webflow handled invisibly. You now own backups, environment variables, database migrations and Payload upgrades. None of it is hard for a developer, but it is real work, so name the person responsible before you start.
What running Payload ourselves taught us
We run our own site on Payload, so we've hit the edges you'd expect from a self-hosted CMS. Build pipelines need care: the build shouldn't depend on runtime secrets that the build server doesn't have, so we split build-time and run-time configuration. The admin panel is a React app with its own styles, and it should load them the way Payload expects rather than having them bundled in with the site's CSS. And custom admin views, such as an overview or analytics page, are worth building once the basics work, because they make the CMS feel like the team's own tool.
None of these are reasons to avoid Payload. They're the kind of maintenance a developer should expect to own.
What does a Payload CMS marketing site cost to run?
Payload itself is open source and free to self-host, so the running cost is hosting, the database and file storage, which for a typical marketing site is modest. There are no per-editor seats and no CMS item limits, which is the main financial reason teams leave Webflow's plan structure.
The larger cost is people: the initial build and a developer's time for upgrades and changes. Compare the full picture in Webflow to Next.js migration cost before you decide, and see our production lessons from setting up Payload for a marketing site.
Payload or Sanity: which should you pick after Webflow?
Pick Payload when ownership is the priority and pick Sanity when you'd rather not run a database. Both pair well with Next.js and both can give marketers a good editing flow.
Pros
- Content in your own database, with no external content service
- CMS and website in one repo and one deployment
- No editor seat fees or item caps
- Fully typed Local API for fast server-rendered pages
Cons
- You run hosting, backups and upgrades
- Real-time multi-editor collaboration is less of a focus than in Sanity
- Requires a developer for schema and layout changes
- A smaller plugin ecosystem than the biggest CMSs
