Drupal's content model survives the move

Technology

Drupal is the enterprise end of the open source CMS world: a real entity and field system, granular permissions, and multilingual support that was designed in rather than bolted on. It asks for a specialist team in exchange, and that team is the expensive part of running it.

When a Drupal site comes up for replacement, the content model is usually the easiest part of the move and the site's behavior is the hardest. Core ships JSON:API, so decoupling the front end before replacing the back end is a real option, and often the cheaper first step.

Monogram logo

Structure

What survives a move off Drupal, and what does not

  1. The content model usually maps cleanly

    Drupal made you declare structure up front. Entities, bundles, fields, and taxonomy terms are already close to the shape a headless schema wants, so mapping them into Sanity or Contentful is a translation job. That is the opposite of a WordPress export, where the structure has to be recovered first.

  2. Views and hooks do not come with you

    The behavior of a Drupal site lives outside the content: listing logic in Views, access and display rules in PHP hooks and preprocess functions, much of it configured rather than written. None of that exports. It gets rebuilt as queries and components, and it is rarely documented anywhere.

  3. Every major upgrade waits on the module list

    A major version lands when the contributed modules you depend on are ready, not when the core release ships. That dependency is the recurring bill, and it is the reason most Drupal estates we are asked about are two versions behind. Our own published work does not include a Drupal build.