Drupal: Where It Fits and What It Costs

Start with the publishing work

Drupal is worth considering when the difficult part of a website is managing its content: who can change it, how it gets approved, how translations relate, and where it appears. A new frontend framework does not remove that work.

I spent five years at Acquia as a Senior Technical Architect, working on enterprise Drupal platforms. That background makes me interested in the editorial and operational details behind a CMS choice. A fast demo is useful. I also want to see what happens when an editor corrects a published page, a reviewer rejects a revision, or an integration stops responding.

This is the basis of my view of Drupal. It can be a good fit for complex publishing requirements, provided the team accounts for the cost of configuring, extending, and maintaining it.

Model the content editors maintain

Imagine a university website with departments, courses, staff profiles, and several languages. A course appears on its own page, in a department listing, and in search. Editors should be able to correct its title once and have the correction appear everywhere.

Drupal's content types, fields, entity references, and taxonomy provide a way to represent those relationships. The important design work is deciding what deserves its own record, what can be reused, and which relationships editors need to manage. Start there before building page templates.

Too little structure leaves editors copying text between pages. Too much structure turns a short update into a tour of several forms. Test the model with actual editing tasks. If changing a course date requires an engineer, the model or the editing interface needs work.

You also do not need a custom entity for every business concept. Try a content type and fields first. Custom code adds a maintenance obligation, so it should solve a requirement that the existing model cannot express cleanly.

Test the editorial workflow

Requirements such as “supports approvals” hide important details. Can an author revise a published page while the current version stays live? Can a regional editor approve only their region's content? What happens when a translation is ready before the source revision?

Work through those cases using the roles the organization will actually have. A demonstration performed as an administrator tells you very little about the editor's experience. Include rejection, correction, and unpublishing in the test, rather than stopping after the first successful publication.

Drupal has tools for revisions, permissions, and translation. Its Content Moderation module (opens in a new tab) supports publishing states beyond published and unpublished. The finished workflow still needs design. Decide which states and transitions serve an actual approval requirement. Adding more states can create confusion without improving control.

Account for the work a separate frontend adds

Drupal's core JSON:API module (opens in a new tab) exposes content through an API tied to Drupal's entity, field, access, and caching systems. GraphQL is available through a contributed module (opens in a new tab). The distinction matters when assessing dependencies and maintenance.

A separate frontend can make sense for an application with substantial interaction or content shared with a mobile client. It also means your team must connect preview, routing, authentication, redirects, and cache invalidation across systems. Those features do not arrive just because an API returns the right JSON.

Consider a correction to a course title. Drupal can serve the new value while a prebuilt frontend page still displays the old one. You need a defined update path and a way to recover when that path fails. Draft preview needs separate handling so unpublished content stays limited to authorized reviewers.

If the site is primarily content pages and forms, I would first evaluate Drupal's own rendering with JavaScript added where needed. Decoupling should buy enough to justify another application to build, deploy, and support. It does not guarantee faster pages; measure the pages your users will actually load.

Treat configuration as part of the release

Drupal distinguishes content from configuration. Content types, field definitions, and Views settings are examples of configuration; the articles and records using them are content. Drupal's configuration management documentation (opens in a new tab) describes how to move those settings between environments.

This lets a team review a field or workflow change alongside the code that depends on it. It does not mean importing configuration moves production content, or that every change is safe to reverse. Removing a field needs a plan for its existing data.

Rehearse releases against representative content and permissions. Check what happens when an environment already has an unexpected configuration change. Keep credentials and environment-specific settings out of shared exports, and decide how deployment will supply them.

Multiple sites add another choice. Sharing code can reduce duplicated maintenance, but a common release can affect every site using it. Sharing code does not require sharing one database or one editorial workflow. Make those decisions separately, based on isolation and release requirements.

Design for failed integrations

A CMS may need to notify a CRM, search index, or other publishing system when content changes. Avoid making the editor wait on every remote service during a save. A queued update can let the editorial action finish while delivery happens separately.

The queue still needs a worker, retries, and visibility into failures. Suppose the remote service accepts an update but the worker loses the response. Retrying must not create a duplicate record. Use a stable identifier and define how the receiving system handles repeated updates.

Decide what a job represents, too. Sending the latest version when the worker runs is different from sending the exact revision that triggered the job. Either can be appropriate. The choice matters when several edits arrive before the queue catches up.

These details belong in the architecture estimate. Installing an integration module may save work, but someone still owns its behavior when credentials expire, requests time out, or the remote schema changes.

Run a useful proof of concept

I would evaluate Drupal with one representative content type and the hardest everyday publishing task. Build the editing form, permissions, approval flow, preview, and final page. Connect one real integration if it is central to the project. Ask editors to use it without a developer narrating every step.

Then change something: add a field, revise the approval rule, or update the content after publication. Deploy that change to another environment. This reveals more about the cost of ownership than a polished homepage on its own.

Drupal becomes a stronger candidate when these tasks make good use of its content and editorial systems. For a small publishing site with simple permissions, that machinery may be more than the team needs. The decision should follow the work you have demonstrated and the people available to maintain it.