Migrating from Drupal to Payload: a practical guide for higher-ed and government teams

Drupal 7 reached end of life on 5 January 2025, Drupal 10 follows in December 2026. For institutions that spent the last two years migrating from D7 to D10, another migration decision is already on the horizon.

This is the position a significant number of universities, government bodies, and NGOs now find themselves in. Drupal has historically dominated these sectors: Drupal’s own figures put it at 80% of the world’s top 100 universities. The adoption was earned. Drupal’s security architecture, built-in multisite support, granular permissions model, and open-source licensing made it a serious choice for organisations with complex content governance requirements.

Why these sectors ran on Drupal

Drupal’s permission system is genuinely sophisticated. Role-based access control with per-content-type and per-field granularity, plus configurable publishing workflows, maps well to how universities and government agencies structure editorial teams: departments own their content independently, editors draft without publishing access, and content moves through an approval step before going live. These are real requirements, not edge cases.

Multisite has been another load-bearing feature. A university might run dozens of faculty sites, departmental portals, and library systems under one Drupal installation, sharing infrastructure and a common identity layer. Replacing that without thinking carefully about the target architecture creates problems downstream.

Drupal’s track record also matters in procurement. Government agencies and institutions subject to public tendering often need to demonstrate that the technology choice has a documented security track record, wide community adoption, and precedent in comparable organisations. Drupal has all of that, and it’s a legitimate reason it’s been the default for so long.

What end of life actually means

EOL doesn’t mean the site stops working. It means security patches stop: no new module compatibility releases, no community security advisories, no fixes for vulnerabilities discovered after the cutoff date.

For organisations with compliance requirements (GDPR, accessibility mandates, data protection regulations specific to educational or government contexts), running an unsupported CMS is a risk that auditors notice and procurement processes penalise. Extended security support programs exist from vendors like HeroDevs and Tag1 Consulting, but these are paid stopgaps, not a long-term architecture.

Drupal 10 reaching end of life in December 2026 matters specifically for institutions that migrated from D7 to D10 in the last two years. The work of that migration is still recent, and the timeline is already moving again.

The decision at the fork

When a version reaches EOL, there are two realistic paths: upgrade within Drupal, or evaluate an alternative. We argued that fork at length in upgrade or replatform; this section is the short version.

Upgrading from D10 to D11 is more manageable than the D7-to-D10 step was. Modules written for Drupal 10 typically need compatibility updates; full rewrites are rare. The Drupal Association has made the major-version upgrade cycle more predictable, with a new version expected every two years. For organisations whose teams know Drupal well and whose use case fits Drupal’s model, staying in the Drupal upgrade cycle is a defensible choice.

The case for evaluating an alternative is different. It applies when the institution has been working against Drupal’s architecture: when headless delivery was retrofitted onto a system that wasn’t designed for it, when the front-end is constrained by Drupal’s theme layer, or when the editorial experience has accumulated enough workarounds that the team dreads publishing. For organisations that need API-first content delivery across native apps, AI retrieval, or multi-channel distribution, Drupal’s headless mode is functional but carries architectural overhead a purpose-built headless CMS doesn’t.

We’re a Payload shop, so we’ll be direct about where we stand: for organisations that need genuine headless delivery, a code-first content model, and a platform they can self-host and fully own, Payload is worth a direct comparison. For organisations whose primary requirement is staying within a large, procurement-tested upgrade path with a long community track record, Drupal 11 is a legitimate choice and we’d tell you that upfront.

Why Payload is a credible comparison

Payload is TypeScript-native, code-first, and built headless from the ground up. The content model lives in code, versioned with the codebase, reviewed like any other change. There is no separate CMS configuration layer drifting out of sync with what developers actually built.

Content is stored and served as JSON through a REST and GraphQL API. Every collection and every field is accessible without a separate decoupling layer. A Next.js front-end consumes the same data as a mobile app, an AI retrieval system, or a third-party integration, because the content was never tied to a specific rendering layer.

Payload runs on Node.js, connects to PostgreSQL or MongoDB, and deploys on whatever infrastructure an institution’s security and compliance requirements dictate. No vendor holds the hosting contract or the data.

WAYF holds a top-tier partnership with Payload and contributes actively to its open-source. That depth matters on a migration: we’ve built the collections, access control plugins, and multi-tenant configurations that enterprise and institutional content models require.

Drupal and Payload, concept by concept

Drupal concept	Payload equivalent	What the move involves
Content type (node bundle)	Collection, defined in TypeScript	The model moves into versioned code
Field	Typed field on a collection	Most map directly; formatted long text is the exception
Paragraphs	Blocks field	Each bundle becomes a named block with its own schema
Taxonomy vocabulary	A collection, referenced by a relationship field	Terms become documents with their own fields and URLs
Media entities and files	Upload-enabled collection	Payload regenerates derivatives through its own image pipeline
Users, roles and permissions	Access control functions on collections and fields	Moves from admin configuration into code
Views	No counterpart	Listings are built in the front end against Payload’s query API

Paragraphs are the closest structural match, so existing bundles largely survive the move. Views is the row to read carefully, and the section below sets out what replaces it.

What the migration involves

A Drupal-to-Payload migration runs through five phases regardless of the institution’s size.

Content audit. Before any technical work, the existing content needs cataloguing: what content types exist, how many nodes of each, which fields are in use vs. which were created and abandoned, what custom modules add to the content model, and what content is worth migrating at all. Large Drupal installs often carry years of content that is outdated, duplicated, or no longer linked from anywhere. A migration is a reasonable opportunity to leave that behind rather than carry it forward.

Content model redesign. Drupal’s node-and-field model doesn’t map directly to Payload’s collections. This phase defines what the new model looks like: which Drupal content types become Payload collections, how paragraph and block structures translate to Payload blocks or rich-text configurations, how taxonomy vocabularies map to relationship fields or controlled-vocabulary collections. This is the most consequential phase, because decisions made here affect every step that follows.

Data extraction and transformation. Drupal exposes content through Drush, its REST API, and JSON:API. Extracting the data is generally straightforward; transforming it to match the new content model is where the work concentrates. Field type mismatches, embedded media references, revision histories, and URL aliases all require explicit decisions. A transformation script maps Drupal’s output to Payload’s import format and runs against a staging environment before any cutover.

Access control rebuild. Drupal’s permissions model is granular and often heavily customised. Payload supports field-level and collection-level access control, and a full role-based system with the right plugin architecture. Rebuilding a Drupal permission structure in Payload requires documenting the existing model first, which institutions frequently discover they don’t have written down anywhere.

Front-end and cutover. If the organisation is moving to a decoupled front-end as part of the migration, that work runs in parallel with the data work. URL structure and redirect mapping need to be agreed before cutover. A pre-launch period with both systems running gives the team time to validate new content against old and catch anything the transformation script missed.

For most migrations, the discovery and content model redesign phase takes two to three weeks. The build runs four to eight weeks after that. Enterprise migrations involving custom module equivalents, heavy integrations, or multisite configurations run closer to three to five months.

What makes migrations harder

Some Drupal configurations add scope in ways that aren’t obvious from the outside.

Custom modules with complex business logic need equivalents built in Payload or as separate services. Webforms with conditional logic and submission workflows are among the most labour-intensive to migrate. Paragraph bundles that have grown through years of incremental additions often need rationalisation before they can be mapped cleanly. Multisite installs require an early decision about whether to consolidate tenants, replicate the structure in a Payload multi-tenant model, or run separate Payload instances.

Integrations specific to higher-ed and government add scope too: student information systems, constituent relationship management tools, single sign-on providers, accessibility scanning pipelines, and translation workflows each have connection points that need re-establishing in the new platform. None of these are blockers, but surfacing them early is the difference between a migration that finishes on time and one that runs over.

The mechanics, field by field

Paragraphs. A paragraph bundle is a reusable structure with its own fields, attached to a node through an entity reference. Payload’s blocks field does the same job, so most bundles move across with their names intact. The work is in rationalising bundles that grew by accretion.

Field types. Text, number, boolean, date and email map directly. Entity references become relationship fields, and link fields become a group holding a URL and a label. Formatted long text needs a decision: the stored HTML converts into Payload’s Lexical format, and entities embedded in it resolve into references rather than staying as markup. This is the least predictable part of the transform.

Media and files. Drupal media entities carry their own fields and behave as entities in their own right. In Payload they become an upload-enabled collection, so alt text, credit and licence travel with the file. Migrate the original, let Payload regenerate the derivatives, leave Drupal’s image styles behind, and map old identifiers to new ones.

Taxonomy. A vocabulary becomes a collection and each term a document inside it, so terms keep their own fields and URLs. Hierarchical vocabularies carry a self-relationship for the parent.

Multilingual. A Drupal entity that is both revisionable and translatable keeps its translations inside the revision: one revision can carry several languages, and the canonical version of a node is the default translation of its default revision. Payload uses localised fields, where one document holds every locale. The transform reads each translation by entity identity and language code, writes it into the matching locale on a single Payload document, and preserves the published state of the revision you selected. What you get out of Drupal depends on the version and the route: core JSON:API negotiates a single language per request and falls back when a translation is missing. If your export produces one record per language and entity, fold those records into that document. Enumerate the translations you need and check the fallback behaviour, so none is silently omitted.

Listings that Views used to build. Drupal documents a view as a listing of content, created and edited through the Views UI module and output as a sortable table, a grid, a block, JSON or an RSS feed. Payload ships no equivalent interface. Listings are written in the front end and read through Payload’s query language, shared across the Local API, the REST API and GraphQL, with operators for equality, comparison, string matching, set membership and existence, and/or logic, sorting and pagination. That moves listing changes into a developer’s queue, so count your editor-built views first.

The redirect map. Path aliases and the accumulated redirect table both have to travel. Export both, build the map before the front end is finished, and keep a legacy identifier on every document so the map survives a model change.

How we approach this

A Drupal move is a CMS replatforming engagement, and when we scope one, we define the content model in writing before any code, in the same document that fixes the price and the delivery date. That document maps content types to Payload collections, specifies field types and relationships, defines access control requirements, and lists what is in and out of scope. A pre-launch milestone gives your team time to validate the build against the acceptance criteria before cutover.

For implementation support, see WAYF’s Payload development team and the projects behind the service. Bring your content-type inventory and access rules to the first discussion.

We hold a top-tier Payload partnership and contribute actively to its open-source. That matters here because accurate scoping on a migration depends on having built the same kinds of structures before: multi-tenant configurations, access control plugins, and field-type mappings that institutions with complex content governance actually need.

Book a call. Bring whatever shape the brief is in: a list of content types, a site audit, or a description of the problem. We’ll tell you whether a migration makes sense and what a reasonable first step looks like.

FAQ

1. How long does a Drupal to Payload migration take?

   Discovery and content model redesign take two to three weeks on most projects, and the build runs four to eight weeks after that. Enterprise migrations with custom module equivalents, heavy integrations or multisite configurations run closer to three to five months.

2. What happens to Paragraphs?

   They become blocks. Payload’s blocks field accepts several named block types, each with its own schema, in an order the editor controls. A paragraph bundle does that same job in Drupal. Most bundles move across with their field names intact.

3. What happens to Drupal field types and media?

   Most map directly: entity references become relationship fields, and link fields become a group holding a URL and a label. Formatted long text is the exception, because the stored HTML becomes Payload’s Lexical format. Media entities become an upload-enabled collection.

4. What replaces Views?

   Nothing in the admin interface. Payload ships no Views equivalent. Listings are written in the front end and read through Payload’s query language, shared across the Local API, the REST API and GraphQL. That moves listing changes into a developer’s queue, so count your editor-built views before committing to a date.

5. How are redirects handled?

   Path aliases and the redirect table both travel. Export them, build the map before the front end is finished, and keep a legacy identifier on every document so the map survives a model change.

6. Who runs the platform after launch?

   You do, if you want to. Payload runs on Node.js and deploys on whatever infrastructure your security and compliance requirements dictate, so no vendor holds the hosting contract or the data. The core is open source, maintained in public and self-hostable, with no lock-in. Running it can be handed to us separately.

7. What does engaging WAYF look like?

   A consultation that costs nothing, then paid discovery, then a fixed quote. We define the content model in writing before any code, in the same document that fixes the price and the delivery date, and a pre-launch milestone lets your team validate the build before cutover.

Sources

• Drupal 7 has reached end of life
• Drupal core release schedule
• Drupal for Higher Education
• endoflife.date/drupal
• Infonomic: Migrating from Drupal to Payload CMS
• Payload CMS documentation
• WAYF on Payload’s partner directory
• Drupal User Guide, uses of Views
• Drupal API, entity CRUD, editing and view modes
• Drupal JSON:API module, translations
• Payload CMS, querying your documents
• Payload CMS, blocks field