You took on a Drupal codebase you did not write. Can you trust the numbers?

A Drupal codebase audit reads a repository and tells you what you are taking on: how much is custom, how much is contrib, what is theme, and what breaks on a current Drupal release. EventHorizon runs that audit from the GitHub branch you choose, so the numbers you scope and quote against are real.

The short version

• Taking on someone else's Drupal site means making decisions against numbers you did not produce.
• EventHorizon reads a GitHub repository, on the branch you pick, and reports what is custom, what is contrib, and what is theme.
• It tells a module from a theme by reading the code's own info files and directory layout, so a module count is a module count.
• What you export matches what the tool shows, so the report you hand a client says the same thing you saw.
• Built for Drupal 8 to 11, and it flags the code that breaks on a current release.

Every agency and platform team has had the same week. A new codebase lands, the deadline to scope it is short, and the person who built it is long gone. You open the repository, and the first question is the one that decides the whole estimate: how much of this did someone write by hand, and how much came off the shelf?

That split sets everything downstream. Read it well and the estimate holds: custom-module work is scoped as custom-module work, a theme rebuild is budgeted as a theme rebuild, core stays core. Read it from a quick afternoon guess and the number you put in front of a client carries that guess for the length of the project.

Why is scoping someone else's Drupal code so hard?

The honest answer is that the line between custom, contrib, and theme is obvious to the person who built the site and takes real work to recover for everyone else. A folder called modules can hold both the contrib modules you will upgrade with a command and the custom modules you will read line by line. A theme can carry as much bespoke logic as a module. A file or folder count gives you a clean total quickly, and a Drupal-aware split adds the part that drives the estimate: which of that total is custom, which is contrib, and which is theme.

This is where a grounded split earns its keep. When the number you scope and quote against is read from the code itself, it holds up through the build, so the budget you set on day one is the budget the work stays inside.

What does an accurate module and theme split give you?

It gives you an estimate you can defend. EventHorizon reads each part of the codebase the way Drupal itself does: it looks at the info file every module and theme declares, and at where the code sits in the project. From those, it decides what is a module and what is a theme, and whether each one is custom, contrib, or core. The split you see comes from the code's own declarations, the same ones Drupal reads.

That changes the report in a way that helps on the day you quote. When you ask for the modules, you get the modules, with the themes kept separate. The counts you scope against are the real counts. And because the split comes from what the code says about itself, you can stand behind the number in front of a client, confident the modules are modules and the themes are themes.

It matters again when you hand the work on. What you export carries the same split the tool shows on screen. The spreadsheet you send a client, or drop into a due-diligence pack, says the same thing you read in the dashboard. There is no quiet drift between the view you scoped from and the document you put your name to.

Can you check a release before it ships?

Yes, and you choose the branch yourself. You connect a GitHub repository, pick the branch you want to read, and EventHorizon audits that branch. So you can read a release branch before it merges, while there is still time to act on what it carries.

For a team that ships on a schedule, that puts findings in your hands while there is still time to act on them. You point the audit at the branch that is about to go out, and you see what it carries before you sign off on the release.

Who is this for?

For an agency, this is the first day of a new engagement made calmer. The scoping read that used to eat a day of careful clicking becomes a report grounded in numbers read from the code, so the estimate goes out built on real numbers you can show.

For an enterprise running technical due diligence, it is a repeatable read on a codebase you are about to depend on or acquire: how much is bespoke, how much is off the shelf, and what is already out of step with a current Drupal release.

For a product team, it is a gate you can run on every release branch, so the risk in a change is something you see before you ship, while there is still time to act on it.

Numbers you can put your name to

Scoping a Drupal codebase you did not write will always carry some uncertainty. What you can remove is the uncertainty that comes from guessing the basics. When the module and theme split is read from the code itself, when the audit runs on the exact branch you care about, and when the export matches the screen, the number you quote is one you can defend in the room.

This post is part of the EventHorizon Release Blogs series, alongside the pillar, Drupal native, not generic, and the companions on performance and cache tags, static security analysis, dependency maps and upgrades, and keeping your code private.

That is the quiet value of a good audit. It makes the work knowable, early enough to plan around, and solid enough to put your name to.

---