--- title: "Drupal's strategy for 2026: AI everywhere, decisions with people" lang: en type: blog canonical: https://www.arocom.de/en/blog/drupal-strategy-2026 alternate: https://www.arocom.de/blog/drupal-strategie-2026 author: "Axel Roth" published: 2026-07-27 last_updated: 2026-07-29 --- # Drupal's strategy for 2026: AI everywhere, decisions with people Drupal revised its product strategy for Drupal CMS in June 2026, with a target horizon of June 2028. Two points matter for decision makers. First, the strategy makes AI a design principle: every workflow should be operable by AI agents, with humans staying in the process. Second, it names a target range of $30,000 to $120,000 in total budget per project, which explicitly addresses mid-market organisations reached through their agencies. For companies planning a relaunch this means setup effort should drop, and the budget that frees up moves into content, integrations and accessibility. What remains open is how much of this actually ships by 2028, and who settles the data protection questions around model use. ## Drupal's strategy for 2026: AI everywhere, decisions with people Hardly anyone outside the community reads strategy papers from open-source projects. This one is still worth your time if you will decide on a website or a portal in the next two years. It is about a market decision, and that decision affects your budget. I read the strategy with two questions in mind. What attitude towards AI sits behind it? And what project size is being built for here? Both answers land closer to our own work than I expected. ## What the strategy actually says The [product strategy for Drupal CMS](https://www.drupal.org/about/initiatives/cms/strategy-2026) carries version number 2.0 and dates from June 2026. It replaces the first strategy from August 2024, and the target date is June 2028. So a project reset its course after two years, towards AI. The document states the target picture like this: "Drupal CMS is the gold standard for turning great ideas into great digital experiences with the speed of AI." Two priorities sit underneath. The first is time to production, which should drop significantly. The second is winning back the middle of the market, meaning the projects that went to WordPress, Webflow or HubSpot over the past years. Who the strategy addresses is interesting. As users it names agencies and professional developers. As the actual addressees it names "mid-market organizations or single departments within enterprise, which we will reach via the digital agencies or developers that work with them". So Drupal is speaking to mid-sized companies and going through their service providers. ## The sentence that matters The AI stance of the document sits in a single sentence: "Every workflow and process in Drupal CMS can be operated by AI agents, while keeping humans in the loop." It contains two claims. The first: no step of work is off limits for automation. The second: people stay in the process, as a planned instance and not as an emergency brake. Most systems deliver only one of the two halves. Without approval you get an autopilot that nobody watches after a few weeks, and without automation that runs all the way through, little changes in the editorial team's day. Our guiding principle [Human Centered. AI First.](https://www.arocom.de/en/blog/human-centered-ai-first) has described the same tension for years, in almost the same words. That a community project with thousands of contributors lands on the same formulation strikes me as a good sign: the stance holds up outside our own projects too. ## Why this pattern looks familiar to us AI has been running on exactly this pattern in our Drupal projects for some time. The AI writes into a draft field, never straight into the published one. Meta descriptions, alt texts and raw translations are generated automatically, and the editorial team accepts, corrects or discards them. How that is built technically is described in our post on [AI content workflows in Drupal](https://www.arocom.de/en/blog/drupal-ai-content-workflows). This was not us anticipating a strategy. We ended up with the pattern because the alternatives did not hold up in operation. Full automation without approval produces mistakes that only surface weeks later. A chat window next to the [editorial system](https://www.arocom.de/en/knowledge/drupal/editorial-system) goes unused after the second week. We see both in client projects; we have no study on it. ## $30,000 to $120,000: the range means you The strategy gets most concrete at one number. Agencies should once again be able to deliver projects with "total budgets (including design, development, hosting, and maintenance) between $30,000 to $120,000 USD". At the exchange rate in late July 2026 that is roughly 26,000 to 105,000 euros, hosting and maintenance included. This is precisely the range where Drupal lost ground in recent years. The reason was rarely the feature set. Too much of it had to be set up first. In our own cost estimates, basic setup, meaning configuration and fundamental decisions before the first piece of content, regularly accounted for a quarter to a third of the effort. On a 250,000 euro project that barely registers, at 60,000 it decides between winning the work and losing it. The initiatives named all target that effort: site templates as a ready starting point, a marketplace for finding extensions, automatic updates against the maintenance load. If that works out, the budget shifts to where it has an effect, meaning the content model, interfaces to your systems and accessibility. What already distinguishes Drupal CMS from Drupal Core today is explained in our knowledge article on [Drupal CMS](https://www.arocom.de/en/knowledge/drupal/drupal-cms). ![Site template selection in the Drupal CMS installation wizard](https://www.arocom.de/images/blog/drupal-cms-site-templates-en.webp) *The template picker in the installer. This is exactly where setup effort is meant to drop. (Source: own installation, Drupal CMS 2.1.3, July 2026)* The screenshot shows the step in question. After installation a choice of ready starting points is waiting, with design and basic features included. The template descriptions, incidentally, are still untranslated even when the interface language is not English. That fits the state of the strategy overall: the direction is set, the execution is still being worked on. ## What the strategy does not solve A strategy paper describes intentions. What has shipped so far is the Drupal CMS 2 line, released in January 2026 and now at 2.1. Everything the strategy describes beyond that is spread across two years. Plan with what is installable today and treat the rest as a welcome addition. On data protection, close reading pays off. The strategy promises that AI features work with various language models and give users "control over their AI engine, cost, and data handling". What is meant is freedom of choice over model, cost and data processing. GDPR compliance of your setup does not follow from it. Which model you connect, where it runs and whether a data processing agreement is in place remains your decision. What the EU AI Act additionally requires is summarised in a [separate post](https://www.arocom.de/en/blog/eu-ai-act-smes). On raw prototyping speed, Drupal will not win anyway. The document itself draws a line against vibe-coding tools such as Lovable or Bolt. For a clickable flow in two hours, those tools are the better choice. Once it has to become a system with editorial processes, permissions and multilingual content, the question this strategy sets out to answer is back. | What is announced | What you get from it | What you still have to settle | | --- | --- | --- | | Agents for every workflow, humans in the process | Less manual work in the editorial team | Who approves, and how that person spots an error | | Site templates as a starting point | Shorter setup, fewer fundamental questions | Whether your content model fits a template | | Marketplace for extensions | Faster discovery instead of module research | Origin and maintenance state of each extension | | Free choice of model | Control over cost and data processing | Data processing agreement, server location, purpose limitation | | Automatic updates | Lower maintenance load | Test coverage so an update does not break things | ### Should we postpone our relaunch until the strategy is implemented? No. The target horizon is June 2028, which means two years with an outdated website. Drupal CMS 2.1 is production-ready today. According to the release notes, Drupal CMS is a starting point for new sites. After that you run a normal Drupal installation, and the strategy's future building blocks reach you as modules and recipes. Waiting only pays off for a project that has no budget before 2027 anyway. ### Does the strategy change our CMS decision? It changes the argument in one band, namely projects between roughly 26,000 and 105,000 euros in total budget. Drupal was often too setup-heavy there. Above that band it was always a plausible choice, below it a website builder is frequently the better fit. What remains decisive are your requirements for multilingual content, permissions, interfaces and accessibility. ### Do we need our own AI infrastructure for this? In most cases, no. Free choice of model means you decide on a model. You do not have to operate one. For typical editorial tasks a provider with a data processing agreement and European processing location is enough. Running your own model only pays off when your data classification forces it. ## The concrete next step Take half an hour and look at your current editorial system, whichever it is. Write down the recurring tasks your editorial team handles every week without making an editorial decision. Meta information, alt texts, teaser variants and raw translations are the usual candidates. Then add a second column next to each task: who would approve the result? That list is what the Drupal strategy wants to automate within two years. Most of it can already be built today. If you want to know which items would pay off first in your case, our [future check](https://www.arocom.de/en/future-check) is the right way in.