One Engineer, One Hackathon, 1,500 Hours Erased: How We Automated Migration Audits For A 500-Site Drupal Fleet

The Problem No One Had Time To Solve

Manual pre-migration audits for large Drupal fleets are one of the most time-intensive bottlenecks in enterprise CMS migration projects. Here is what a pre-migration audit looked like for a 500-site Drupal fleet migrating to Acquia ACSF:

1. SSH into a bastion host.
2. Tunnel through to the source database.
3. Run ad-hoc queries to inventory content types, Layout Builder blocks, media assets, taxonomies, menus, webforms, and five other content categories.
4. Copy the results into a spreadsheet.
5. Manually cross-reference the inventory against the migration codebase to identify coverage gaps.
6. Repeat for the next site.

Each site took 2 to 4 hours to audit manually. At 500 sites, the total Drupal migration audit burden reached approximately 1,500 analyst-hours — the equivalent of 37.5 full working weeks. That is 37.5 full working weeks of someone opening terminals, running queries, and pasting into cells.

The real cost was not just time. Coverage gaps — content types or components without migration mapping — were typically discovered only after running the migration. Not before. That meant failed migrations, rework cycles, and delayed timelines on a project where 500 sites needed to land on a new platform.

Post-migration QA was equally manual. Engineers visited thousands of pages on both source and destination environments, visually comparing layouts and content. There was no systematic way to catch regressions at scale.

The problem was visible to everyone on the project. No one had the bandwidth to solve it inside normal delivery cycles. (For a broader view of how delivery teams manage migration risk, see how delivery teams reduce migration risk and build executive confidence.)

The Hypothesis And The Hackathon Experiment

If the pre-migration audit and post-migration QA could be automated into a single Drupal admin interface, per-site audit time would drop from hours to minutes — and coverage gap detection would shift from post-migration discovery to pre-migration identification.

The opportunity came during an internal hackathon. One senior engineer submitted an idea (Idea #23 on the internal platform) and built the solution using Claude as an AI coding collaborator during the time-boxed event.

The result: a Drupal 11 module called bi_migrate_audit that replaces the entire manual workflow with two integrated processes. This follows a pattern Axelerant has used before — turning a recurring engineering frustration into a reusable tool. See how a similar approach produced an SDLC plugin from one engineer's frustration and an open-source plugin that made Drupal delivery more predictable.

What Got Built: Automated Pre-Migration Audit For Drupal

Step Manual Process Automated Process Site selection Engineer identifies site, looks up credentials Dropdown in Drupal admin populated via Acquia Cloud API and Site Factory API Database access SSH into bastion host, tunnel to database manually Module opens SSH tunnel through bastion automatically. No terminal required. Content inventory Ad-hoc queries across 11 content categories Automated scan across all 11 categories: content types, Layout Builder blocks, media, taxonomy, menus, webforms, and more Coverage analysis Manual spreadsheet cross-reference PHP tokenisation cross-references audit results against actual migration codebase Gap reporting Informal notes, discovered post-migration Traffic-light dashboard: green (covered), amber (needs review), red (needs client approval) Documentation Manually assembled spreadsheet Coverage charts and print-ready PDF generated automatically

The architecture decision that makes this work at scale: coverage discovery is dynamic. The module reads YAML configuration to determine what content categories to audit, then uses PHP tokenisation to scan the migration codebase and determine what is already handled. This dynamic coverage analysis means the audit tool automatically stays current as the migration codebase evolves — no hardcoded checklists that go stale.

For teams managing large Drupal fleets on Acquia, this pairs naturally with platform-level tools. See the case for Acquia MEO for multi-site Drupal management and how Acquia Source changes the development workflow.

What Got Built: Automated Post-Migration QA

Step Manual Process Automated Process Page inventory Engineers manually compile lists of pages to check Module streams pre-formatted alias CSV from source database in approximately 30 seconds Visual comparison Manual page-by-page visits on source and destination CSV feeds a Playwright-based page comparator for automated visual diffing Results review Screenshots shared via chat or email Engineers upload ZIP report into Drupal admin, rendered in an iframe. No external file sharing.

The entire system sits inside the Drupal admin panel. An analyst with no terminal access can run a full pre-migration audit and review post-migration QA results without leaving the CMS — eliminating DevOps as a bottleneck for routine audit operations.

This approach to keeping QA inside the delivery tool aligns with Axelerant's broader Drupal QA practice and the Drupal migration services that support large-scale platform transitions.

The Drupal Migration Audit Automation Results

Metric Before After Change Per-site audit time 2–4 hours Under 10 minutes ~94% reduction Total fleet audit effort (500 sites) ~1,500 analyst-hours ~83 analyst-hours 94% reduction Coverage gap detection timing Post-migration (during QA) Pre-migration (before execution) Shifted left Post-migration page inventory export Manual compilation (hours) ~30 seconds Orders of magnitude faster Visual QA method Manual page visits Automated Playwright comparison Systematic, not sampled

The 94% reduction is arithmetic: 500 sites × 10 minutes = 83.3 analyst-hours, down from an estimated 1,500 hours — a saving of more than 1,400 hours on a single project.

But the number that matters more is zero. Zero migrations run without knowing the coverage gaps in advance. The shift from post-migration gap discovery to pre-migration gap identification eliminates an entire class of rework. This is the same principle behind why Drupal 7 and WordPress to Drupal 11 migrations are never "just a migration" — the audit and planning phase determines the outcome.

External Validation From Acquia

The module was accepted by the Acquia team and contributed to the project codebase. The code was also shared with Acquia's Production Partners team and the client's own technical team.

Having the platform vendor adopt code built by a services partner is one of the strongest forms of validation in the Acquia ecosystem — it signals that the engineering quality, API usage patterns, and architectural approach met the bar set by the people who built the platform.

This builds on Axelerant's established track record with Acquia. See the Acquia–Axelerant partnership and Acquia Site Factory case study for context on how this relationship shapes engineering decisions.

The Role Of AI In The Build

The engineer used Claude as a coding collaborator during the hackathon. The dossier is clear on what we know and what we do not.

What we know: The engineer designed the architecture, selected the integration approach (Acquia Cloud API, Site Factory API, PHP tokenisation for coverage analysis, SSH tunnel automation), and produced a working, production-grade module within the hackathon window. Claude was used as a coding partner during the build.

What we do not yet know: The specific division of labor between engineer and AI. Which components Claude generated versus which the engineer wrote directly. How the engineer prompted Claude. How much time the AI collaboration saved compared to building without it.

We are documenting these details through a follow-up interview with the builder. What we can say now: the output was not a prototype. It shipped to production and was accepted by the platform vendor. The engineer's deep knowledge of Acquia's API surface, Drupal's module architecture, and the migration team's actual daily workflow shaped every design decision. That domain expertise was the irreplaceable ingredient.

This mirrors a pattern emerging across Axelerant's engineering teams — AI as a force multiplier for engineers who already have deep domain knowledge. See how AI is transforming engineering workflows and why AI adoption is no longer optional for engineering teams.

The Four-Layer Migration Audit Architecture

This is not a story about one module on one project. The pattern applies to any large-scale CMS migration. Here is the transferable framework.

The Four-Layer Migration Audit Architecture is an approach to automating pre-migration content auditing that replaces manual, per-site inventory processes with a self-service, code-aware system integrated into the CMS admin layer.

Layer Purpose Implementation In This Module Transferable Principle Platform API Discovery Enumerate source sites, fetch credentials, manage access programmatically Acquia Cloud API and Site Factory API populate a site dropdown, auto-fetch database credentials Use the hosting platform's APIs to discover sources. Do not maintain static lists that go stale. Automated Tunnel And Access Abstract away infrastructure access so analysts can self-serve SSH tunnel opened and managed through bastion hosts automatically from within Drupal admin Remove DevOps as a bottleneck for routine audit operations. The goal is self-service without terminal access. Dynamic Coverage Analysis Cross-reference source content against migration code using code analysis, not static checklists PHP tokenisation scans the migration codebase, compares against content inventory from source database Static checklists decay. Code-driven analysis stays current as the migration codebase evolves. Integrated Reporting Keep results inside the tool the team already uses Traffic-light dashboard, coverage charts, print-ready PDF, and QA report iframe all inside Drupal admin Exporting to spreadsheets or external dashboards creates version control problems and access friction.

Teams running large Drupal multisite estates can apply this framework regardless of hosting platform. The goal is the same: make pre-migration audit self-service, make coverage analysis code-aware, and keep all reporting inside the CMS. Learn more about Axelerant's Drupal migration services and Drupal Acquia services.

Frequently Asked Questions

What is Drupal migration audit automation?

Drupal migration audit automation is the practice of replacing manual, per-site content inventory and coverage gap analysis with a programmatic system that scans source databases and cross-references migration codebases automatically. Instead of an engineer spending 2–4 hours per site running ad-hoc queries and pasting results into spreadsheets, an automated audit module completes the same inventory in under 10 minutes per site — including coverage gap detection against the live migration codebase.

How long does a manual pre-migration audit take for a large Drupal fleet?

For a 500-site Drupal fleet, manual pre-migration audits require approximately 1,500 analyst-hours — roughly 37.5 full working weeks — when each site takes 2 to 4 hours to audit. This includes SSH access setup, database querying across multiple content categories, spreadsheet compilation, and manual cross-referencing against the migration codebase. Automation reduces this to approximately 83 analyst-hours, a 94% reduction.

What content categories does an automated Drupal migration audit cover?

A comprehensive Drupal migration audit should cover at least 11 content categories: content types, Layout Builder blocks, media assets, taxonomy terms, menus, webforms, and additional site-specific components. The bi_migrate_audit module uses YAML configuration to define audit scope and PHP tokenisation to dynamically detect which categories are already handled in the migration codebase — ensuring no content type is missed before migration execution begins.

What is the Four-Layer Migration Audit Architecture?

The Four-Layer Migration Audit Architecture is a framework for automating large-scale CMS migration audits. The four layers are: Platform API Discovery (using hosting APIs to enumerate source sites programmatically), Automated Tunnel and Access (abstracting infrastructure access so analysts self-serve without terminal access), Dynamic Coverage Analysis (using code analysis rather than static checklists to cross-reference content against migration code), and Integrated Reporting (keeping all results inside the CMS admin rather than external dashboards or spreadsheets).

How does automated post-migration QA work for Drupal multisite migrations?

Automated post-migration QA for Drupal multisite migrations uses a two-step pipeline: first, the migration audit module exports a pre-formatted page alias CSV from the source database in approximately 30 seconds; second, that CSV feeds a Playwright-based visual comparator that automatically diffs source and destination pages at scale. Results are uploaded as a ZIP report and rendered directly inside the Drupal admin panel, eliminating manual page-by-page visits and ad-hoc screenshot sharing.