How to Audit a Drupal Site You’ve Just Inherited: A Complete Drupal Review Framework

Few situations are more uncomfortable than inheriting a Drupal site you didn’t build.

The previous developers are gone. Documentation is incomplete. Nobody can explain why certain modules were installed. Production is behaving differently than development. Stakeholders want changes immediately, but you’re not even sure what you’re looking at yet.

Most developers make the same mistake when they inherit a Drupal project:

They start changing things before they understand the system.

That’s how outages happen.

Over the years I’ve inherited Drupal projects from agencies, internal teams, contractors, and organizations that had lost all institutional knowledge. Some were clean and maintainable. Others were held together by custom code nobody understood and modules that hadn’t been updated in years.

The goal of an audit is not to criticize previous developers.

The goal is to establish a clear understanding of:

What exists
What is working
What is risky
What should be fixed
What can wait

This article outlines the framework I use when evaluating a newly inherited Drupal platform.

Step 1: Establish the Facts

Before touching code, gather information.

Create a simple project inventory.

Document:

Drupal version
PHP version
Database version
Hosting provider
Deployment process
Repository location
Branching strategy
CI/CD tools
SSL provider
DNS ownership
CDN provider
Monitoring tools

You would be surprised how often organizations cannot answer all of these questions.

If you cannot identify who controls DNS, hosting, source code, and deployments, stop and solve that first.

Ownership confusion creates operational risk.

Step 2: Understand the Business Purpose

Technical audits fail when they focus only on code.

Ask:

Why does this site exist?

A government agency website, a media platform, and an ecommerce application have completely different requirements.

Meet with stakeholders and document:

Business goals
Critical user journeys
Revenue dependencies
Compliance requirements
Publishing workflows
Integrations

Understanding the business context helps prioritize technical work.

A broken search experience may be more important than upgrading a module.

A content approval workflow may matter more than performance tuning.

Step 3: Audit the Content Model

The content architecture is usually where Drupal either shines or becomes difficult to maintain.

Review:

Content types
Taxonomies
Paragraphs
Media entities
User roles
Custom entities

Ask:

Does the model reflect the business?

Common problems include:

Content Types That Should Be Taxonomies

I’ve seen systems with:

News content type
Blog content type
Article content type
Story content type

All representing nearly identical structures.

This creates unnecessary complexity.

Taxonomies Doing Too Much

Some sites use taxonomy terms as content storage.

This usually becomes difficult to manage at scale.

Field Sprawl

A content type with 80 fields is often a warning sign.

Not always.

But often.

Document anything that appears overly complex or duplicated.

Step 4: Review User Roles and Permissions

Permissions are one of the most overlooked areas of Drupal maintenance.

Review:

User roles
Permission assignments
Administrator access
Editorial workflows
Anonymous access

Questions to ask:

Can editors accidentally break production content?

Do users have permissions they don’t need?

Are custom roles clearly defined?

Many inherited sites have permission drift caused by years of incremental changes.

Step 5: Audit Contributed Modules

Create a complete module inventory.

Categorize modules into:

Core Functionality

Modules critical to operation.

Examples:

JSON:API
Media
Views
Pathauto

Business Functionality

Modules supporting workflows.

Examples:

Content moderation
Rules
ECA

Technical Infrastructure

Examples:

Redis
Solr
OAuth
Scheduler

Then identify:

Abandoned modules
Unsupported modules
Duplicate functionality
Modules no longer used

One of the easiest wins on inherited projects is removing dead dependencies.

Step 6: Review Custom Code

This is often where the real risk lives.

Review:

Custom modules
Themes
Patches
Event subscribers
Services
Plugins

Look for:

Business Logic Hidden Everywhere

Business rules should be predictable.

If logic exists inside:

preprocess hooks
forms
services
controllers
templates

simultaneously, maintenance becomes difficult.

Custom Code Replacing Existing Solutions

Sometimes custom code exists because no alternative was available.

Other times developers simply didn’t know the ecosystem.

Document these situations carefully.

Missing Documentation

Lack of documentation doesn’t automatically mean bad code.

But undocumented business-critical systems represent risk.

Step 7: Perform a Security Review

Security deserves its own audit category.

Review:

Core version
Module updates
PHP version
SSL configuration
User permissions
Authentication flows

Check:

Open security advisories
Exposed configuration
Unused administrator accounts
Weak password policies

If OAuth or SSO exists, review:

Token lifetimes
Client permissions
Scope configuration

Many Drupal security issues are configuration issues rather than software vulnerabilities.

Step 8: Audit Performance

Performance complaints often originate from architecture problems rather than server capacity.

Review:

Caching

Is Drupal caching configured correctly?

CDN

Is static content being cached?

Database

Are queries optimized?

Search

Is Solr configured correctly?

JSON:API

Are clients over-fetching data?

Images

Are image styles optimized?

Measure before changing anything.

Performance tuning without metrics becomes guesswork.

Step 9: Review Hosting and Infrastructure

Many inherited problems originate outside Drupal.

Document:

Server specifications
Autoscaling strategy
Backup policies
Disaster recovery
Monitoring
Logging

Ask:

What happens if production fails today?

If nobody knows the answer, you have identified a serious operational risk.

Step 10: Audit Deployment Processes

A deployment process reveals a lot about a team’s maturity.

Review:

Git workflow
Release process
Environment strategy
Configuration management
Rollback capability

Questions:

Can deployments be repeated reliably?

Can production be restored quickly?

Is configuration managed correctly?

A technically excellent site can still be operationally fragile.

Common Mistakes

Mistake #1: Starting Development Immediately

Resist the urge.

Understand first.

Change second.

Mistake #2: Chasing Every Problem

Not every issue matters.

Focus on business impact.

Mistake #3: Ignoring Stakeholders

Technical excellence means little if business goals are ignored.

Mistake #4: Rebuilding Everything

Most inherited systems don’t need rewrites.

They need prioritization.

Drupal Site Audit Checklist

Discovery

Hosting identified
Repository identified
Deployment process documented
Business stakeholders identified

Architecture

Content model reviewed
Entity relationships documented
Custom code reviewed

Security

Updates reviewed
Permissions audited
Authentication reviewed

Performance

Caching evaluated
Search evaluated
Database evaluated

Operations

Backup strategy documented
Monitoring reviewed
Disaster recovery reviewed

Technical Debt

High-risk items documented
Medium-risk items documented
Low-risk items documented

Final Thoughts

A Drupal audit isn’t about finding flaws.

It’s about reducing uncertainty.

By the end of your review, you should be able to answer three questions:

What is working?
What is risky?
What should happen next?

If you can answer those confidently, you’ve already created significant value for the organization.

Most inherited Drupal projects aren’t disasters.

They’re simply undocumented.

The audit process turns unknowns into knowns, and once you have clarity, the path forward becomes much easier.

Need Help Reviewing a Drupal Platform?

DrupalRX specializes in architecture reviews, inherited site audits, headless Drupal evaluations, performance investigations, and modernization planning.

If you’ve inherited a Drupal platform and need an experienced second opinion, start with an architecture review before making major technical decisions.

standard