Payload CMS: our review after putting it into production

Since June 2026, the site you are reading has been running on Payload CMS and Next.js, a widely used framework for building websites. We migrated nearly 200 articles from Webflow, along with our case studies and service pages, in both French and English. Here’s how Payload changes daily operations, its real costs, when we wouldn’t recommend it, and the pitfalls of migration. Technical and pricing details verified as of late September 2026, on Payload 3

Payload CMS at a glance, and what has changed since 2024

Payload is an open source headless CMS (MIT license), designed for Next.js. A CMS is the tool used to manage a site’s content: it’s the admin panel where you write text and add images. “Headless” means this admin panel doesn’t control the layout: it stores the content, and the custom-built site displays it as needed. “Open source” means Payload’s code is public and free to use, even for commercial sites

With Payload, content types, their fields, and user permissions are defined in the project’s code. Since version 3, released on November 19, 2024, Payload installs directly into a Next.js application: the site and its admin form a single project. It works with the most common databases (PostgreSQL, MongoDB, SQLite)

Three key developments for a 2026 decision:

• Joining Figma and the end of managed hosting for allFigma announced on June 17, 2025 that the Payload team was joining and committed to keeping the software free. However, creating projects on Payload Cloud, the editor’s managed hosting, is now reserved for the Enterprise plan, Payload’s paid offering for large organizations. In practice, the site must be hosted elsewhere: on a rented server or with specialized providers like Vercel or Cloudflare, for which Payload provides ready-to-use templates
• A steady release pacePayload releases a new version almost every week: version 3 went from 3.0 to 3.90 in under two years, and version 4 is in development. Keeping up with these updates is regular work to factor into maintenance
• A close tie with Next.jsNot all Next.js versions are compatible with Payload: updating one requires checking the other

If you’re looking for what we build with Payload, see ourPayload CMS agency.

What we actually have in production

Our own siteNext.js 16 and Payload 3 in the same application, a PostgreSQL database, a server with OVH, and a separate staging site (a copy of the site for testing before going live). The blog, case studies, service and sector pages, menu, and footer are all managed in the admin. We set one rule: any visible text on the site must be editable without touching the code

Zéro Doute, a directory of verified service businesses in Charente. We developed the site and its admin: company profiles, testimonials linked to each business, articles, and contact requests logged in the CRM. Today, the Zéro Doute team manages the site independently: they add newly certified companies, publish audio testimonials from their clients, and update ratings. The content model (the list of content types, their fields, and the links between them) also includes business rules: a testimonial cannot be published if the company it’s linked to is still a draft

Parallaxe Studio, an architectural photography studio: starting from a static prototype, the site is fully managed in Payload (pages, projects, services, images)

These projects are featured on the page our Payload CMS case studies.

When Payload is the right choice

Based on what we’ve built, Payload makes sense in four scenarios:

1. Extensive, interconnected content. Articles, case studies, offers, companies, testimonials: each type has its own fields, and the links between content are true relationships with rules. Zéro Doute’s testimonial publishing rule is a good example.
2. A multilingual site with fine-grained control. Each field (title, text, button, etc.) has its version in every language, with different URLs per language if needed. Our site works this way in French and English.
3. A site that needs to connect to other tools or scale. CRM forms, directories, client portals, internal search: everything is developed within the same project as the site.
4. The desire to own your site. Code and content are yours, the database can be exported, and hosting can be chosen, including in France.

When not to choose Payload

• No one to handle technical maintenance after launch. A Payload site is an application: you need someone, in-house or a provider, for updates, hosting, and evolution.
• A team that wants to modify the design themselves. In the admin panel, you edit content and assemble the sections designed for your site; changing the design or creating a new section type requires code.
• A built-in multi-level approval workflow (e.g., a writer submits, a manager approves) or SSO login. Drafts, previews, and roles (who can do what) are included; anything else falls under the Enterprise plan, on a quote basis, or requires custom development.
• A small, stable site to launch in a few days. An all-in-one tool like Webflow or Wix handles this well, including hosting, security, and backups.

Compared to alternatives, our take is straightforward. Webflow remains the right choice when the team wants to retain control over design and requirements change littlewe also offer it (see the strengths and limitations of Webflow CMS). WordPress makes sense mainly for a heavy existing setup or an essential business extension. Strapi and Directus split the site and admin into two separate applications; Directus is primarily designed for data management (our review of Directus). Payload’s decisive advantage for us: a single project to develop, host, and maintain.

What this changes for the marketing team

Drafts and previews. On our articles and case studies, each edit can be saved as a draft, with auto-save during input, then checked using the Preview button before publishing. Only published content is visible to the public.

Version history. When enabled for a content type, Payload keeps successive copies of each document, shows what changed between versions, and allows reverting. We retain 30 per document (the default setting is 100). The only limitation: changes made directly in the database, outside Payload, leave no trace.

A decision to make during design: which content types support drafts. Drafts and version history are configured per content type. For pages that rarely change, direct publishing may suffice; for pages undergoing major revisions or edited by multiple people, drafts become essential. This choice is made when designing the content model: it’s more costly to change later.

Multilingual support. Each translatable field has its French and English versions; if the English field is empty, the site displays the French version.

Creating a page without a developer. The admin panel lets you assemble a new page from the sections designed for the site. With the Scroll AI Builder that we offer on our Payload sites, a new page can be created in about ten minutes from a prompt, then reviewed before publishing.

What remains technical. Some operations still require a developer. Redirects, for example: when you rename a published page’s URL, the old address must redirect to the new one. An official module allows managing them from the admin; you must plan, during development, for the site to apply them. More broadly, the admin is only as good as the content model you’ve designed: that’s where team autonomy is determined.

Costs to anticipate

Software: zero. Payload is free, with no mandatory subscription (WordPress is too, but its advanced themes and plugins are often paid). Only the Enterprise plan (single sign-on, approval workflows, announced visual editing, etc.) is paid, based on a quote. All-in-one tools, on the other hand, operate on a subscription model: Webflow, for example, charges a subscription per site, plus a workspace subscription and additional users.

Hosting: low.For a showcase website with around ten pages and under 10,000 monthly visitors, our typical setup costs less than €10 ex-VAT per month: a small OVH server and the domain name, with add-ons (emails, analytics, network protection) staying on free plans. Costs rise with volume: heavier databases, high traffic, or large email volumes.

Development: the main cost.It depends on the number of pages and templates, design complexity, content volume to migrate, multilingual needs, and integrations with your tools. Part of the budget goes to designing the content model: this work is what makes the admin panel easy to use later. Each project is quoted after an initial discussion about your needs.

Maintenance: the often-overlooked cost.With an all-in-one tool like Webflow or Wix, the platform handles servers, security, and backups. With a self-hosted Payload site, as with WordPress, someone must do it. On our site: engine updates every month, encrypted database backups every night, regular checks that backups restore correctly, external monitoring to alert if the site goes down, and notifications if a backup fails. We offer this monitoring for the sites we develop, if you wish.

Changing CMS: five checkpoints from our own migration

Our new site has been live since June 12, 2026. It came from Webflow, but these points apply to any migration, whether from WordPress or another all-in-one tool. Migrating nearly 200 articles revealed pitfalls not covered in the documentation. Here are the ones we encountered, and the checklist we derived.

1. The article body is not the whole article. In the old tool, some content may live outside the main text. In our case (Webflow), article FAQs were stored in a separate collection (a standalone content list, like a separate spreadsheet tab), linked to each article, and an import that doesn’t follow this link leaves them behind. In WordPress, this often includes fields added by plugins. What we check: a full inventory of all fields for each content type, including their relationships, before writing the migration script.

2. Automatically compare old and new content. Manual proofreading isn’t enough for hundreds of pieces of content. What we check: a script automatically compares old and new content, field by field, before going live.

3. Watch out for traces of the old tool. Every tool leaves its own. Webflow’s “empty” paragraphs often contain an invisible character that creates large gaps between paragraphs if imported as-is. In WordPress, this might include plugin shortcodes, which lose meaning outside WordPress. What we check: the rendered output of imported articles, not just their text.

4. Check the page actually served, not just the admin panel. The title displayed in Google and the page’s canonical URL may be correctly set in the admin, but appear too late in the page code because Next.js sends the page in chunks. Next.js states that Google can read them; we prefer not to take the risk and place them at the start of the page. What we check: the page as Google receives it, for each page template.

5. Treat URLs as a separate project. Redirects from old URLs are prepared before launch, but the work doesn’t stop there: renaming a URL later breaks direct links written in other articles’ text. What we check: every rename goes through a redirect and internal link repair.

The full method (audit, content mapping, redirect plan) is detailed on our Webflow to Payload migration.

Our take

Payload is now our default choice for sites with extensive linked content, multiple languages, custom features, or growth potential. It’s not a hands-off option: it replaces an all-in-one subscription with a site you own, which you must host, back up, and update. If no one can handle this work, or if your team mainly wants to edit the design themselves, an all-in-one tool will remain more suitable. To decide based on your situation, our custom website design and redesign page explains how we choose the right tool with our clients.