Migrating from Drupal to Payload.
We move teams off Drupal and onto Payload, pages, assets, URLs and search rankings intact. Tell us what you're running below and we'll scope the move.
A Drupal to Payload migration starts by cataloguing the existing estate: content types, node counts, fields in active use, fields abandoned over time, custom modules, URL aliases, embedded media, and content that is no longer worth carrying forward. Drupal's node-and-field model does not map directly to Payload collections, so the most consequential work is content model redesign: content types, paragraph bundles, blocks, taxonomy vocabularies, relationships, and active fields all need explicit mapping before any import script moves data.
The extraction itself can use Drush, REST, or JSON:API, but the transformation is where the project concentrates. Custom modules with business logic need equivalents in Payload or separate services. Webforms, multisite structures, permissions, single sign-on, translation workflows, and institutional integrations have to be documented and rebuilt where they remain in scope. If the front end is being decoupled, that build runs alongside the data work, with redirects and pre-launch validation agreed before cutover.
Who runs the migration
We are a Payload partner agency and a top contributor to the project. When something in the platform needs attention, we have direct access to the maintainers.
We have run this kind of move at enterprise scale. We migrated Ingersoll Rand's China sites off Oracle Content Manager in five months, with zero downtime at cutover, and we built the Council of Europe Development Bank's events platform to the deadline of their 70-year anniversary.
The first conversation is a free consultation. Scope, cost, and timing are agreed before any work starts.