Inheriting a Drupal Project: Archeology, Metrics, and Taking Control

Sooner or later, almost every Drupal project changes hands: a contract ends, a public tender brings in a new vendor, or a client who has been maintaining the site in-house decides they need external support. Handover is a delicate moment. The client expects to see quick progress, while the knowledge the new team needs is scattered, undocumented, or left alongside the previous team. The first decisions are made on a platform that no one on the new team fully understands yet, and promises made before knowing the true state of the code now have tight deadlines.

This session covers that exact moment: how to gather as much context as possible, how to recover the rest directly from the project itself, and how to turn a handover into true project ownership—measured with data rather than gut feelings.

What the session covers

1. Making the most of the handover. What to ask for: access to all environments and systems, repositories, the deployment pipeline, integrations, open issues, and existing documentation. Also, how to organize Q&A sessions with targeted questions for the outgoing team—and why asking them what they would fix first is one of the most useful questions in the entire process.

2. Project archaeology. When there is no one left to ask or the information falls short, the project itself becomes the source. That means diving into the code and, if available, the Git commit history. Findings tend to follow familiar patterns:

   • Unmaintained or severely outdated packages, some with known security vulnerabilities
   • Code written using patterns from other frameworks or legacy versions of Drupal
   • Lack of automated tests
   • Custom code with unclear purpose, or that overlaps with an existing contrib module
   • Early architectural decisions that triggered a snowball effect, which are often resolved by fixing the root cause once identified

   The goal is to understand, not to judge, so you can deliver the best service possible. Hindsight is always 20/20. We are all familiar with the industry's fast pace and deadline pressures: last-minute changes that compromised the architecture and were never refactored, along with other real-world constraints that impact final code quality.

3. A shared project vision. Consolidating what the team learns into project documentation that everyone reads the same way, while progressively building up test coverage to serve as a safety net.
4. Metrics over opinions. Every handover starts with an initial audit, designed as a comprehensive assessment spanning security, technical health, code quality, Drupal best practices, architecture, performance, infrastructure, accessibility, SEO, and GDPR compliance. It establishes a baseline and prioritizes findings by severity. Following that, periodic audits demonstrate clear progress to both the technical team and the client’s business stakeholders.
5. Managing parallel tracks. Fixing issues identified by the audit while simultaneously tackling new feature requests, ensuring neither track blocks the other and that technical debt remediation remains visible beneath the backlog of new features.

Target audience: Project Managers, Tech Leads, and Product Owners.