Skip to content
FN 05Field noteAugust 10, 2026

Taking over a Drupal site from a previous developer: the technical checklist

#drupal#inherited-sites#devops

The survival guide covers triage for whoever got handed the site. This one’s for the developer doing the actual takeover — the technical inventory that decides whether the next year is maintenance or archaeology.

Access, in dependency order

Get these in this order, because each unlocks the next: hosting/server (SSH or platform dashboard), the database, the codebase, then Drupal admin. With server access you can recover everything else — drush uli mints an admin login, and the database gives up its secrets to anyone who can read settings.php.

The repository question

git status on the server tells you more about the previous developer than any reference call. The tiers, best to worst:

  1. Clean repo, remote you can reach, deploys documented. Rare. Cherish it.
  2. A repo exists but the server has drifted. Diff server against HEAD before touching anything — those drifted changes are undocumented production hotfixes, and they’re load-bearing.
  3. No repo. The server is the source of truth. Your first act is git init and a commit of exactly what’s running, warts included, before any cleanup instinct kicks in. Archaeology starts with preserving the dig site.

Composer, or the lack of it

On Drupal 8+, check whether composer.json and the lock file actually match /vendor and the module set — composer validate and composer status answer quickly. A D8+/9/10 site managed by FTP-ing module folders around (you’ll see it: no lock file, or vendor committed wholesale) needs its dependency story rebuilt before any update runs safely. On Drupal 7 there’s usually no composer at all; the module inventory is /sites/all/modules, and drush pm-list is your census.

Configuration state (D8+)

drush config:status — the single most informative command on an inherited modern Drupal site. Overridden config means the database and the exported YAML disagree; until you know which side is truth, drush cim is a loaded weapon. If there’s no config export at all, drush cex into the fresh repo is day-one work.

The five-command physical

drush status          # versions, DB, paths — the vitals
drush pm-list         # what's installed vs enabled
drush ws --count 50   # what the log has been screaming about
drush config:status   # config drift (D8+)
drush sql:query "SELECT COUNT(*) FROM users"   # scale check

Twenty minutes with those five tells you more than the previous shop’s whole handoff document — when one exists.

When the checklist says “assessment”

No repo and no composer and config drift and a red status report is a site where fixed-price certainty beats hourly archaeology: the upgrade assessment (from $2,500) or a rescue ($1,500) produces the written map first, whoever does the work after. That’s not upsell — it’s the same thing you’d tell a friend at a campfire: know the water before you paddle it.


Dead North takes over Drupal sites for a living — versions 5 through 11 since 2013, two contrib modules maintained, prices published.