DrupalCon Vienna 2025: what we learned (and what changes for you)

We spent four days at DrupalCon Vienna 2025 (October 14-17) attending over twenty technical sessions, workshops, and BOFs. The strongest message? Drupal isn't chasing trends but consolidating technical leadership in three critical areas: enterprise-grade AI with real governance, Canvas as the first "design system native" CMS, and operational maturity for projects at scale. 

This isn't a marketing report but a practical account of what we saw working in production, which problems remain open, and where you should invest attention over the next six months. For Italian teams planning 2026 projects, there are decisions to make now, not later.

October in Vienna has that dry cold that makes everything sharper. Perfect for four days of total immersion in what turned out to be one of the most technically dense DrupalCons in recent years. It wasn't a conference of sensationalist announcements, but of working demos and field-tested solutions, as well as that rare combination of strategic vision and operational pragmatism that distinguishes mature communities from those in the hype phase.

All session videos will soon be available in the official DrupalCon Vienna 2025 playlist.

Dries Buytaert's keynote set the tone: four pillars (Canvas, AI, Orchestration, Site Templates, Marketplace) and a clear statement. AI is a technology that's here to stay, regardless of whether the financial bubble bursts sooner or later. Drupal is one of the best-positioned open-source CMSs to leverage it. No defensiveness, no "we have AI too," but a clear strategic implementation roadmap.

What struck us most? The distance between announcements and reality was minimal. Canvas isn't vaporware: it's in working alpha with agencies already running pilots with real clients. AI isn't a tacked-on chatbot: it's architecture designed for enterprise governance with production-grade observability. Site templates have moved beyond the concept phase: the first ones are already here.

We're organizing this report by thematic areas, not chronologically. What matters isn't "what was said on Tuesday" but "what changes for your 2026 projects."

Canvas: demo vera, risposte vere

Drupal Canvas (the new name for Experience Builder) is Drupal's brand new visual builder that promises to simplify and streamline how we design and build pages in Drupal. We've already discussed it in our article on Drupal CMS 2.0 innovations and in the comprehensive overview of Drupal AI, where we analyzed the architecture and strategic positioning. In Vienna, we saw what it means to bring it to production, and especially where gaps still exist.

The "Drupal Canvas Unleashed" session sold out with over 400 participants. The key message: Canvas combines Single Directory Components (SDC) and blocks as "backend" components, but with Canvas you no longer need to know how they work once they've been developed.

Settings in Canvas are the properties of SDCs, while a left panel controls slots, a new "entity" that allows managing the component tree in layers, potentially nested within each other. Additionally, in the theme configurations there's a setting to let Canvas manage global regions like header and footer, importing them with just a few clicks into every new page. Truly effective and intuitive: anyone familiar with Figma or other visual builders like Framer and Webflow will find themselves in a very familiar environment.

But the most interesting feature? Code Components, which support writing React components directly in the browser. These components can use elements and CSS components defined in Canvas, also support props to add dynamic data (for example, a title). Furthermore, it's also possible to query via JSON:API to build dynamic components that retrieve data from the backend.

What already works:

• Content Templates for defining structured content type layouts (perfect for landing pages)
• Global regions and reusable components
• AI (in beta) that allows building code components directly via prompts
• Views natively supported

Gaps still open:

• Paragraphs and layouts are still work in progress
• Some contrib modules that only work on nodes aren't compatible
• Some contrib field types don't work yet
• Multilingual isn't fully supported
• Server-side rendering isn't implemented (blocked by security implications, support isn't guaranteed for all server providers)
• APIs to extend Canvas (not just in terms of module integration, but also embedded web apps in Canvas) and offer truly rich user experiences
• Standard permissions system (e.g., to create new components or use existing ones)

The "Strategies for Integrating Drupal Canvas in Your Existing Platform" session provided practical guidance. Canvas creates a new "canvas pages" content type, so modules that only work on nodes might have compatibility issues. Canvas is a React app on the frontend, compilation and rendering in the editor happen in the browser in real time.

For frontend developers, the "JavaScript Frontend Development with Drupal Canvas: Beyond Decoupling" session showed advanced workflows. It's possible to develop external JS components and sync them with dedicated utilities. There's a bidirectional workflow to move from Drupal to Storybook and vice versa. Canvas supports adding global CSS for preview. Each component passes data to Drupal, the component is rendered with nuxt client-side, and external components are standard Vue components.

Practical takeaway: If you're planning Drupal projects for Q1-Q2 2026, Canvas will be production-ready (stable release November 2025, default in Drupal CMS 2.0 from January 2026). In the budget, it will become essential to account for component library development time, rather than individual page implementation. The ROI is immediate for teams with high page creation volume.

Native design system: finally a CMS that understands design

The "Drupal, the first design-system native CMS" session by Pierre Dureau (Beyris) presented a paradigm shift that deserves attention.

Indeed, in Drupal themes present significant historical problems: they're not shareable (a theme is for a specific project), they're not plug-and-play (there's always a missing template), they have unfriendly DX.

The proposed solution: business agnostic coding. Like the backend, the frontend must be decoupled from business through plugins—that is, a design must be conceived independently of business and brand. This is where well-structured design systems come in, enabling a major strength: "one design, many products."

And Drupal is an ecosystem that particularly effectively leverages a design system, as a structured, organized, and well-described design is one that Drupal can easily understand and use (we also discussed this in our recent Design System and Drupal CMS article).

Very interestingly, the talk introduces a method that proposes an inversion of the traditional Drupal workflow (site builder / backend dev → templates → frontend dev). Instead, now it's the frontend developer who provides modular frontend plugins, and this also implies ownership for the frontend developer and YAML as the primary working tool.

More than a mere stylistic exercise, supporting this method and this shift are concrete features already available directly in Drupal core:

• breakpoints.yml for breakpoint images
• layouts.yml for layout grid system (layouts in Layout Builder)
• SDC for UI components
• icons.yml for icon packs

Certainly, feature coverage is still quite limited. However, coming in Drupal 11.3 and 11.4 will be important new design-dedicated API endpoints that will significantly raise the bar and further separate theming from the Drupal app:

• Styles API with Utilities & Helpers (set of mutually exclusive, self-descriptive, single-purpose, and universal HTML attributes like Typography, Borders, Colors, Spacing, Elevation) and Themes & Modes (predefined branding switch, color scheme, accessibility settings)
• Design Tokens API with scoped values available for local or global overrides, which become CSS variables only at runtime

Despite several gaps remaining, this talk emphasizes an ambitious but achievable goal for the first time in Drupal's history: the possibility of a fully automatable design workflow, from the design phase in Figma to final rendering in the browser.

But it wasn't the only talk focused on the winning Design System + Drupal pair. Truly remarkable is the session on Nestlé's scalable multi-brand design system, which showed a real implementation. This case study discussed reorganization and design system design on three levels: core, ui components, brand overrides.

This structure proved fundamental both for managing the complexity of dozens of different brands and for giving overall coherence to the brand ecosystem. The Drupal theming system based on starterkit ensured rapid deployments, efficient updates, and the ability to instantiate new sites in days instead of weeks. Now, over 100 sites developed in Drupal adopt this approach.

Practical takeaway: If you're building or rethinking your design system, consider a "design system first" approach instead of "Drupal theme first." The initial investment is higher but scalability and maintainability are orders of magnitude better. For multi-brand organizations, it's practically mandatory.

Digital accessibility: EAA and AI

One of the main advantages of a design system is optimization and consistency of user experience. But today, the design system is also a strategic tool for complying with the European Accessibility Act. Two talks addressed the accessibility theme, and in particular the "AI in EAA" session explored how AI can support compliance with accessibility standards, increasingly critical with the EAA in effect since June 2025.

AI can accelerate QA teams (automated crawling), content editors (summaries, automatic alt-text, intelligent text editors), designers (color and contrast analysis, object recognition, ARIA property and state suggestions), and developers (linting tools, IDE extensions, autocomplete to create accessible components) in catching accessibility issues.

However, it cannot replace genuine human testing. Even in this area, it's essential to mitigate the risks of over-reliance on AI, maintaining human oversight to overcome limitations and biases of automated tools, such as cultural and linguistic peculiarities, cultural sensitivity, linguistic particularities, and misinterpretations of context.

Fundamental in any case is understanding accessibility issues, no longer an accessory element, but both an obligation and a business opportunity. We've explored the topic in two key resources: the whitepaper Accessibility and Design System and the operational accessibility checklist.

Practical takeaway: For many organizations, accessibility isn't yet a clear priority. Automated tools and AI can offer significant support, but education on requirements, internal training, and communication are indispensable pillars. To truly be compliant and truly embed accessibility into the company DNA requires an approach that integrates accessibility from the design phase: a "design-to-code" method that combines technical interventions, training, and culture, which only a specialized partner can orchestrate.

Enterprise AI: governance first

We've already written an in-depth article on Drupal AI analyzing features like content generation, context management, autonomous agents, and observability. In Vienna, we saw concrete implementations and discovered patterns that work (and some that don't).

The "The AI Agent Swarm has come to Drupal Canvas" session showed practical integrations. Canvas template agent can build entire landing pages by assembling components, and the AI beta configured in Canvas allows building code components via prompts (some settings are preconfigured to accelerate adoption, but everything is customizable).

The session also explored how agents can be used everywhere in Drupal for small or large tasks, even building sites from scratch with external tools via MCP (Model Context Protocol), all without writing a line of code.

For effective LLM use, "context is king." In our previous article, we examined the ability to define context for specific actions callable through Field Widget Actions. This system was still quite cumbersome and embryonic.

A nice leap forward in this regard is represented by the Context Control Center, which allows centrally defining all context information, such as your brand, persona, and topic (much like what happens in Claude Code or Copilot through claude.md or agents.md files, but directly in the Drupal UI).

Furthermore, centralization of contexts enables decidedly more effective governance. The various contexts are then easily callable and usable by different Drupal AI features and agents. If you want to delve deeper into Context Engineering, we refer you to the very interesting talk by Enrico Zimuel during our GenAI-focused event.

Pattern that works. AI for content generation with human supervision for approval (Human in the Loop): AI creates a draft, a person reviews and approves before publication. This approach resolves the trade-off between speed and control, and aligns with Drupal's philosophy where AI empowers people, not replaces them.

Pattern that doesn't work well yet: Full automation without human supervision. Even with a well-configured Context Control Center, AI can generate content that technically respects guidelines but has wrong nuances that only a human can catch. Full automation therefore risks not aligning with brand quality level, and human supervision is strongly recommended.

Practical takeaway: Invest in AI to accelerate execution (drafting, research, assembly), not to replace strategic decision-making. The Context Control Center is the key differentiator: without centralized governance, enterprise AI scales poorly and introduces risks. Budget time for robust initial Context Control Center configuration, don't think it's "plug and play."

DevOps and Release Management: lessons from the field

Some of the most practically valuable sessions were on DevOps, CI/CD, and release management: topics that truly make the difference between projects that scale and projects that collapse.

GitHub Actions + Docker + Cypress = CI/CD Nirvana

The talk describes an ideal configuration (the "CI/CD Nirvana") for the development process: tools for local development that automate QA (grumPHP), visual regression testing (BackstopJS), e2e testing (Cypress), and security audits. These same tools must also be used in CI to ensure safe code release without regressions.

On GitHub, this is possible with GitHub Actions. Ideally, write your own custom Actions, customized for the specific use case. This way, the obtained advantages are evident: you avoid using Docker images with unnecessary software, you can insert specific tools (e.g., debug), you have full control of what gets deployed.

But it's imperative to pay close attention to security implications. GitHub Actions can also act on production code and therefore access must be limited, ssh keys must be kept secret, close attention must be paid to third-party Actions and database dumps. As always, it's essential to schedule regular code audits and reviews.

Mastering the Release Flow: 5 years of continuous improvement

Very instructive case study that includes a Drupal instance distributing content to 5 React apps, 20 connected external services, 40 countries with up to 3 languages each (multilingual was absolutely essential in this project), 13,000 test steps distributed across 700 Behat feature files.

The tests in particular followed a very rigorous approach: they were structured in adherence to identified user journeys, separating production and non-production tests, core functionality and country-specific, running every night. The goal? Identify bugs and anomalies before users (and the client).

Despite the meticulousness, some emerging problems made it evident that it still wasn't sufficient. In particular, the problems encountered by the team were:

• Behat is no longer actively developed
• The Mink extension had a critical bug for the latest Chrome versions for a long time (not fixed for 3 months)
• Nightly tests on AWS now lasted more than 8 hours

To overcome these limitations, the team created a new framework called Cuppet that combines Cucumber (to avoid rewriting tests) and Puppeteer (actively maintained by Google), based on NodeJS.

Our takeaways from this case study?

• If it's "painful," automate it or solve it
• Operational excellence is not optional
• Make it work → make it right → make it fast (in this order; in this case study, the process lasted a full 5 years of iterative improvements)
• Reliability is more important than new features (address technical debt)
• Being a "good person" is more important than technical skills, even more so in a world where everyone interacts with AI, but where developers and end users are always people.

This last point emerged in several sessions. The keynote "Neurodiversity: An Underrated Superpower in Business" opened the second day with discussion on neurodiversity and how peculiar capabilities of people often set aside can bring valuable contributions to teams and organizations.

Testing in the AI Era

The "Test All the Things" session emphasized that with AI generating more and more code, testing takes on even greater importance. LLMs make coding accessible to everyone, even those without prior skills, developing a false sense of security. Growing reliance on these tools increases the probability of defects or unexpected behaviors that are difficult to identify.

Very interesting is the overview of different testing approaches in different environments, for example:

• Running tests in an environment that replicates production ensures high fidelity, but it's a complex process, with privacy implications and long times, especially with large databases
• Installing a site with test content is instead much faster and manageable, ideal for more agile development and verification cycles, necessarily at the expense of production environment fidelity

Static code analysis (PHPStan, psalm) is a valid tool for preventing bugs and keeping overall code quality under control. The workflow described in the talk is very similar to what we adopt at SparkFabrik, thus confirming its quality, with the difference that this year we adopted Symfony Panther for behavioral tests, replacing Behat. Also interesting is the mention of Pa11y for accessibility analysis, an often underestimated tool but of great support for ensuring standards compliance and inclusive experiences.

Practical takeaway: If you're adopting AI for code generation, invest proportionally more in test automation and static analysis. AI-generated code often works but has unexpected edge cases that only robust tests will catch.

Security by Design: from requirement to culture

At SparkFabrik, security is particularly close to our hearts. Beyond being a regulatory requirement for many companies, security is fundamental for protecting data, user trust, and companies' online reputation.

The "Secure by Design: Integrating Security into Drupal Development" session presented a valid overview on the "secure by design" approach, with theoretical and practical guidance on strategies to implement to ensure security of sites and portals developed in Drupal, from business requirements to technical implementations.

The starting assumption: Security must be understood as a core business requirement, not as an "afterthought."

And in Drupal, this assumption is taken very seriously, with a dedicated Security team that regularly publishes security advisories. In October 2023, the Security by Design Initiative in the Drupal community also launched, supported by the U.S. Cybersecurity and Infrastructure Security Agency, along with international partners, including European states like Germany and the UK.

The talk shares practical guidance (also very technical and specific), including:

• Implement security from the requirements phase
• Periodic code review with security focus
• Automated security scanning in CI/CD
• Regular penetration testing for critical projects
• Security training for the entire team (not just developers)

Also worth mentioning is the "Better Debugging with Xdebug" session, which presented advanced debugging features, including experimental features like "control sockets" for debugging running processes, and the concept of "time traveling" to "go back in the execution process."

If you want to delve deeper into security topics, check out our articles on security and compliance with Drupal CMS, on Software Security, Cloud Security, DevSecOps and on the impact of NIS2 and DORA in Cloud Native (we also created a complete operational guide).

Practical takeaway: For enterprise projects, it's important to budget specific time and resources for security activities (threat modeling, security testing, security reviews), ideally a budget of 10-15% of total time. It may seem like a lot, but it's a minimal fraction of the cost of a security incident.

Marketplace and Site Templates: real economics

Ryan Szrama from Centarro presented "How to Sell Drupal Site Templates" with rare honesty.

First, what is a site template? It's a combination of Drupal CMS, frontend theme, possibly also a backend theme, recipes that provide functionality, and predefined content that, together, create a Drupal installation tailored for a specific purpose and allow quickly starting a new project. Think for example of a Template for SaaS companies, or an ecommerce site: use cases with specific needs that can be packaged.

Commerce Kickstart is precisely one of the first available Site Templates. From Drupal distribution, it was converted into a site template, enriched with recipes for eCommerce, with modern checkout experience, various configuration options, and installation simplification.

The appeal of Site Templates is quite clear: provide a specific solution to a specific problem. Even from a sales perspective, it should be a "better" sales strategy, or at least more immediate and direct, compared to a project idea, an "abstract solution." This is where the most interesting and pragmatic points of the talk emerge: the critical points and the experience so far.

Three are the most critical points:

• In practice, how and where to publish a site template? Currently, there's no centralized marketplace on drupal.org yet, there's no transaction management system, and not even file distribution. For templates to take off, it's fundamental to find an operational answer, avoiding having to manage purchases manually and individually.
• How to protect intellectual property when distributing the entire product as code? Very hot topic, and here too there's no clear answer.
• But the priority point is: how to convince a real client to buy a Site Template? The focus is on this point, testing sales in the field. The value proposition being leveraged is monetary and time savings for the end client, accepting however the trade-off of lack of customization ("off the shelf" product). Important disclaimer, at the current state, no sale has been completed yet (prospects weren't clear what they were buying and requests veered toward coaching needs, customization, dedicated services).

For Site Template sales to be sustainable, three things are therefore fundamental: a way to distribute them effectively, and clear communication about what the package includes.

In this regard, the "Decision-making at Scale: Drupal Marketplace Process Behind the Scene" session showed how a committee of 12 people handled deciding whether Drupal should create a marketplace for site templates (a process that lasted 14 weeks). The answer is positive, with a gradual release.

On the official page of the Drupal Marketplace Initiative, the overall plan on Site Templates and Drupal Marketplace is detailed:

• by DrupalCon Vienna, a pilot with the simple release of 1-2 templates;
• by DrupalCon Chicago (March 2026), release of an MVP of the Marketplace, with 10-15 templates, both free and paid;
• initially, Site Template Makers will be limited to some selected Drupal Certified Partners, then progressively expand to other makers;
• for paid templates, requirements of transparent pricing, guaranteed maintenance, clear support terms must be met;
• the MVP will include experiments in terms of pricing models and revenue division;
• it's hypothesized that initially 10% of revenues will go to the Drupal Association;
• in future iterations, the marketplace will directly manage transactions and revenue division could change to 60% to the creator, 30% to DA, 10% to a fund supporting the ecosystem.

Practical takeaway: The marketplace will officially launch in the coming months, and will evolve gradually but quickly. For agencies, consider developing vertical site templates (e-commerce, non-profit, education) for your target market, as soon as possible (and prepare to sell it as a product, not as a solution). The economic model is still emerging but the timing is ideal for early movers.

Orchestration e Architetture Composable

The "From CMS to Platform: How to Build Future-Proof Digital Ecosystems with Drupal" session presented an important vision. When a client asks for a website, in reality the request often hides the need for a complete digital ecosystem, composed of websites, applications, integrations with third-party systems for specific services.

In the Drupal Core Strategy published in July, Dries explicitly defined Drupal as a "platform" because talking about CMS is now limiting. Drupal has potential to serve as the heart of a digital platform for various touchpoints.

This talk also presented an example, a project based on NodeHive, but the basic architecture can be generalized for any platform that leverages Drupal as a single headless backend, with an Orchestration layer that allows managing various touchpoints.

As we discussed in our article on composable architecture, this approach is increasingly relevant for organizations that need to serve experiences across web, mobile apps, digital signage, voice assistants, and more, simultaneously and consistently.

Finally, in terms of workflow orchestration, an important new feature is Drupal's support for no-code/low-code automation tools such as Activepieces (an open-source orchestration platform licensed under MIT). This was announced during Driesnote and discussed in detail in Dries' dedicated article.

Practical takeaway: Don't think "Drupal site" anymore but "Drupal as content hub." Architect from the start for multi-channel content delivery. The initial cost is slightly higher but future flexibility is incomparably greater.

Managing scope change: the art of saying NO without saying NO

Beyond technical talks, the "Navigating Scope Creep" session was particularly appreciated by project managers. Indeed, it addressed a universal theme in software projects: scope creep, the uncontrolled expansion of requirements, features, and deliverables of a project beyond what was initially approved.

Typically, scope creep manifests during certain phases: requirements gathering, client feedback, near project completion (last-minute changes are particularly risky), and when stakeholders change (for example, new team members, who can bring new ideas).

The main causes? Unclear objectives or requirements, inadequate communication, desire to avoid conflict (probably the most common problem), but also constantly evolving regulatory and market frameworks.

The talk proposes a clear approach: accept scope change, but do it effectively. The approach is based on three pillars:

1. Awareness: it's fundamental to know the project in detail, monitor stakeholder behavior and the change request process.
2. Alignment: from the early phases, create a shared vision of objectives, align priorities, discuss expectations, formalize scope documentation.
3. Clear processes: implement clear Change Management processes, don't accept verbal requests, document requests and decisions, set clear limits.
4. Avoid misunderstandings: Communicate openly and transparently (even expressing your disagreement, with motivation), involve the client in testing, explain using wireframes and prototypes.

Cherry on top: four concrete tactics were shared in conclusion.

• The alternative offer: we can work on the new request, but we'll need to adjust the timeline and budget.
• Priority shift: adding the request means removing something else from the backlog, what should we deprioritize?
• Future release: let's plan this addition for phase two, after completing core features.
• Data-driven approach: based on our analysis, this addition would bring little value, especially compared to development cost (if you have statistics against a feature, bring them to the table).

Practical takeaway: Invest in formalizing the Change Management Process from kickoff. It seems like an initial cost, but it prevents hours (or weeks) of rework and tensions with stakeholders. Use tools like AI notetaker for automatic meeting notes that become "single source of truth" shared by everyone.

Real Talk: Drupal vs Storyblok

Another session was a breath of fresh air: "Why We Left Drupal, Tried Storyblok, and What Happened Next". An agency attempted the switch from Drupal to Storyblok, driven by the desire to diversify tools and this alternative CMS's massive marketing. In short? The new solution didn't measure up.

The main frustration was the absence of basic features almost taken for granted in Drupal, like building modules, complexity in managing URLs and redirects, configuration management (and related versioning) in Git. The team essentially found itself in the position of having to innovate autonomously to replicate basic features already available in Drupal ("We literally rebuilt Drupal's Configuration Management for Storyblok").

No less important, the limited tech stack. The team had chosen Storyblok + Next.js, given their expertise, but Storyblok was optimized for Vue.js. As a result, the agency had to build workarounds autonomously, even to leverage features of the new Next.js version released during the project.

Features aside, Storyblok's support itself didn't meet expectations, with non-timely responses and unclear guidance that caused significant delays. You can't even rely on the community, being extremely small and poorly engaged. Essentially, every problem requires a custom solution.

The discovery: A technology like Storyblok can be useful in very specific contexts, but for enterprise solutions, Drupal continues to represent a high standard. Solid, tested over 20+ years of community work, with proven solutions we risk taking for granted, forgetting not all CMSs have them.

A memorable tagline: "Product before marketing." This resonates with the general theme of the conference. Drupal isn't doing aggressive marketing but is consolidating its positioning as an excellent product in critical areas that truly matter for business. As we discussed in our CMS comparison, Drupal excels where complexity, governance, and longevity are primary requirements.

Practical takeaway: If you're evaluating alternative CMSs, look beyond feature lists on paper and shiny UI. Ask hard questions: how do you handle multi-brand? How do you manage configurations and versioning? How do you ensure granular access control? How do you migrate when you'll inevitably need to? How is the support and community around the ecosystem? Drupal has proven answers, alternatives often have promises.

Performance: HTTP/3 and network-level optimizations

As evident from the title "TCP Fast Open and HTTP/3: Network-Level Optimizations for Lightning-Fast Drupal", this was an interesting examination of how the HTTP/3 and TCP stack works and its performance-level optimizations. That is, how to save precious milliseconds with the right configurations, and attention to possible attack vectors.

According to shared data, among the top 1000 sites, 60% support HTTP/3, of which 85% via CDN (Cloudflare, Fastly, etc.) and 15% directly. For Drupal specifically, Drupal.org, Acquia Cloud, and Platform.sh/Upsun support HTTP/3.

A technical talk, but the key message is clear: It's time to enable HTTP/3.

Practical takeaway: If you haven't enabled HTTP/3 yet, now is the time. Performance gains are significant and measurable, especially for mobile connections and applications requiring low latency. Check with your hosting provider if it's available (Acquia, Platform.sh, Pantheon all support it).

Conclusion: concrete action items for your projects

Four days in Vienna confirmed a thesis: Drupal is going through a moment of profound technical renewal without losing the enterprise reliability that characterizes it. This is a rare and valuable combination.

For Italian teams planning 2026 projects, here are concrete action items to consider carefully.

If you're planning a new Drupal project:

• Budget Canvas as authoring layer (stable in November 2025, default in January 2026)
• Architect for design system first, not for Drupal theme first
• Include AI Readiness Assessment in the project discovery phase (introducing AI features like Context Control Center requires planning)
• Plan for composable architecture even if starting with a single touchpoint

If you have Drupal in production:

• Review CI/CD pipelines to include automated security scanning
• Evaluate a pilot with Canvas, limiting yourself to one section of the site (not full migration immediately)
• Check compliance for accessibility in view of new EAA requirements (but also as a new opportunity)
• Verify HTTP/3 support

If you're an agency or system integrator:

• Consider developing vertical site templates for your target market, as soon as possible (and prepare to sell it as a product, not as a solution)
• Invest in design systems, reusable and consistent across projects
• Evaluate partnerships to integrate AI solutions and features into your offering

If you have an in-house team:

• Propose a Canvas pilot, to facilitate future creation of high volumes of pages and content
• If you need content generation, experiment and define business cases to set up in the Context Control Center
• Do a review of your change management process (reduce scope creep problem, it costs more than the formalization process)
• Plan intensive training on the new stack of features and tools (Canvas, AI tools, design system approach)

The feeling leaving Vienna? Drupal made architectural choices in 2015 (structured content, API-first, rigorous configuration management) that at the time seemed overkill. In 2025, those choices are proving winning. They're exactly the infrastructure needed for enterprise-grade AI, visual page building without sacrificing governance, and scalable composable architecture.

As Dries said in the keynote: "AI is the storm, but it's also the way through it." Drupal isn't avoiding the storm. It's navigating better than anyone else.

At SparkFabrik, we combine deep technical expertise in Drupal with advanced skills in AI integration, composable architectures, and enterprise governance. Our Drupal development services cover the entire spectrum: from strategic consulting on the AI readiness of your current architecture, to implementation of custom AI-powered solutions, through to security, ongoing support, and optimization.

If your organization is considering adopting AI for its digital initiatives, we invite you to:

1. Explore our case studies of enterprise Drupal implementations
2. Contact our team for an assessment of your specific needs
3. Discover how our suite of Drupal services can support your AI strategy

This article is part of our series dedicated to Drupal CMS. To explore other aspects of the platform, we invite you to consult our previous articles on features and benefits, comparison with alternatives, migration strategies, security and compliance, composable architecture, Design System, Drupal headless omnichannel, and overview and news of Drupal AI.