Legacy site manifest: the 20-minute file your team needs

You inherit a Drupal site that someone built in 2017. The original developer moved to Berlin. The agency that maintained it folded last year. There is one shared Google Doc with a Plesk password, a hand-drawn diagram in a Dropbox folder called "old stuff", and a recurring invoice in your inbox for €38 a month from a hosting provider you have never logged into. The site does €40k a month in revenue. The PHP version is one release behind end-of-life.

This is the moment you reach for the manifest. Or you reach for it three weeks later, after the first incident, having reconstructed half of it from grep and guesswork. We have done both. The first way is faster.

What a manifest actually is

A manifest is one file that describes the legacy site as it exists today. Not how it should be rebuilt. Not what is broken. Not what a migration would cost. Just the facts of the current install: every version, every credential location, every cron, every integration, every human who can still answer questions about it.

It is not a runbook and not an architecture diagram. Those come later, once you actually understand the system. The manifest is the thing you write before you understand it, so that the next person does not have to start from zero.

It belongs in the repository, at the root, in plain text or markdown or YAML. Never in a Google Doc. Docs get lost. The manifest gets cloned with the codebase, which is where the next engineer will look first.

The twenty-minute version

You can write a useful manifest in twenty minutes if you stop trying to be exhaustive. Open a text file. Answer ten questions. Save.

1. What is the URL of the site, and where is the source code?
2. What stack is it on, with version numbers?
3. Who hosts it, and where are the credentials stored?
4. What is the database, how big is it, where do backups go?
5. What third-party services does it talk to?
6. What runs on a schedule (cron, queue, scheduled task)?
7. How does authentication work, and who has admin?
8. Which humans own which parts of the content?
9. What is currently broken that everyone has learned to live with?
10. When was this manifest last verified, and by whom?

That is it. Ten answers. Here is what one of ours looks like, anonymised:

site: example.com
stack:
  cms: Drupal 7.98
  php: 7.4.33
  mysql: 5.7.39
  webserver: Apache 2.4 (via Plesk)
hosting:
  provider: TransIP VPS
  panel: plesk.example.com
  credentials_location: 1Password vault "Client / Example"
  monthly_cost_eur: 38
domain:
  registrar: TransIP
  dns: Cloudflare (free tier)
  ssl: Let's Encrypt, auto-renew via Plesk
database:
  name: example_drupal
  size_mb: 412
  backups: nightly to /var/backups, 7-day retention, no offsite copy
integrations:
  payments: Mollie (live key in sites/default/settings.php)
  mail: SMTP via Google Workspace
  analytics: GA4 property G-XXXXXXX
  search: Algolia (free tier, 10k records)
scheduled_tasks:
  - drush cron every 15 min (Plesk scheduler)
  - nightly db dump at 03:00 UTC
auth:
  admin_users: 3 (see vault)
  2fa: none
  sso: none
content_owners:
  marketing: sara@client.example
  tech: agency contact unreachable since 2025-09
known_issues:
  - product image upload broken since 2024-05
  - /nl/contact form not delivering (postfix queue full)
  - php 7.4 has been end-of-life since 2022-11
last_verified: 2026-03-12
manifest_owner: jacob@abn.company

None of this is hard to find. Most of it lives in your hosting panel, your password manager, and the composer.json or composer.lock at the root of the repo. The friction is not collecting the information. It is sitting down for twenty minutes and writing it in one place.

The version numbers are the point

Two of the lines in the example above are quietly dangerous. PHP 7.4 stopped receiving security fixes in November 2022, per the official PHP supported versions list. Drupal 7 reached end-of-life on 5 January 2025, per the Drupal release schedule. Either of those is a serious finding. Both together is a site that should not be processing card payments.

The manifest forces you to write the versions down. The versions force you to look them up. Looking them up surfaces the EOL dates. That is the whole loop, and it takes about three minutes once the file exists.

What the file unlocks

A manifest is worth the twenty minutes because four things become cheaper the moment it exists.

Onboarding. A new engineer reads one file and knows what they are touching. Without it, they spend a day grepping settings files and asking three people for passwords.

Migration scoping. You cannot quote a Drupal 7 to Drupal 10 migration accurately without knowing which contrib modules are installed, which PHP extensions the site depends on, and which integrations break the moment the URL changes. The manifest is the spec for the spec.

Incident response. Site is down at 22:00 on a Friday. You need to know who hosts it, how to get into the panel, and whether the last backup is recent enough to roll back to. The manifest answers all three before you finish opening Slack.

Security audits. The version numbers tell you what is end-of-life. The integrations list tells you what API keys exist in the wild. The auth section tells you whether 2FA is on. Three minutes of reading replaces an afternoon of scanning.

The maintenance ritual

A manifest that is wrong is worse than no manifest. The fix is a tiny ritual: every quarter, the owner re-reads the file and updates the last_verified date. If a line cannot be confirmed in five minutes, it gets removed. The file shrinks if needed. Five accurate lines beat fifty stale ones.

For sites we maintain, we put a calendar reminder on the owner's name. The reminder is not "audit the site". It is "open the manifest, change the date or delete a line". That is a task a human will actually do.

What we learned shipping this for clients

When we took over a Joomla 3 site for a Dutch wholesale client this quarter, the thing we ran into was that the previous agency had left a paid Algolia plan running that nobody used. We caught it in the first ten minutes of writing the manifest, before any legacy migration work began, and saved the client €1,400 a year on a tool the site no longer needed.

If you do one thing today, open the repo of your oldest production site and create /docs/manifest.md. Answer the ten questions. Commit it. That is the smallest legible step toward not being the person reconstructing it from grep next year.