Maintenance

What to do when the previous developer is gone — taking over a Drupal project

A developer handover is a common situation. Here is a practical guide for taking over a Drupal project without losing anything critical.

Why this situation is difficult

A Drupal project is more than code. It is:

  • Configuration (modules, settings, roles)
  • Database (content, users)
  • Files (images, documents)
  • Hosting (server, domain, SSL, email settings)
  • External services (analytics, payments, CRM integrations)
  • Knowledge (why things were built a certain way, what known issues exist)

The previous developer held all of this in their head. Now you have to reconstruct it.

First steps

1. Collect all access credentials

Gather everything before contact with the previous developer ends:

  • Hosting — where the site lives, SSH/FTP, cPanel/Plesk
  • Domain — registrar, DNS management
  • Drupal admin — administrator account
  • Database — database credentials (host, name, user, password)
  • Version control — git repository (GitHub, Bitbucket, GitLab)
  • External services — Google Analytics, reCAPTCHA, payment gateways, email services

If the previous developer is uncooperative, check whether the hosting is in your name — then you can restore access yourself.

2. Take a backup immediately

Before you touch anything: ```bash # Database mysqldump -u [user] -p [dbname] > backup_$(date +%Y%m%d).sql

# Files tar -czf files_backup_$(date +%Y%m%d).tar.gz sites/default/files/ ```

3. Map what exists

  • Which Drupal version? (drush status)
  • Which modules are installed? (drush pm:list --status=enabled)
  • Are there custom modules? (ls modules/custom/)
  • Is there a git repository? (git log --oneline -10)
  • Which PHP version is in use?

``bash drush status drush pm:list --status=enabled --type=module ``

What to look for in the code

Documentation

Is there a README.md? Are there comments in the code? Often there are not — but check.

Custom modules

Modules in the modules/custom/ directory are what the previous developer wrote. These are the most critical — they are not updated automatically and documentation is often missing.

Hooks and overrides

Look for hook_ functions in .module files — these are customisations to Drupal's default behaviour.

Hardcoded values

Search for IP addresses, domain names, API keys embedded directly in code. These are red flags.

settings.php

sites/default/settings.php contains database credentials and environment settings. Keep this file secure.

If the code quality is poor

The previous developer may have written code that "works but":

  • Is not upgradeable
  • Does not follow Drupal standards
  • Has security vulnerabilities
  • Has performance problems

Rewriting everything immediately is rarely sensible. The right approach:

  1. Stabilise — make sure everything works, take backups
  2. Update — modules, Drupal core, PHP
  3. Audit — map problems by priority
  4. Fix incrementally — start with security, then performance, then code quality

Technical audit

After a handover we recommend a technical audit to get a clear picture of:

  • Module health (updates, security status)
  • Custom code quality
  • Performance
  • Accessibility
  • Known issues

This gives a clear view of what to expect and what to prioritise. Contact us — we can map the situation quickly.

Kaido Toomingas Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us