Legacy site-manifest: het bestand in twintig minuten

Je erft een Drupal-site die iemand in 2017 heeft gebouwd. De oorspronkelijke ontwikkelaar is naar Berlijn verhuisd. Het bureau dat de site bijhield, is vorig jaar omgevallen. Er is één gedeeld Google Doc met een Plesk-wachtwoord, een handgetekend diagram in een Dropbox-map met de naam "oude troep", en in je inbox een terugkerende factuur van €38 per maand van een hostingprovider waar je nog nooit op hebt ingelogd. De site draait €40k per maand aan omzet. De PHP-versie is één release verwijderd van end-of-life.

Dit is het moment waarop je het manifest pakt. Of waarop je het drie weken later pakt, na het eerste incident, nadat je de helft ervan hebt gereconstrueerd met grep en gokwerk. Wij hebben het op beide manieren gedaan. De eerste manier is sneller.

Wat een manifest eigenlijk is

Een manifest is één bestand dat de legacy site beschrijft zoals die er vandaag uitziet. Niet hoe hij herbouwd moet worden. Niet wat er kapot is. Niet wat een migratie zou kosten. Alleen de feiten van de huidige installatie: elke versie, elke plek waar credentials liggen, elke cron, elke integratie, elke persoon die er nog vragen over kan beantwoorden.

Het is geen runbook en geen architectuurdiagram. Die komen later, zodra je het systeem echt begrijpt. Het manifest is het ding dat je schrijft voordat je het begrijpt, zodat de volgende persoon niet bij nul hoeft te beginnen.

Het hoort in de repository thuis, in de root, in plain text of markdown of YAML. Nooit in een Google Doc. Documenten raken kwijt. Het manifest wordt mee gecloned met de codebase, en daar kijkt de volgende engineer als eerste.

De versie van twintig minuten

Je kunt een bruikbaar manifest schrijven in twintig minuten, als je stopt met volledig willen zijn. Open een tekstbestand. Beantwoord tien vragen. Sla op.

1. Wat is de URL van de site, en waar staat de broncode?
2. Op welke stack draait hij, met versienummers?
3. Wie host de site, en waar staan de credentials?
4. Wat is de database, hoe groot is hij, waar gaan de back-ups heen?
5. Met welke third-party diensten praat hij?
6. Wat draait er op een schema (cron, queue, scheduled task)?
7. Hoe werkt authenticatie, en wie heeft admin?
8. Welke mensen beheren welke delen van de content?
9. Wat is er nu kapot waar iedereen mee heeft leren leven?
10. Wanneer is dit manifest voor het laatst geverifieerd, en door wie?

Dat is het. Tien antwoorden. Zo ziet een van die van ons eruit, geanonimiseerd:

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

Niets hiervan is moeilijk te vinden. Het meeste staat in je hostingpaneel, je wachtwoordmanager, en de composer.json of composer.lock in de root van de repo. De wrijving zit niet in het verzamelen van de informatie. De wrijving zit in twintig minuten gaan zitten en het op één plek opschrijven.

De versienummers zijn het punt

Twee regels in het voorbeeld hierboven zijn stilletjes gevaarlijk. PHP 7.4 krijgt sinds november 2022 geen security-fixes meer, volgens de officiële PHP-versielijst. Drupal 7 bereikte end-of-life op 5 januari 2025, volgens het Drupal release-schema. Elk van die twee is een serieuze bevinding. Beide samen is een site die geen kaartbetalingen zou moeten verwerken.

Het manifest dwingt je om de versies op te schrijven. De versies dwingen je om ze op te zoeken. Het opzoeken brengt de EOL-data boven. Dat is de hele cirkel, en zodra het bestand bestaat kost het ongeveer drie minuten.

Wat het bestand oplevert

Een manifest is de twintig minuten waard omdat er vier dingen goedkoper worden zodra het bestaat.

Onboarding. Een nieuwe engineer leest één bestand en weet waar hij aanzit. Zonder manifest verliest hij een dag aan grep door settings-bestanden en bij drie mensen wachtwoorden navragen.

Migratie-scope. Je kunt geen accurate offerte maken voor een migratie van Drupal 7 naar Drupal 10 zonder te weten welke contrib-modules geïnstalleerd zijn, van welke PHP-extensies de site afhankelijk is, en welke integraties breken zodra de URL verandert. Het manifest is de spec voor de spec.

Incidentrespons. Site is om 22:00 op een vrijdagavond offline. Je moet weten wie de site host, hoe je in het paneel komt, en of de laatste back-up vers genoeg is om naar terug te draaien. Het manifest beantwoordt alle drie nog voordat je Slack open hebt.

Security-audits. De versienummers vertellen je wat end-of-life is. De integratielijst vertelt je welke API-keys er in het wild rondzwerven. De auth-sectie vertelt je of 2FA aan staat. Drie minuten lezen vervangt een middag scannen.

Het onderhoudsritueel

Een manifest dat niet klopt, is erger dan geen manifest. De oplossing is een klein ritueel: elk kwartaal leest de eigenaar het bestand opnieuw door en werkt de last_verified-datum bij. Als een regel niet in vijf minuten te bevestigen is, gaat hij eruit. Het bestand mag krimpen als dat nodig is. Vijf accurate regels verslaan vijftig verouderde.

Voor sites die wij onderhouden zetten we een agenda-herinnering bij de naam van de eigenaar. De herinnering is niet "audit de site". Hij is "open het manifest, pas de datum aan of verwijder een regel". Dat is een taak die een mens ook daadwerkelijk doet.

Wat we leerden door dit voor klanten te bouwen

Toen we dit kwartaal een Joomla 3-site overnamen voor een Nederlandse groothandel, liepen we ertegenaan dat het vorige bureau een betaald Algolia-plan had laten doorlopen dat niemand gebruikte. We zagen het in de eerste tien minuten van het schrijven van het manifest, nog voor enig legacy-migratiewerk was begonnen, en bespaarden de klant €1.400 per jaar op een tool die de site niet meer nodig had.

Als je vandaag één ding doet: open de repo van je oudste productiesite en maak /docs/manifest.md aan. Beantwoord de tien vragen. Commit. Dat is de kleinste leesbare stap richting niet de persoon zijn die het volgend jaar uit grep zit te reconstrueren.