In recent months, a number of Acquia customers have independently made the same strategic decision: to migrate hundreds of websites from WordPress and other platforms to Drupal.
Some of these sites will move to Acquia Cloud, while others will move to Acquia Source. Drupal CMS played an important role in these decisions by making Drupal more approachable for marketers and site builders.
Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.
A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.
Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.
Organizations are under pressure to move faster and reduce costs. CMS fragmentation makes both harder by creating recurring duplication. Integrations, security practices, governance policies, design systems, and technical expertise must all be developed and maintained across multiple platforms.
Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.
This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.
A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.
Each decision can make sense for the individual project while creating significant duplication across the organization.
More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.
Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.
Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.
But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.
That is where Acquia Source and Acquia Cloud fit together.
Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.
Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.
Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.
A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.
I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.
When organizations standardize this way, the economics change dramatically. We have helped some customers save tens of millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.
The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.
The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.
Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.
One CMS foundation with multiple operating models makes that possible.
Visual page builders often arrive with a familiar promise: fewer developer handoffs and more control for editors. Drupal CMS 2.0 makes that promise concrete by using Drupal Canvas as its default editing experience, with drag-and-drop composition, live previews, and editing directly on the page. The change does not remove front-end development. It moves the unit of work from the individual page towards reusable components and the rules surrounding them.
Single-Directory Components make those rules visible in code. Part of Drupal core's render system since Drupal 10.3, a component can keep its Twig template, metadata, CSS, JavaScript, and related assets together. Props define structured inputs, slots create controlled areas for nested content, and schemas can restrict the values a component accepts. Drupal's SDC quickstart describes these inputs as an application programming interface, or contract, for the component.
Consider a featured article card. Developers can encode its semantic markup, heading structure, image treatment, responsive behaviour, accessibility requirements, spacing, and permitted visual variants. Editors can choose the article, label, image, and approved presentation without adding arbitrary classes or rebuilding the markup. The editor gains useful control because the developer has already decided where flexibility is safe.
Recent Drupal publications make this division of labour clearer. In the 4 December 2025 blog post "Drupal Canvas 1.0 Released," Drupal founder Dries Buytaert described reusable components that match a team's design system. His 23 October 2025 State of Drupal recap presented visual page building for end users alongside component work for front-end developers, while Drupal.org's 24 March 2026 post "Drupal at 25: Built to Last. Ready for What's Next." said Canvas can speed page creation without sacrificing structured content. The pattern is clear: visual tools redistribute development work rather than make technical expertise unnecessary.
Canvas also extends component development beyond traditional Twig-based theming. Its code components contain JavaScript and CSS, can receive page data and custom inputs, and can be created in the browser or maintained in a local codebase. They render through Preact with a React compatibility layer. For teams that need source control, shared files, static assets, or package dependencies, the local workflow supports development outside the Canvas interface and synchronisation with the Drupal site.
Greater component power creates a governance question. A schema can restrict the values a component accepts, but the development team must still decide which choices are meaningful, who owns the component, and how changes will affect pages already using it. Too many exposed options can weaken the design system, while too few can recreate the bottlenecks that visual building is meant to reduce. Reusable components should therefore be reviewed as public interfaces, with clear defaults, accessibility checks, documented variations, and predictable behaviour.
Existing custom themes do not need to adopt this model in one large rewrite. Teams can begin with repeated elements such as cards, teasers, calls to action, and heroes, then move their inputs into documented props and their flexible regions into deliberate slots. Components can be tested within the theme before mature and stable choices are exposed through Drupal Canvas. The future Drupal developer may assemble fewer pages directly, but will carry more responsibility for building the platform on which those pages can be assembled safely.
Chris Kelly links the board candidacy to a question now facing Drupal: how the project can make installation and upgrades easier without weakening security, independence, or open-source safeguards.
Michael Kinnunen and Steve Wirt share how they each got started with Drupal through higher-ed jobs and stayed for the communit. They compare those community values to FIRST Robotics, explaining FIRST's K-12 programs (FRC, FTC, and FIRST LEGO League), kickoff-style challenges, and the "coopertition" culture where teams help competitors with parts and repairs. Both mentor highschool robotics teams in the US.
Drupal Developer for CivicActions by day, FIRST Robotics mentor by night Steve has been a Drupal Developer for 19 years and helps government agencies build tools that help improve their mission. He is founding mentor of FRC team Compass Robotics.
Michael Kinnunen
Backend Engineer for CivicActions Michael has been working with Drupal for about a decade, starting with Drupal 7 in 2016 as a Web Developer at Northern Michigan University. He has also spent the past six years as a mentor for the Negaunee Minerbotics FRC team, where he has helped students build technical skills in programming and engineering.
Drupal is not named in the HTML First paper, but the argument lands close to home. It gives Drupal teams a useful test for deciding when server rendering, Twig, components, and JavaScript should each carry the frontend load.
LocalGov Drupal is a Drupal distribution that combines Drupal, some configuration, and a collection of modules with the aim of making it easier for councils to create websites. The functionality provided includes content pages, news pages, bus timetables, and waste collection systems. What's more, it's maintained by a vibrant community of people.
The LocalGov Drupal Waste Collection module is a module that allows local bin collection schedules to be displayed to users. This uses a combination of an address lookup and collection data to show users the bins collection schedule for that address for the next few months.
A plugin interface is used to allow different banks of data to be used in the bank end of the module, with CSV and Whitespace API integration coming with the module. Whitespace is a company used across the UK to manage waste collection systems and the Whitespace plugin interfaces with a SOAP API to pull bin collection data into the site.
I've been using the Waste Collection module for a little while now with a few different projects. Whilst the information that the module provides is good, I needed to alter this data in a recent project with Central Bedfordshire. This required the use of a hook to alter the Whitespace plugin class and output more customised waste collection schedules.
In this article I will go through the issue I needed to correct, and how I altered the data coming out of the Whitespace API without creating a new plugin.
The Problem
When you set up Whitespace integration using this module it pulls a set of service names, which is essentially a list of the types of collections that can happen. This will be things like "Refuse (black bin)" or "Recycling" and shows residents what sort of bin they need to put out for collection on that day.
I've read recently about making SDCs dependent on Drupal Canvas because of needing to reference Canvas in the definition of your prop, so the right media widget is used inside Canvas:
image:
$ref: json-schema-definitions://canvas.module/image
type: object
title: Image
description: >
Image of the singer
examples:
- src: 'micro.webp'
alt: 'Nice picture of the singer'
width: 200
height: 300
That was the case during the alphas. But was fixed long ago, even before the 1.0.0 release. See canvas#3515074.
image:
type: object
title: Image
required: [src]
properties:
src:
type: string
format: uri-reference
contentMediaType: "image/*"
x-allowed-schemes: [http, https] # this is image-uri, itself a nested $ref
alt: { type: string }
width: { type: integer }
height: { type: integer }
description: >
Image of the singer
examples:
- src: 'micro.webp'
alt: 'Nice picture of the singer'
width: 200
height: 300
That's more verbose, but would make your SDC Canvas-independent and re-usable, and it's 100% equivalent.
If we missed updating some docs, please create an issue on the Canvas issue queue.
At Josefinas, every pair of shoes is handmade in Portugal after the order is placed. There is no warehouse full of finished stock: a customer buys, and an atelier starts working. For years, the bridge between "order paid" and "order shipped" was a shared spreadsheet. It listed what had to be produced, who was making it, and when it might be ready. It also lived completely outside the store: no link to the actual orders, no states, no history, and no way to know where time was being lost.
We replaced that spreadsheet with a Drupal module. It has now been running Josefinas' production for months, and today we are releasing it to the community: Commerce Make-to-Order is available on drupal.org, with a stable 1.0.0 release.
What it does
Commerce Make-to-Order adds a production layer to Drupal Commerce. Make-to-order (also written made-to-order, or build-to-order) means producing items only after a customer order is received, instead of keeping pre-made inventory. When an order reaches a state you configure (for example, paid), the module creates one MTO order per order item: a production order the team tracks from queue to completion.
Each MTO order runs a State Machine workflow designed for real ateliers: Draft, Queued, Waiting for Materials, In Production, Quality Check, Rework, Completed, Canceled. QC failures do not silently loop back into production: they move to a dedicated Rework state and back through Quality Check, so first-pass rate and rework are measurable instead of invisible.
Around that core there is everything a production team needs day to day:
Production order numbers via Commerce Number Pattern (MTO-2026-00042)
Assignment to team members, priorities, and due dates with overdue highlighting
Estimated completion dates, calculated automatically from a per-type setting
Internal notes, transition notes, and team notes with optional email notification
An activity log timeline and a full state history with per-state timing
A production analytics dashboard: bottlenecks, team performance, materials wait analysis, QC metrics, on-time delivery
Closing the loop with the store
The interesting part is what happens when production finishes. The module offers two integration modes with the parent Commerce order:
State sync: when all MTO orders of a Commerce order complete, the order transitions directly (for example, Processing to Shipped).
Shipment integration: with Commerce Shipping, MTO orders link to the checkout shipment, and when the last one completes the order is promoted to a "ready to ship" state. The shipping team adds tracking, splits shipments if needed, and ships.
Automation has one important limit, learned in production: hold states. Some order states represent a deliberate human decision, like a customer asking not to ship yet. You can configure which states automatic promotion must never override; the module logs a note on the order instead and lets a person decide.
Battle-tested, then released
This is not a v1 built in the abstract. The module has managed hundreds of real production orders at Josefinas before its first public release. Publishing it meant generalizing what was site-specific (hold states became per-type configuration, integrations became optional), adding its own test coverage against Drupal Commerce's core workflows, and cleaning everything to drupal.org standards.
It also plays well with the rest of our contrib work: with Commerce Order Amend, amending a placed order keeps production orders in sync with the changed items.
Requires Drupal 10 or 11, Commerce 2.x or 3.x, and State Machine. Commerce Shipping is optional, for the shipment integration mode.
If you run a store where things are made after they are sold (furniture, fashion, print on demand, anything artisanal) we would love to hear how it fits your workflow. The issue queue is open.
All security issues have been migrated from the older security.drupal.org site to our GitLab instance at git.drupalcode.org. This is the latest in a series of steps to improve Drupal's coordinated vulnerability disclosure tools. We hope this will help in a few ways:
Merge requests for security issues will get automated testing to increase the quality of the releases. (Previously, tests for core security issues had to be triggered manually, and contrib testing was not available.)
GitLab has more automation to help with advisory creation, reducing manual work.
Powerful features like labels, commenting, and thread reviews on merge requests are now possible for security issues as well.
Here are some of the key steps we took:
We started by evaluating a few solutions. We decided to use the GitLab instance on drupalcode.org.
We planned how to remap and improve the current features from security.drupal.org and added some labels and automation to private issues on drupalcode.org.
We made new security issue reporting default to git.drupalcode.org for several months. This helped us could gain confidence in the system, fix bugs, and make improvements.
While that happened, Neil Drumm worked to create the migration process.
The migration finally ran from July 9th to July 12th.
This work is possible because of support from the Drupal Association and is very appreciated.
We suppressed most emails during the migration, but a small number of people did get extra notification emails about issues, including old issues. We apologize for any resulting confusion.
How do I use GitLab to submit and manage security issues?
As before, security reports should be submitted by clicking the "Report a security vulnerability" link on the project page. If a project has already migrated public issues to git.drupalcode.org, you may also mark an issue confidential as you open it. The Security Team triages confidential issues for all covered projects.
For more information about how Drupal.org's GitLab instance works, read our documentation.
Let us know your thoughts. If you have feedback about how to further improve the Security Team process, you can file them in the Security Team Queue. If you have issues to report about the GitLab tooling itself on git.drupalcode.org, you can file them in the Drupal.org queue.
The old site does a redirect to the new location for issues and members of the Security Team can get content out of it if anyone notices items missing from the migration.
Panel access simplifies procurement but does not authorise a deployment. Agencies still need to review the assessment scope, findings, and residual risk against their intended use.
The Drupal Association is changing CEOs, and the community reacted with the intensity it usually reserves for controversy. Jürgen, who sent the DA a formal four-page letter of concern in May, makes the case for constructive engagement over outrage. Leadership means disappointing half the room on almost every decision - disagree with choices without turning decision-makers into enemies. The practical call to action is the 2026 board election. Become a member now to earn the right to vote. If you are already a member, vote. Show up on the quiet days, not only when the alarm goes off. A transition is rare - a moment where the direction is genuinely open.
Official Drupal 7 support ended on January 5, 2025 - yet many organizations still run sites on it in 2026. The real question is no longer "should we update?" but what platform you want for the next 5-10 years.
A practical decision guide: rebuild on Drupal 11 or Drupal CMS, migrate content, switch CMS, go static, or buy time with extended support - plus a prep checklist for pricing and board-ready options.
For regulated Drupal projects, choosing a cloud region settles only the easiest part of the sovereignty question. Access, key custody, operations, recovery, and exit planning determine whether the hosting claim holds.
Darren Oh links his board candidacy to a question now facing Drupal: how the project can expand adoption without adding friction for maintainers, smaller projects, and new users.
