What your team gets when the site becomes a Drupal CMS
CTOs, heads of digital, and content operations leads
A Drupal CMS for content teams changes who can change the website. This is what lands on day one after a replatform with X to Drupal, where the work goes, and what it does not cover.
The short version
- Your editors compose pages from typed components and publish without a developer or a deployment.
- Drupal 11 and Drupal CMS ship media, scheduling, permissions and SEO foundations configured, so a large part of the site arrives finished.
- The delivered site installs on a fresh Drupal 11 as a Recipe, in one step, so the whole thing is reproducible.
- The transcription work moves into the harness run, so the project's time goes to the judgement calls. The section below says where the work goes.
- Drupal's AI layer arrives configured against your own provider keys, with generated alternative text and metadata drafted per content type.
- The machine-readable surfaces for LLMs arrive with it, and the media library arrives already holding your images rather than empty.
- Deeper AI authoring and a deeper automated SEO audit are the two things still in build, and we label them that way.
The pixels are what stakeholders look at when a replatform lands. What decides whether the project was worth doing is what your team can do on the Monday after.
So this post covers the after. What changes for the people who own the words, what arrives already built, where the work actually goes, and where the boundaries are.
What changes on day one for your content team?
Editors get to change the site.
That sounds like the lowest possible bar and it is the thing most migrated sites fail at. On a site with a real content model, an editor opens a page and sees its sections as a list they can reorder, edit and add to. Each section has typed fields with the right widget: a text field for a heading, an image upload for an image, a link field for a call to action, a repeatable group for list rows.
The practical effect shows up in the requests that stop arriving. A campaign page for next week's webinar gets built on Tuesday afternoon by the person running the campaign. Swapping a hero image takes a minute. Reordering a homepage does not need a release.
The second change is that listings look after themselves. Any list of content on your site becomes a Drupal View: your insights listing, your case studies, the related-articles block, the "latest from the team" strip on a landing page. Publish an article and it appears in all of them, in the right order, filtered correctly, with the right card layout. Nobody maintains a list of links.
The third change is governance. Roles, permissions and scheduled publishing are platform features. An editor writes the piece, schedules it, and it goes live at 9am on Thursday. That is configuration doing the job a process document used to do badly. A review step before anything publishes can be added as part of a custom scope.
What arrives already built?
More than most people expect, and this is the part that has changed most in Drupal over the last few years.
A current Drupal install starts close to finished. The site we deliver comes with these working and configured:
| Capability | What you get |
|---|---|
| Scheduling | Scheduled publishing on every content type |
| Media management | A media library with focal-point cropping, image styles, responsive images, remote video |
| SEO foundations | Metadata management, XML sitemaps, clean URL patterns, redirects |
| Structured data | Organisation, website, web page, article and service markup emitted as JSON-LD from the content model |
| AI in the CMS | The AI module suite wired to your own provider keys, with assistive authoring, generated alternative text and metadata drafted per content type |
| Forms | A full form builder with spam protection, so marketing builds its own forms |
| Admin experience | A modern admin theme with a dashboard and quick navigation |
| Performance | Page and render caching with an object cache behind them, WebP conversion, focal-point cropping |
| Privacy | Consent management for cookies and embeds |
| Permissions | Role-based access down to individual fields |
| Security | An enforcing content security policy, strict transport security carried over where your current site already sends it, and an editor role that is not an administrator role |
None of that is bespoke work on your project. It is the ecosystem, configured. The practical significance is straightforward: capabilities that used to be separate pieces of project work are now setup steps.
Where does the work actually go?
I am going to describe this without putting a number on it.
That is a deliberate choice. How it plays out depends on your content library, your template count, and how much of the current site survives review, so any single figure I gave you would travel further than it deserves and be wrong for most readers. What I can describe precisely is where the work goes.
A replatform breaks into four buckets of work: re-implementing the design, deriving the content model, moving the content, and everything else. Three of those four are transcription. The information already exists in the current site and a person is retyping it into a new system with high standards. That is where the hours sit, and that is the part X to Drupal removes.
What stays is the work that needs a person: deciding whether the current information architecture is still right, handling the integrations, planning the redirect map and the cutover, quality assurance, and the judgement calls about content that looks editorial and is actually mechanism.
So the shape of the change is that a project stops being mostly transcription with some judgement, and becomes mostly judgement. The other effect worth naming: the senior architect whose time was going into modelling a site that already exists gets to spend it on what you are building next.
How does SEO come out of a move like this?
A platform move is the moment SEO risk concentrates, so it gets treated as a workstream and not a checkbox.
Three things carry the risk: URLs, metadata and redirects. We keep the URL structure where we can, carry metadata across with the content, and put a redirect map in place for anything that has to change. Drupal covers all three natively: path patterns, metadata management per content type, and a redirect module that logs what is being hit.
The delivered site arrives with the SEO foundations already configured: metadata management per content type, XML sitemaps, clean path patterns and redirects. It also emits structured data from the content model, so organisation, website, web page, article and service markup comes out of the fields and stays in step with what a visitor reads. The surfaces an LLM reads arrive with them, which the post on LLM readiness goes into properly. A deeper automated audit is still in build, and the section below is honest about where that has got to.
What is a Recipe and why should you care?
This is the plug-and-play part, and it is the most underrated thing in the delivery.
A Drupal Recipe is a packaged set of configuration and content that applies to a Drupal site in one step. The site we deliver comes as a Recipe, so it installs onto a fresh Drupal 11 with a single command and produces the site: content types, fields, paragraph components, Views, taxonomies, menus, text formats, the theme, and the content.
What that gives you in practice:
Reproducibility. Any developer can stand up the whole site from scratch, today or in two years. There is no undocumented state and no "ask the person who built it".
A clean handover. Whether we keep working with you or your in-house team takes it on, what changes hands is a standard Drupal site with its configuration in version control.
Extension in one step. The wider Recipe ecosystem works the same way, so adding a capability later, an events section, a case-study type, a privacy pack, takes an install.
Getting the Recipe right took real work. A good Recipe holds only what your site needs, so it installs in one step and stays easy to read. That is what ships now.
What ships with the AI layer today?
The suite arrives installed and pointed at your own provider keys, so the capability belongs to your account and your CMS.
What that gives your editors on day one: assistive authoring and content suggestions inside the editor, working on fields with a known purpose; alternative text generated for images that arrived without any; and titles, meta descriptions and social metadata drafted per content type from the content itself, with an editor approving. More than one provider is installed, so you choose which one answers.
Two details behind it are worth a line each. Keys are read from the environment, so they never travel in a configuration export or a database dump. And the layer logs which model was called, for which task and when, while leaving the content of prompts and responses out of the log, which answers a spend question and a privacy question with the same record.
The governance point is the one I would lead with in an internal pitch. An AI-drafted piece goes through the same roles and the same permissions as anything a person wrote, because it is the same content model underneath.
What arrived since this post was written?
This section used to name three capability packs and say all three were roadmap. One of them has shipped, and a few things arrived that were not on the list at all, so it is worth updating rather than quietly leaving stale.
The machine-readable pack now arrives with the site. An llms.txt map, a markdown copy of every page, read-only JSON per content item from Drupal's own API layer, and crawl rules that name the AI agents individually. It is on the site we replatformed, so you can open qed42.com/llms.txt or qed42.com/jsonapi rather than take it on faith. The LLM readiness post covers what each surface does and why the structured data is the foundation they sit on.
The media library arrives holding your images. Every image the site uses is in the library on day one, ready for an editor to find and reuse. On our own site that is 1,334 media items. This is the change your content team notices first.
The image handling is proven before it is relied on. A server can accept an image format and still be unable to produce a cropped copy of it, which fails quietly: the visitor sees the original, nobody sees an error, and the cropping you specified never happens. The delivery now tests that the server can produce what the site asks for, and says so plainly if it cannot.
Editor tooling is served from your own site. An enforcing security policy and an editing widget that loads its code from an outside network are in direct conflict, and the widget loses. Those libraries now come from the site itself, so no admin screen depends on an outside network being reachable.
Verification signs in. The checks used to run as an anonymous visitor, which cannot see a widget that only breaks once you log in. They now cover the admin screens your team will actually use, and every width your design declares rather than a fixed set.
Still in build: deeper AI content authoring past the drafting and suggestions above, meaning expansion at length, summaries, taxonomy suggestions across a whole library and translation help; and a deeper automated SEO audit covering the metadata that came across, sitemap and redirect coverage, structured data and the crawl surface. Both arrive the way the site does, as Drupal Recipes, so adopting one is an install on a site you already have.
On timing I will point you at a conversation. If either matters to your decision, ask us where it has got to, because a date on a blog post ages badly.
Where does this fit best?
It fits well when you have a site that basically works and a team frustrated by how hard it is to change. Content-heavy marketing sites, insight and resource libraries, case-study driven sites, multi-brand setups where the same components repeat.
It fits well when you want to keep the design. A move that holds the design fixed removes a round of stakeholder review and keeps the focus on the model.
It fits less well when you already know the site needs a redesign and a rethink of its information architecture. In that case a move gets you a faithful reproduction of something you were about to change, and starting from the design work is the better sequence. Worth saying plainly, because the honest answer is sometimes "not yet".
It also has boundaries worth knowing about up front. Sites built heavily on scroll-driven animation and video backgrounds are the hardest to reproduce exactly. Content behind authentication, single-page applications and infinite-scroll interfaces need a conversation before anyone quotes anything.
What to ask any vendor doing this
Four questions that separate a platform move from an expensive snapshot. They apply to us too.
- What happens to content published after the migration? If new content does not behave like migrated content, something got hard-coded that should have been modelled.
- Can an editor change this section without a developer? Ask them to open the edit form and show you. This is where a JSON payload in a textarea gets found.
- How many custom modules is the site relying on? The lower the number, the easier your site is for anyone else to maintain. Ours ships at zero.
- Can you rebuild the whole site from scratch, right now? If yes, the configuration is real. If it needs a database somebody is protecting, it is not.
This post is part of the X to Drupal series, alongside the pillar, why replatform into Drupal and what X to Drupal provides, and the companions on fourteen generations of building it, what it taught us about working with AI, moving our own site off Webflow, what makes the delivered site readable to LLMs, and how we check the result really matches.
Frequently asked questions
Can content editors change layouts in Drupal without a developer?
Yes, when the content model is built for it. Editors see each page as an ordered list of components with typed fields and native widgets, so they can reorder sections, add new ones and change content directly. A weak content model takes that freedom away, which is why the modelling decisions matter more than they look.
What is a Drupal Recipe?
A packaged set of configuration and content that applies to a Drupal site in one step. The site we deliver comes as a Recipe, so it installs onto a fresh Drupal 11 with a single command and produces the whole site: content types, fields, components, Views, taxonomies, menus, theme and content.
Where does the work go with this approach?
The transcription work moves into the harness run: re-implementing the design, deriving the content model, and moving content. The judgement work stays with people: whether the information architecture is still right, the integrations, the redirect map and the cutover, and quality assurance.
Do the AI features ship today?
Drupal's AI module suite arrives installed and wired to your own provider keys, with assistive authoring in the editor, alternative text generated for images that arrived without it, and metadata drafted per content type. The machine-readable surfaces an LLM reads arrive configured with it: an llms.txt map, a markdown twin of every page, read-only JSON per content item, and crawl rules naming the AI agents individually. Deeper authoring work such as long-form expansion, summaries and taxonomy suggestions across a library is still in build. For timing on that part, ask us where it has got to.
Does an SEO audit come with the migration?
The SEO foundations arrive configured on the delivered site: metadata per content type, XML sitemaps, path patterns, redirects, and structured data emitted from the content model. The machine-readable surfaces an LLM reads arrive with them, so the site is legible to an assistant on day one. A deeper automated audit covering sitemap coverage and the crawl surface is still in build, so that part is roadmap today.
Who is a good fit for this?
Teams with a content-heavy site that basically works, who are frustrated by how hard it is to change, and who want to keep the current design. Insight libraries, case-study sites and multi-brand setups with repeating components fit especially well.
When is a replatform the wrong move?
When you already know the site needs a redesign and a rethink of its information architecture. Moving first gets you a faithful copy of something you were about to change, so starting from the design work is the better sequence.