Press Preview on a Fully Decoupled Drupal site, and Consumer Node Preview 1.0.0-rc1 shows the unsaved page in the frontend your readers will see: the title you just changed and the text you just rewrote, rendered by the site that will publish them.
Drupal's own Preview renders the node in Drupal's theme, not your frontend, so editors save a draft to check it. Next.js draft mode smooths that workaround, but still needs a saved revision. Consumer Node Preview works on what's still in the edit form, for the person writing it, before anything is saved.
Anything that reads JSON:API can be on the other end. Druxt Node Preview 0.1.0 is the Nuxt one, already running druxtjs.org's previews.
The Migrate Drupal module, which is required for migrating Drupal 6 and 7 sites, will be removed from Drupal core in the next major release, Drupal 12. Also removed is the Migrate Drupal UI module, which provides a basic user interface for running a migration. Both of these modules will not be moved to a contributed project, as is often done for removed extensions.
This means that legacy Drupal sites will not be able to migrate directly to Drupal 12 and later. Legacy sites should migrate to Drupal 11 and then upgrade to Drupal 12.
This was decided in [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL and also discussed in Future of migrate in core in a post Drupal 7 world.
Decreasing need for Migrate DrupalThe decision to remove the Migrate Drupal module is driven by several factors:
A strategic track for Drupal is modernization and we want all Drupal sites to enjoy the benefits of Drupal 11 and beyond.
Setting a clear deadline for sites to use Migrate Drupal in core may help some sites schedule the work without delay.
The percentage of Drupal sites using Drupal 6 or 7 continues to decline.
Sites can migrate to a supported release of Drupal up to 3 years after the end of life for Drupal 7 and 12 years after the end of life for Drupal 6. This is because Drupal 11 will be supported until mid to late 2028.
After 2028, it will still be possible to migrate to Drupal 11 in a development environment, then update to Drupal 12 (or beyond) prior to launching a site.
Following from the above, Migrate Drupal will not become a contributed project
Migrate Drupal is coupled to many core extensions and it is technically difficult to move all the code to a single module. Moving the code to a single module is a required step in moving a core extension to a contributed project. That task would require a fair amount of contributor and committer time. Instead, we prefer to encourage that time and effort is spent on improving the Migrate API itself.
RecommendationDrupal 6 and Drupal 7 sites should complete migrations to Drupal 11 by mid 2028.
In Rotterdam, Dries asked the community to talk louder about Drupal. The response so far: 264 pieces of advocacy from nearly 150 people, in at least seven languages, on everything from Reddit threads to a major Italian daily. I spent the past week reviewing all of it, and I'm feeling incredibly optimistic about what this program can unlock.
This month's Insider leads with the full wrap-up: the numbers, the credit matrix we built along the way, and fifteen people whose work shows what the program is for. If you've been waiting to see whether the Advocacy Program is real before joining in, consider this your evidence.
Thanks for reading, and for telling Drupal's story.
Ryan Witcombe, Director, Product Marketing
The Advocacy Program by the numbersAt DrupalCon Rotterdam, Dries asked the community to talk louder about Drupal, and the Drupal Association launched the Advocacy Program to back it. The idea is simple: tell Drupal's story in your own voice, and earn contribution credits through the same system that recognizes code.
One month in, 264 pieces of advocacy have gone through review from nearly 150 contributors: blog posts, videos, conference talks, podcast episodes, Reddit replies, and press coverage, in at least seven languages. Around 2,400 contribution credits are now going out through Drupal.org.
The pattern we hoped for showed up in the data. Social posts made up more than half the volume but under a fifth of the credits, and the biggest scores went to work that travels furthest:
Read the Month 1 wrap-up for the numbers, the credit matrix, and the fifteen people and pieces we're spotlighting this month.
Want in? Anything public that shows what Drupal can do counts, and anything you've published in 2026 is eligible. Submit it through the form or in Drupal Slack, in the #promote-drupal channel. A Month 1 leaderboard is on the way, and the Drupal 12 launch in December will be the next theme.
In the Open with Tiffany FarrissIn the Open is a weekly series from Drupal Association Interim CEO Tiffany Farriss, sharing what she is hearing across the Drupal community and where the Association is headed. The first episode is out, and new episodes will be published each week. Subscribe to the Drupal Association YouTube channel to follow along. With thanks to Stephen Cross of Second Signal Media for producing the series.
A busy month for the engineering teamOctober's biggest engineering news came from upstream. On October 21, PHP released fixes for two critical remote code execution vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that affect every PHP application, Drupal included. We had been preparing, so when PHP moved the release up a day, we hardened Drupal.org's production sites hours before the fixes were public. We then briefly took Drupal.org offline to patch. For the full story, read the incident recap.
The same day, GitLab released a fix for a critical (CVSS 10.0) vulnerability, and we had git.drupalcode.org upgrading within minutes, before GitLab had even published the severity. We've also been sharing mitigation and audit guidance with Drupal Certified Partners and hosting partners. Thank you to our engineering team and our infrastructure partners at Tag1 for the late nights and early mornings, and to the community for your patience.
The regular work didn't stop:
Three ways to get involved:
DrupalCon Rotterdam is over, and we would like to thank everyone who attended, contributed, and supported the event. It was fantastic to bring the Drupal community together for another inspiring edition.
Now it's time to look ahead to 2027. DrupalCon Europe is heading to Edinburgh, a city with a rich history, creative spirit, and thriving culture of innovation, and a fitting setting for the community to connect, share knowledge, and shape what comes next. Save the date: 25 to 28 October 2027.
Drupal AI InitiativeDrupal AI 1.5: what it means for digital marketing leaders. Drupal AI 1.5 is out, built by 63 contributors from 31 organizations around the world. A new post from the Drupal AI Initiative explains what the release means for digital marketing leaders. Conversational assistants can remember context across a browsing session and draw on your own site content, streaming guardrails filter output token by token, and editorial copilots help editors refine copy and draft image alt text. Semantic search ranks results by intent, and you can choose your own AI provider. Read the post.
AI Inside Drupal Essentials course debuts in November. The official Drupal AI Initiative training program is now open for registration. The first live, online session begins November 9, with more sessions starting in January 2027. Created by Mike Anello (ultimike), a seasoned Drupal developer and trainer, AI Inside Drupal Essentials is an 18-hour curriculum delivered in 3-hour sessions on Mondays, Wednesdays, and Fridays over two weeks. Participants get a 100+ page course guide, DrupalEasy's weekly office hours, all class recordings, and the AIDE Slack channel. The course fee is $600. Register for AIDE training.
Adapted from the Drupal Association’s monthly newsletter, the DA Insider. "The work that just happens" spotlights the behind-the-scenes effort required to keep Drupal’s infrastructure, programs, and community moving forward.
Subscribe | Browse the series | Support the work
AI helped adapt the newsletter for the web, and Drupal Association staff reviewed and edited it.
Composer 2.11 can hold back new releases for a cooldown period, counted from when the registry first saw them. LakeDrops now applies a one-day cooldown to its Drupal projects without changing a single composer.json or lock file: one central policy file, merged in memory by a plugin every project already has. Jürgen walks through why the policy couldn't live in composer.json, a Docker image or an environment variable, why drupal/* packages wait too, and why one week was too long. Three LakeDrops additions fill the gaps: lock trust prevents downgrades, a guard stops moves from stable to dev, and a fast lane lets fixes for Drupal Security Team advisories through early. Side stories: a release that was three years old on day one, a spell checker that reordered the rollout, and a composer outdated edge case reported upstream.
When an enterprise web platform reaches a certain scale, the standard advice for handling architectural debt (freeze feature development, spin up a fresh site, and migrate) stops being an option. At Tag1 Consulting, we maintain the e-learning infrastructure behind two of the largest labor organizations in the United States: the American Federation of Teachers (AFT) and the American Federation of Labor and Congress of Industrial Organizations, AFL-CIO.
Share My Lesson (SML) is AFT's resource hub. It has more than two million registered educators who collaborate on classroom materials and participate in on-demand professional development webinars. Meanwhile, on dedicated platforms like AFT eLearning and the AFL-CIO's LaborLab, union members and stewards across the country complete leadership tracks, health and safety courses, and workplace training.
These platforms carry years of member training records, completion histories, and certificate logs. They also place very different technical demands on the stack: Share My Lesson needed e-learning added to a large existing content repository, while the union portals needed deep, multi-tenant course structures.
By late 2022, the ground beneath us was giving way. Our underlying system, built on the legacy Opigno LMS distribution, was buckling under years of accumulated technical debt.
This is the technical story of how we pulled 100,000 lines of legacy code out of contrib, extracted a decoupled navigation engine over 18 months, survived a major Group module entity overhaul, ran a dual-engine hybrid repository, and ultimately built the open source Drupal LMS module.
If you'd rather watch the presentation, the DrupalCon Rotterdam session includes the audience Q&A. Watch my DrupalCon Rotterdam session. > The Breaking Point: How Distributions Become TrapsWhen Tag1 started this e-learning project in 2017, adopting Opigno's early Drupal 8 alpha seemed like a sensible place to start. It gave us ready-made entities for courses, modules, and activities. Crucially, it anchored class memberships on the new Group module (1.0-RC at the time).
We're grateful to Opigno for pioneering e-learning in Drupal. It proved that Drupal's entity system could model a school curriculum. But as Drupal matured through versions 8, 9, and 10, the monolithic distribution architecture began working against us.
In Drupal 7, full-stack distributions were the gold standard. In modern Drupal, they can easily become an architectural straitjacket. Because Opigno was a distribution, it arrived as an all-or-nothing monolith: its own opinionated theme, its own administrative UI, and dozens of deeply interconnected submodules.
When I joined the project in 2021 to help guide the Drupal 8-to-9 upgrade, the cracks were widening. Unused submodules couldn't be disabled without cascading fatal errors. Critical features relied on dangerous runtime anti-patterns, such as serializing raw PHP objects into user dashboard records, which reliably corrupted whenever a module updated. Worst of all, our team was writing high-quality patches to fix infinite recursion and data-loss edge cases, but our fixes sat unreviewed in upstream queues for months, then years. Every upstream release became an event we dreaded, threatening to overwrite our hotfixes or introduce new regressions.
The dealbreaker came when AFT wanted to bring online learning directly to Share My Lesson (SML).
SML was already a high-traffic Drupal site with its own custom theme, established content types, and over 2 million registered educators. You cannot install a distribution on top of an existing Drupal database. We didn't need an entire operating system; we needed a composable module.
Every hour spent rebasing patches and fighting upstream distribution baggage was an hour that could have been spent on extending educational features. Our clients deserved better, and that required a change of course.
Step 1: Taking Ownership (Un-Vendoring 100,000 Lines of Code)The first step of rebuilding mid-flight didn't feel like brilliant architecture. It felt terrifying.
On September 14, 2022, my colleague Nat Catchpole did the fork. He went into composer.json, removed the constraints for opigno_learning_path and opigno_module, and copied 665 files and over 100,000 lines of code directly from web/modules/contrib/ into web/modules/custom/.
Committing 100,000 lines of someone else's procedural legacy code to your own custom folder goes against every instinct you have as an open source engineer. But it transformed our day-to-day work and gave us hope for a cleaner environment.
Suddenly, we were no longer passive consumers waiting on an upstream release cycle that wasn't responding. We were done maintaining a fragile, multi-layered stack of Composer patches. Within 48 hours of that commit, I was deep inside the navigation internals (LpSteps.php), hunting down and fixing recursive nesting bugs and FALSE->id() fatal errors that had haunted our student completion callbacks for months.
Step 2: Extracting the Engine into TrainingManagerOnce the code lived in web/modules/custom/, the real surgery began.
In the legacy distribution, course navigation, access gatekeeping, and scoring calculations were scattered across the codebase. Some logic was trapped inside Form API submit handlers; some lived in controller redirects; some was buried in procedural helper functions inside .module files. If a client asked to change how passing grades were calculated or requested a "no-fail" revisit mode, I had to hunt through half a dozen disconnected files to make sure I didn't break a hidden dependency.
We needed a presentation-agnostic state machine.
In October 2022, Nat planted the seed: he committed a tiny, 51-line service class called TrainingManager.php with a single query method. Over the next 18 months, across more than 70 targeted commits, I used that file as my anchor.
Whenever I touched a legacy feature, I extracted its business logic from the controllers and forms, refactored it into clean, testable object-oriented PHP, and moved it into TrainingManager. Method by method, commit by commit, I taught the service to manage the entire student lifecycle through five responsibilities:
Progress Tracking: Loading and creating unambiguous status records across courses, lessons, and activities.
Navigation State: Deciding whether a user can advance, whether lesson rules allow backward navigation, and whether jumping ahead is permitted.
Lifecycle Gatekeeping: Initializing and updating lesson attempt records and verifying prerequisite lesson completions.
Scoring and Routing: Calculating weighted scores, evaluating mandatory vs. optional modules, and routing open-text submissions to instructor grading queues.
Maintenance Utilities: Providing administrative methods to recalculate out-of-sync student attempts or safely reset training progress on courses that needed updates.
In the legacy codebase, navigation and tracking had sprawled across nearly 6,000 lines of tangled procedural code between opigno_learning_path.module and opigno_module.module.
Consolidated into a pure service using dependency injection, the same logic took roughly 1,000 lines of clean PHP in the TrainingManager service.
More importantly, our forms and controllers became thin, dumb delegates. They no longer made business decisions; they asked the TrainingManager what should happen next. Because the engine was now decoupled from Drupal's render arrays and Form API, it was inherently headless-ready.
Step 3: Surviving the Group 3.x Entity OverhaulCourses and classes across our stack are built on the Group module. Because Opigno was tightly coupled to early Drupal 8 APIs, our codebase had been pinned to Group 1.0-RC for six years (2018 to 2024). We were running production sites on a release candidate while Drupal core marched from 8 to 10.
When we finally moved to Group 3.x in early 2024, it wasn't a standard dependency bump. Group maintainer Kristiaan Van den Eynde had re-architected the module's internal domain model: the foundational group_content entity type and its configuration entity (group_content_type) were deprecated and replaced by group_relationship and group_relationship_type.
This wasn't a cosmetic rename of a few methods; it was a seismic shift that touched our live database:
Physical Database Migrations: On live databases holding years of student history, primary MySQL tables (group_content and group_content_field_data) had to move to group_relationship tables without orphaning or dropping a single active membership.
Query and Storage Sweeps: We had to rewrite every query, storage handler call, and entity hook (hook_group_content_*) across our stack that targeted the old entity type.
Broken Views: Dozens of student gradebooks, course catalogs, and administrative rosters lost their relationship joins overnight when the underlying base tables changed, requiring systematic reconfiguration across multiple affiliate sites.
Nat and I survived this live schema migration in two intensive sweeps across dozens of commits. It was grueling work, but shedding six years of technical debt paid off: native alignment with Drupal core's Access Policy API and VariationCache, which permanently eliminated the database permission bottlenecks that used to slow down the site during concurrent quizzes. Kristiaan also helped every upgrading project, including ours, by providing an update hook so a full migration wasn't needed.
Step 4: The Clean 1.0 Rewrite and the Hybrid StrategyBy spring 2024, our custom refactored code was humming in production. It was time to give this work back to the community.
I created the drupal/lms project on Drupal.org. But as soon as I started writing the public 1.0.x branch, I decided not to carry legacy procedural code into the contrib project. I wanted a clean-room architecture featuring typed plugins, modern PHP attributes (#[ActivityAnswer]), Single Directory Components (SDC), and normalized JSON answer data storage.
This led directly into the classic enterprise trap: How do you build a breaking, clean-room 1.0 release on Drupal.org when learners on your live client platforms are taking exams on the older 0.2.x fork?
You cannot run composer update drupal/lms across a decade of live production data and hope for the best.
In June 2025, we made what I consider our most effective risk-management decision: the hybrid repository strategy.
We permanently froze our working 0.2.x code inside web/modules/custom/lms/. Production users continued logging in, taking mandatory tests, and earning licenses against this battle-tested codebase.
Simultaneously, we required our modern drupal/lms contrib package in web/modules/contrib/lms/.
This gave us the freedom to build the future out in the open. Contributors such as Claudiu Cristea standardized our dependency injection and PHP attributes; Oberon Ray modernized our frontend using Single Directory Components and built rich feedback question plugins; and Nat brought core-level traits and caching rigor.
Both engines lived side by side in the exact same codebase and database. Production never stopped, and the contrib project never took on legacy hacks. All we needed was the bridge to move the data across.
Step 5: The In-Place Data MigrationTo build that bridge, our colleague Mauricio Dinarte wrote lms_migrate, a comprehensive Migrate Plus pipeline.
Instead of setting up a fragile, multi-server ETL (extract, transform, load) process between two databases, we chose to migrate in place and we had all we needed in every site database already. Because the old custom module and the new contrib module ran in parallel within the same Drupal installation, we gained four advantages:
Zero Media and User Overhead: We didn't have to spend weeks migrating user accounts, taxonomy vocabularies, file entities, or media libraries. They were already there.
Calling Runtime APIs Directly: In legacy Opigno, certain student statuses were not stored cleanly on entity tables; they were calculated through procedural helper functions. Because both modules were enabled simultaneously, Mauricio's migration plugins could call our backend PHP APIs directly during the ETL process to extract and normalize historical attempt states.
URL Alias Swapping and 301 Redirects: Teachers had tens of thousands of bookmarked links to specific courses. The migration automatically applied an administrative prefix to legacy Opigno course URLs, reassigned the canonical URL alias directly to the new lms_course entity, and spun up 301 redirects wherever path structures differed.
Pivoting to Revisions Midstream: When we introduced an enterprise course revisioning strategy in Drupal LMS 1.1, the migration pipeline was already halfway built. Because our architecture was modular, Mauricio updated the migration mapping to populate the new revision base fields before the final cutover, preserving complete version auditability.
The generic foundation of this migration pipeline is now available to the entire community at drupal.org/project/lms_migrate.
Architectural Highlights in Drupal LMSBy stripping away the distribution and rebuilding purely on modern Drupal core APIs, we built engineering patterns that I'm proud of.
1. Recursive Modal SubformsEditing a multi-layered course structure, where courses contain lessons and lessons contain activities, often pushes developers toward heavy decoupled JavaScript apps. Opigno took that route with a React based Course Manager and multiple endpoint controllers.
We replaced that entire decoupled frontend with native Drupal Form API and AJAX modal subforms. A subform inside a modal submits to an internal endpoint that validates the data, rebuilds the parent form, and stores the intermediate state in Drupal's form cache. Because requests handle state recursively, there is no nesting limit. You can edit an activity inside a lesson inside a course, and the parent form receives the unified submission tree, with no third-party JavaScript framework. Using Drupal Core entity form API also automatically handles all security, performance and scalability issues that'd be valid in case of a custom solution.
2. Session-Based Entity Storage for Anonymous LearnersPublic education and enterprise demos often require letting anonymous users try a course without registering first.
Traditionally, tracking student progress requires a database row tied to a user ID. We implemented an adaptive entity storage handler for our LessonStatus and Answer entities. If the user is anonymous, the handler stores their progress in their active PHP session. If they register or log in later, the handler can write their attempts to the database. To prevent per-user session states from breaking page caching, action buttons and navigation links use Drupal Core Lazy Builders to remain completely cacheable via BigPipe.
3. Plugin-Driven Bundle Field InstallationIn Drupal LMS, ActivityType is a configuration entity that defines a bundle of the Activity content entity. Each bundle connects to an answer plugin (Multiple Choice, Drag-and-Drop, Free Text with Teacher Evaluation, etc.).
Instead of complex schema update scripts, our plugins declare the fields they need using configuration templates containing bundle placeholders:
# Config template provided by an Answer Plugin id: activity._bundle_placeholder_.field_answer_options field_name: field_answer_options entity_type: activity bundle: '_bundle_placeholder_'When an administrator creates an Activity Type in the UI, the answer plugin automatically installs those fields onto that bundle. Activities remain 100% fieldable, meaning editors can attach custom media and descriptive fields, or style the entire presentation with Layout Builder.
Reversing the Decay CurveLong-lived codebases tend to decay. Patches accumulate, dependencies rot, and projects become fragile places where developers dread touching old code.
By isolating the engine and unbundling the monolith, we reversed that curve:
From 100,000+ lines of fragile procedural code down to ~40,000 lines of clean, object-oriented modern PHP.
From a 4,000-line procedural monster down to a 1,000-line testable TrainingManager service.
From an all-or-nothing distribution down to a composable module that dropped into Share My Lesson and is ready for the Drupal CMS Recipe era.
Rebuilding mid-flight is not easy. It demands patience, defensive Git workflows, and an unwavering commitment to protecting live user data. But by taking ownership of the legacy code, isolating the core business logic first, running hybrid tracks, and migrating in place, you don't have to choose between keeping the lights on and building software you're genuinely proud of.
Drupal LMS is production-ready, stable at 1.2.x, and 100% open source. Check out the project at drupal.org/project/lms, or join us in the #lms channel on Drupal Slack.
From legacy distributions to live-data migrations, Tag1 helps enterprise teams modernize Drupal without taking their sites offline. Explore our Drupal services. >A new Canvas module for the times when team managing the site grows: decide who edits which pages and uses which components.
This is the second post in a three-part series about the impact of the AWS Open Source Credits program on the Drupal community. Part one covered our testing infrastructure. Part three will cover the AI era and what we're exploring next.
When people talk about open source infrastructure, they usually mean git repositories and CI runners, and that's what our first post covered. But Drupal is a 25-year-old project with a global community, and the infrastructure that holds that community together goes well beyond code.
This post is about the rest of it: our translation platform, the contribution credit system, the tools for organizing events, and the community archives that AWS credits help keep online. We build the tools that enable our community to build Drupal, and many of those tools have nothing to do with merge requests.
Translating DrupalLocalize.drupal.org is our community translation platform, where more than 8,500 contributors work across 119 language groups. Together they have recorded nearly 1.8 million translations of more than 1.4 million source strings, across more than 33,000 projects.
Behind those numbers is a crucial pipeline: every time a maintainer ships a release, the platform parses it and extracts the translatable strings automatically. So far it has parsed more than 211,000 releases and scanned more than 15.8 million files. Translators then do the part that needs people: deciding how Drupal should read in their own language. In August, localize.drupal.org was one of the last services we moved off the old hardware at the Oregon State University Open Source Lab and onto AWS. Coming very soon, we'll be deploying an upgrade of localize.drupal.org to modern Drupal, thanks to an important group of community contributors.
Localization is how open source reaches people beyond the English-speaking developer world, and for many contributors, translating Drupal into their own language is the first contribution that leads to a greater contribution journey.
Recognizing the work that doesn't show up in gitDrupal does something rare among major open source projects: we record contribution, including work that isn't code, and credit both the people who do it and the organizations that sponsor them. Documentation, event organizing, mentoring, marketing, and accessibility work can all earn credit in our Contribution Records system, alongside code. In the three years to this September, it recorded more than 217,000 credits for more than 14,000 people.
Most of that credit still goes to code, because code is the easiest work to see, and we're working to change that. This fall we launched the Advocacy Program pilot, which awards credit for work that helps people discover and understand Drupal, and organizations can now see the events they sponsor in their Owner Tools on Drupal.org.
The reason we do this is practical: organizations choosing a Drupal partner can see who contributes, which gives companies a reason to sponsor their people's time, including for work that never touches the codebase. We've written about the limits of any credit system, and we adjust ours as we learn, most recently by raising the weight of core and core security work.
The community's calendar, and its memoryCommunities organize, and organizing takes tooling. We run events.drupal.org for DrupalCon, and the community events calendar on Drupal.org holds the record of more than 1,700 past events going back to 2004, from local meetups to volunteer-run DrupalCamps around the world, with dozens more on the calendar now.
Why we think this matters beyond DrupalMost of the conversation about open source sustainability focuses on paying maintainers, and for good reason. But there is a second gap that gets less attention: infrastructure for everyone around the maintainers, like the translators, event organizers, documentation writers, and the people who mentor new contributors. Many of the people who come to Drupal.org never open a merge request, and they need tools too.
Most projects never build this layer because nobody funds it. Fortunately, cloud credits are a practical way to close this gap: they pay for the servers under the translation platform and the events calendar just as they pay for CI. When AWS supports our infrastructure, it supports the community around the code as well as the code itself.
What's next in this seriesIn our final post: what the AI era is doing to demand on open source infrastructure, where our community's contribution numbers stand today, and how we're thinking about AI tooling for contributors who want it, not only those whose employers pay for it.
The Drupal Association is a 501(c)(3) non-profit. If your organization depends on Drupal, or on the health of open source infrastructure generally, you can support our work.
I've always been a big advocate of Drupal's Migrate API. It's incredibly flexible, allowing developers to pull data from just about anywhere. With contributed modules like Migrate Plus and Migrate Source CSV, that includes CSV files, SQL databases, JSON APIs, and other content management systems.
But migrations can be time-consuming. The process usually looks something like this:
That final step is often the most frustrating. Complex relationships, inconsistent legacy data, and unexpected edge cases can turn migration QA into a lengthy process of trial and error.
Drupal migrations are a particularly good fit for AI-assisted development. There's a lot of structured data to analyze, custom code to write, and repetitive testing to work through. I've found it especially valuable for data discovery, transformations, and QA.
Understanding the source dataBefore writing migration configurations, we often need to spend considerable time understanding the source data, especially when working with unfamiliar databases or legacy content structures.
With a local, container-based development environment, an AI coding assistant can be given controlled access to a copy of the source database. This allows it to inspect tables, write SQL queries, identify patterns, and produce reports without manually investigating every relationship.
Consider rich-text fields in Drupal. They might contain embedded images, media references, links to PDFs, or other files that aren't immediately obvious from the content structure.
On a recent project, we wanted to migrate only media assets that were actually referenced in content. Rather than migrating every file from the legacy system, I used AI to analyze rich-text fields and generate temporary database tables containing unique references to images and documents.
This gave us a clearer picture of which files needed to be migrated and where they were being used.
A prompt might be as straightforward as:
Analyze the rich-text fields in the source database. Identify unique references to images, embedded media, and linked documents. Create a temporary table containing each referenced asset and the source content that uses it. Report any references that cannot be resolved.
Tasks like this previously required writing exploratory SQL, custom scripts, and repeatedly inspecting results. AI can significantly reduce that effort.
Custom transformationsDrupal's migration process plugins are powerful. They allow us to transform incoming data, manipulate values, look up related entities, and handle project-specific requirements.
Core and contributed modules cover many common scenarios, but some migrations require custom process plugins.
Recently, I used AI to help write a custom process plugin that validated existing addresses using Google's Address Validation API.
The site contained approximately 4,500 address entities, many referenced by other content. We suspected there were duplicates and inconsistencies, but determining which addresses could be safely removed wasn't straightforward.
The validation results helped us identify potential duplicates and flag existing address entities for review. This gave us a path toward reducing approximately 4,500 address entities to around 3,000, while accounting for their existing references.
Google's API doesn't perform deduplication. Instead, it gave us more consistent information to inform decisions about which entities should be retained or removed.
This is the kind of improvement I'd considered on previous projects but often couldn't justify because of the development effort involved.
AI makes it much more practical to explore these opportunities. A process plugin that might have required hours of research and development can often be drafted quickly, then reviewed, tested, and refined.
Not every transformation needs to be permanent, reusable code. Some are highly specific to a single migration. That's perfectly fine.
A migration is also an excellent opportunity to improve legacy data rather than simply reproduce its problems in a new system.
Making migration QA more effectiveThis is where I've found some of the biggest benefits.
Traditional migration QA involves reviewing imported content, identifying issues, adjusting migration scripts, and running everything again.
AI can help automate much of that investigative cycle.
For example, after running a migration, I might ask:
Select 10 migrated entities that collectively represent the most important edge cases, including complex field values, media references, and entity relationships. Compare the source and destination data, identify discrepancies, and explain why each example was selected.
An AI coding assistant with access to both databases can inspect records, compare values, and identify inconsistencies that might otherwise take considerable time to uncover.
It can also help investigate failures, propose fixes to migration configurations or process plugins, and rerun targeted migrations for verification.
Of course, reviewing 10 records doesn't prove an entire migration is correct. Automated checks for record counts, missing references, failed imports, and unexpected field values remain important.
But AI makes it easier to develop those checks and identify meaningful samples.
There's a client-facing benefit here, too. Instead of manually searching for representative content to include in a QA handoff, we can generate a curated set of examples covering different content types, relationships, and transformations.
That gives clients a more useful starting point for reviewing migrated content.
Keep developers in controlAI-assisted migrations still require an understanding of Drupal's data structures, the Migrate API, and the intended destination architecture.
Generated migration code needs review. Data transformations should be deterministic and testable. Complex relationships and potentially destructive cleanup operations require particular care.
It's also important to be deliberate about data access. A local container provides a controlled database environment, but that doesn't automatically mean data shared with an AI service stays local. Use approved tools, minimize access, and avoid exposing sensitive production data. The same considerations apply to third-party APIs, including restrictions on storing or reusing their response data.
The goal isn't to let AI independently decide how data should be migrated. It's to give experienced developers a faster way to investigate problems, test solutions, and verify results.
More time for the work that mattersDrupal's Migrate API was already one of my favorite parts of the platform. AI-assisted development makes it even more useful.
What excites me most isn't necessarily generating migration configurations faster. It's the ability to explore source data more thoroughly, tackle transformations that previously seemed too expensive, and make the QA process considerably more efficient.
Migrations will always require careful planning and validation. But spending less time tracking down obscure data issues means more time improving the quality of the migration itself.
Joel SteidlThe owner of a 3D printing workshop could no longer keep up with client requests. Printing took little of that time. Most of it went into retyping an address on the GLS portal, digging through WhatsApp for a measurement sent days earlier, and opening the slicer just to learn how long a print takes. That is the problem the owner brought to me.
I analysed the workshop's workflow, from the client's first message to the delivered parcel, and split it into twelve operations. I started with the ones that repeat on every order and picked a fitting technology for each: a deterministic agent (no AI), an AI agent, or a Mac app.
The owner is left with three operations: designing the part, starting the print and checking the result. That is the craft of the job.
At the center sits Drupal 11, the CMS the workshop already used with its clients, and it stays the only source of orders and statuses. Anything that reaches a client or the public goes out after the owner's yes.
Drupal runs an unusual kind of e-commerce here: it gathers requirements more than it sells from a catalog. The client describes what they need, and many parts are made to measure for them and stay private. On their page they follow the steps of the job: which parts are already printed, what is missing, the payment and the shipment tracking.
I’m writing about my NedCamp presentation because I’m excited about my AI-generated slide deck. Ironically, the entire presentation is about using AI to explore, build, maintain, and secure Drupal, based on my previous blog posts. Yet this post is about using AI to generate the presentation's visual narrative. Before we go further, I should share some background information.
Background
My undergraduate degree is in fine arts, with a focus on painting and some sculpture. I don’t make much art these days, but I appreciate the history, craft, and process behind making art, which helped me teach myself programming. With art and programming, AI is changing how works of art or programs are created. The reality is that AI isn't creating new things. It is generating code and images based on prior work and knowledge. Artists and developers can nudge or feed AI ideas that could generate something creative and new. I am starting to go down the rabbit hole of thoughts on AI and how I’ve integrated AI into my Drupal development workflow, which is the topic of my presentation. This post is about my presentation’s slide deck.
Past presentations
I’ve been presenting at Drupal events and recording demos for over a decade on the Webform module and my other Drupal projects. I’ve become comfortable with public speaking and organizing my thoughts. My slide decks have been simple, with me speaking off the cuff, without a script but with extensive practice beforehand.
Several times, I felt my presentation had a theme or narrative I could see visually portrayed in the slides. Still, I didn't have the bandwidth or resources to take dozens of photographs, find illustrations, or pay someone to create the imagery.
If you've seen any of my Webform presentations, which use a free comic-based template called Read More
In the Open is a weekly series from Drupal Association Interim CEO Tiffany Farriss, sharing what she is hearing across the Drupal community and where the Association is headed. In this episode: what the Drupal Association team took away from its first all-staff retreat in three years, how the Drupal certification program is evolving, and what’s coming up with the Rosetta Sprint and DrupalCon Orlando 2027.
“There are some things and some conversations that can only seem to happen when we’re all together."
The following is a transcript of Tiffany’s remarks, lightly edited for readability.
Being in one roomI’m Tiffany Farriss, the Interim CEO of the Drupal Association, and this is In the Open, my regular update on what’s happening at the Association as we navigate a year of change.
Top of mind for me is just how important and accelerating being together in person is. For the first time in three years, the entire Drupal Association staff was in one room. Drupal and the DA collaborate across global time zones every day. That’s just how it works. But there are some things and some conversations that can only seem to happen when we’re all together in the same place at the same time.
Why we existIn our DA retreat, we spent a lot of time talking about why we exist. I know you know this, but a handful of companies now run most of the web, whether it’s cloud or search or browsers, and increasingly AI. Whoever runs your infrastructure gets a say in whether or how you get to use it. Using open source and Drupal offers a different, more sovereign option, a different future, if you will.
Drupal is a registered digital public good that enterprises and governments, the UN, and humanitarian and academic organizations rely on. So all of us at the DA traced a piece of our work to someone that it helps specifically, and then we mapped it to how it serves, whether it’s the makers who build Drupal, the advocates who share the message about what Drupal is and what it could do, or the patrons who fund it.
Every single role at the Drupal Association is essential to how we steward our open source project, how Drupal is actually able to manage the commons that we have. And a lot of that work is stuff that folks in the community may not ever really see or notice.
Evolving Drupal certificationThis led us to our biggest strategic conversation of the week: the Drupal certification program.
I talked about this a little bit at Rotterdam. I feel like it’s the only thing I talk about these days. But for the last 25 years of Drupal, a really small group, mostly agencies and individuals, have been buying the round for millions of people around the world who use and run Drupal. And we’re super deeply grateful for that.
But as we all know, the agency landscape is changing, and it’s time for everyone who benefits from Drupal to buy a round too. As a 501(c)(3) program, we need to make sure that our mission serves the public interest. We’re not a trade association. We can’t give advantage to anyone or even just a few companies.
Those are real guardrails that we talked a lot about at the DA. The revamped Drupal certification is not a partner program. It’s not a trade association. We’re evolving it to be a public registry about those who engage with the Drupal ecosystem in a net neutral or a net positive way, and we’re going to build it on facts that we can verify about how organizations contribute.
By designing Drupal certification, it will include the entire ecosystem. Agencies, yes, of course. Hosting and platform providers, definitely, but also infrastructure providers, technology and third-party integrations, and global systems integrators. People who have been using Drupal, and we see them occasionally contributing in small ways, but we want to encourage them to be able to participate more.
AI has made code cheap, and what we’ve realized is that trust is precious. So you’re going to hear more about this idea of trust and Drupal trust over the coming months.
How we work togetherWe also talked a lot about how we work. Individuals here at the DA have worked side by side, some of them for many, many years. What we’re shifting to, though, is actually working together cross-functionally on things that relate to all of us.
So that’s really exciting, and I think that just reminded me that the DA needs to get together regularly and think about what it does and how we serve the Drupal community. I’m coming out of that very energized, and I also know that we’re not the only ones who need to get together regularly.
The Rosetta SprintDries has proposed an in-person Rosetta Sprint for early January, and I think that’s coming together now. The idea with Rosetta is that Drupal modules describe what they can do once, so that AI assistants, front ends, and workflow tools can all use that same description, with no custom integration work for each kind of task you might want to do.
So if you maintain a module, Dries’ post explains how to start now, and I’ve put the link below.
DrupalCon Orlando 2027Obviously, the biggest place we all come together as a Drupal community, and where that energy is really palpable, is DrupalCon. If you haven’t yet, please check out our DrupalCon Orlando site. Registration is open now for 2027.
This will be the first time since the absolutely epic DrupalCon Australia, which I missed sadly, that we’re going to be at a resort, an 1,100-acre resort, the Hyatt Regency Grand Cypress in Orlando, Florida. It’s in the Disney Springs area, right near Disney.
So you won’t want to miss it. Obviously, there will be sessions and contribution and the hallway track all in one place. But I do want to make sure that you know it is spring break week. So if staying on site with everyone really matters to you, I do encourage you to both register for DrupalCon and book your hotel now. We may be able to add more rooms, but not until the ones we already have are gone.
So you’re not going to want to miss it. The local team is deep in planning amazing things, and I know that they’ve started to recruit for the new Drupal’s Got Talent. So whatever your act is, we want to see it, so please do apply.
I’m putting links below to everything. So thank you to the DA team for a really great week together. Thank you to everyone who builds, champions, and funds Drupal, and I hope to see you in Orlando, if not before.
Follow the conversationNew episodes of In the Open publish each week. Subscribe on the Drupal Association YouTube channel to follow along.
With thanks to Stephen Cross of Second Signal Media for producing this series.