Drupal vs Payload

Drupal and Payload are both open source, and both can run a large, multilingual, permission-heavy content estate. They put the work in different places. Drupal is a PHP platform with editorial workflow, translation and layout tools in core, extended by a large set of contributed modules and usually configured through its admin. Payload is a TypeScript application you install in a Next.js project, where the content model, access rules and hooks are code.

This page compares supported Drupal, meaning Drupal 11 today and Drupal 10 until its end of life on 9 December 2026, with Payload 3. For the support dates and the upgrade paths out of Drupal 10, see our Drupal 10 end-of-life guide. For the mechanics of a move, see the Drupal to Payload migration guide. This comparison is about choosing between the platforms.

The short decision

Upgrade Drupal when the site’s editorial machinery already works. Content Moderation, per-field translation, Views and a set of maintained contributed modules are working assets, and a supported Drupal keeps them. Scope the upgrade against module compatibility and custom code; a rebuild re-implements these capabilities.

Choose Payload when the team would benefit from keeping a Next.js frontend, the content model and access rules in one TypeScript codebase, or when custom modules mostly work around Drupal’s content model. Both platforms can serve several channels through APIs. Payload can be run by your own platform team, a delivery partner or, under an enterprise agreement, Payload.

Three ways to run Drupal, and where Payload sits

Drupal can render the whole site through its themes, which use Twig, Drupal’s template language. It can also run progressively decoupled, where a JavaScript frontend takes over parts of pages that Drupal still serves, or fully headless, where Drupal only manages content and a separate frontend renders everything. Drupal’s decoupled documentation describes the headless mode, and JSON:API is in core for it.

The comparison with Payload depends on which of these you run. A coupled Drupal site gets layouts, preview and caching from the platform, so a move to Payload also means building a frontend. A headless Drupal already has that frontend, so a move changes the backend and the data it serves. Payload is headless by design. Its admin and APIs can run inside the same Next.js application as the site, which is the arrangement where it differs most from Drupal.

Editorial workflow and moderation

Drupal’s Content Moderation module lets a published version stay live while a separate working copy goes through review. Workflows define the states and transitions; the default editorial workflow adds Draft and Archived to Published, and each transition gets its own permission. Each translation is moderated separately. Revisions are on by default for content types, and comparing two revisions needs the contributed Diff module.

Payload’s drafts and versions give a saved draft over a live version, diffs, restore, autosave and scheduled publishing, all in core when configured. A collection’s update access rule can constrain _status to restrict who can publish, and the admin hides the Publish button for those users. Named review stages with their own permissions are the part Drupal ships and Payload does not: Payload sells Publishing Workflows as an enterprise feature, or a team builds the stages in code.

For an institution whose approval policy maps onto Drupal’s states and transitions today, that difference is concrete work in a move. List the states, transitions and roles before pricing either option.

Structured content and page building

Drupal models content as entity types and bundles, which editors know as content types, with fields added per bundle in the admin and exported as configuration. The contributed Paragraphs module adds component content, and it is widely used. Payload defines collections and fields in TypeScript, and its blocks field plays the role Paragraphs plays in Drupal.

Page building is where Drupal is moving. Layout Builder is in core and lets editors override a layout per item. An open core issue proposes deprecating it and moving it to contrib, and it is not decided. Drupal Canvas, developed under the working name Experience Builder, is a stable contributed module and the default editing experience in Drupal CMS 2. A team choosing Drupal for page building today should check which of these it is committing to.

Payload gives editors blocks and Live Preview in core, and developers can add custom React components to the admin. Payload’s enterprise page lists a Visual Editor as coming soon. Treat that as roadmap until it ships.

Drupal CMS adds to the choice. It is a ready-made starting point built on Drupal 11 core, with recipes for media, SEO, search, forms and optional AI features. Once installed, it is ordinary Drupal: there is no separate Drupal CMS to update.

Multilingual publishing

Drupal’s multilingual support is four core modules: Language, Content Translation, Configuration Translation and Interface Translation. Each field on each bundle is set as translatable or not. Configuration and interface text are translated too, and the contributed TMGMT module can trigger translation jobs when the source text changes.

Payload localizes at the field level. You declare the locales, mark the fields that vary and set fallback, and one document carries every language. Independent publication status per locale is available through an opt-in beta feature; the default status applies across locales. Access rules decide who edits what. Interface translation for the site belongs to your frontend, while admin UI translations can be configured in Payload.

Both handle complex multilingual estates. Test the publication scope on each: whether one language can publish while another stays in draft, and who signs off each translation.

Permissions and governance

Drupal groups permissions into roles, and access to individual nodes and fields is controlled through code hooks. The contributed Field Permissions module gives field-level permissions an admin interface, and its project page describes it as minimally maintained. Payload’s access control is a set of functions per collection, document, field and operation, which can combine the user and the document’s data in one rule.

Drupal’s core targets WCAG 2.2 AA for public and admin interfaces, and the same page says a finished site is not automatically accessible and that contributed modules are outside that gate. Accessibility on a Payload build depends on the frontend and on admin customisations, so it belongs in the acceptance criteria for either route.

APIs, modules and upgrades

JSON:API is in Drupal core. The contributed GraphQL module is maintained, and its 5.x version asks developers to set up and map the schema. Payload generates REST and GraphQL APIs from its config, and its Local API lets server code in the Next.js app query content without an HTTP call.

Contributed modules are a major Drupal advantage and a large part of its upgrade cost. The security team issues advisories only for projects that opted into coverage, and only for their stable releases, so check the shield on each module a site depends on. Payload’s plugin set is smaller; the rest is application code your team maintains.

Drupal promises a continuous upgrade path: an API is deprecated in one major and removed in the next, and contributed and custom code must be updated before a major upgrade. Majors arrive every two years and each is supported for at least four. Drupal’s deprecation guide lists Search for deprecation in 11.5 and removal in Drupal 12; the Drupal 12 alpha notes still describe that removal as proposed. Sites using core Search should plan to test the contributed Search module or Search API before upgrading. Payload ships through npm releases; its 3.x line is current and a 4.0 canary is in development. Its search plugin indexes selected fields in a search collection.

Cost inputs and exit

Neither platform charges a core licence fee: Drupal is GPL-2.0-or-later and Payload is MIT. The cost lines are hosting, database and file storage, security patching, upgrades, paid services, engineering time and editor training. Commercial Drupal platforms such as Acquia, Pantheon and Upsun sell managed hosting with their own plans. Payload can be self-hosted, deployed through hosting templates or hosted by Payload under an enterprise agreement; its enterprise features require a sales discussion. Price the same editors, languages, environments and traffic on both sides.

Both keep content in a database you control. Leaving either platform means moving the content model and the behaviour built around it: workflows, access rules, listings and integrations. That work is the same kind in both directions, and it is proportional to how much of the site’s logic lives in modules or application code.

Upgrading to a supported Drupal is a serious option

For many Drupal 10 sites, the right decision is Drupal 11. Drupal 11 is supported until Drupal 13 is released, and a site that upgrades keeps its moderation, translation, Views and module investment subject to compatibility checks. Drupal 12 is scheduled for the week of 7 December 2026. On 29 September the Drupal 12 release list shows only 12.0.0-alpha1; Drupal says alpha releases should not be used in production. It is not a production option yet.

Our end-of-life guide sets out the paths and the evidence that decides between them. The comparison adds one question: after the upgrade, is Drupal still the right shape for what the team needs to build next? If the answer is yes, upgrade and stop there.

What survives either choice

Some requirements do not change with the platform, and they are worth writing down before comparing:

• The approval policy: who drafts, who reviews and who publishes, per content type.
• Translation ownership and the rule for missing translations.
• The URL structure, redirects and canonical URLs that search engines and other sites depend on.
• Accessibility obligations for the public site and the editing interface.
• Integrations that read from or write to the CMS, and their owners.
• Retention rules for content, revisions and personal data.
• Who hosts, patches, backs up and monitors the platform.

These carry over whichever way you go. The platform decides how they are implemented and who maintains them.

What a move to Payload rebuilds

A move re-implements the parts of Drupal that do work beyond storing content. Plan for the moderation states and transitions; Views listings, which become queries and frontend components; Webform forms and submission handling; Layout Builder, Paragraphs or Canvas layouts, which need a block schema and a data migration; custom modules, hooks and node access rules, which become access functions and hooks; the translation setup; URL aliases and redirects; and search.

The migration guide maps Drupal concepts to Payload and walks through the extraction and transformation work. Price each item above before committing.

Two decision scenarios

Both scenarios are illustrative. They are not client projects.

An institution with a large Drupal editorial investment. A public body runs a coupled Drupal 10 site with 40 editors, a four-state moderation workflow with separate reviewer and publisher roles, three languages with translations signed off per language, Views-driven listings, a set of forms and a dozen custom modules. Its priority is getting onto supported software before December with minimal disruption to editors. The recommendation is Drupal 11. Its workflow, translation and permission model map onto Drupal’s core features, and a rebuild would re-implement each of them. Payload becomes a candidate only if the upgrade estimate shows the custom modules mostly work around the content model, or if the next phase needs a new frontend and several channels anyway. In that case, list what survives, price what a move rebuilds, and compare the two numbers.

A team whose product needs outgrew the architecture. A company runs Drupal headless behind a Next.js site, with custom modules that reshape JSON:API output for a new mobile app and a partner portal. Five editors publish in two languages, and approval is a single publish right. The team writes TypeScript and wants access rules and schema changes in pull requests. Payload fits: collections, access functions, REST and GraphQL APIs and the admin can live in the same codebase as the Next.js app, and the single publish right is a core access rule. The move rebuilds the listings, forms, redirects and search; the team can arrange hosting itself, through a delivery partner or with Payload under an enterprise agreement. If the editorial team later needs named review stages, price Payload’s enterprise Publishing Workflows against building them.

A short evaluation checklist

Run these with your own estate before choosing:

• Workflow. Write down every moderation state, transition and role. Mark which ones Payload handles in core and which need custom work or an enterprise agreement.
• Translations. Record which fields are translatable, who signs off each language, and whether languages publish independently.
• Layouts. Count the items using Layout Builder overrides, Paragraphs or Canvas, and decide what the block schema needs to hold.
• Modules. Split contributed and custom modules. For each custom one, note whether it extends the model or works around it.
• Listings, forms and search. List the Views, Webforms and search indexes the site depends on, with an owner for each replacement.
• Integrations. List everything that reads from or writes to the CMS.
• Cost. Set the Drupal 11 upgrade estimate beside the rebuild estimate, and include hosting, maintenance and editor retraining on both sides.

A note on our position

WAYF is a Payload partner and contributes to its open source, so we have an interest in this comparison. We recommend upgrading Drupal when its workflow, translation and module investment is the better match, and a delivery partner can run either stack.

If you choose Payload, WAYF’s Payload development service covers the build. For a move from an existing CMS, plan the replatforming around the content, workflows and integrations that need to move.