Migrating from Drupal to Payload: a practical guide for higher-ed and government teams
Drupal 7 ended January 2025. Drupal 10 ends December 2026. For institutions now facing another migration decision, here's what moving to Payload actually involves, and how to decide whether it's the right call.
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.
Upgrading from D10 to D11 is more manageable than the D7-to-D10 step was. Modules written for Drupal 10 typically need compatibility updates rather than rewrites. 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 around Drupal’s architecture rather than with it: 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.
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.
How we approach this
When we scope a Drupal migration, 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.
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.
Sources
We're booking content platform
engagements for 2026.
Twenty-five minutes to walk through the work and decide if we're the right team for it. Scoping and a fixed price come after.