A sample handover documentation
This is the set that stays with the client after our work: here for a typical company website on WordPress, on shared hosting. Names, addresses and figures are examples; the layout and the scope are real. All of it lives in the client’s repository as Markdown and configuration written as code; passwords and keys never go into the repository, only into the client’s password manager.
The first conversation is free: 30 minutes online, no preparation and no commitment.
What the handover contains
- Service card: what it is, what it runs on, who is responsible for what and what it costs.
- Access register: who has access to what, how, and when it is reviewed.
- Backups and restore: what, how often, where, and a restore procedure proven in a test.
- Emergency procedures: symptoms, steps, escalation, contacts.
- Updates and changes: rhythm, staging environment, change log.
- Monitoring: what is checked and who gets the alerts.
- Acceptance checklist: what must hold before we call the handover complete.
1. Service card
| Field | Value (example) |
|---|---|
| Service | Company website example.com |
| Platform | WordPress 6.x, PHP 8.3, MariaDB 10.11; custom theme, 11 plugins (listed in plugins.md) |
| Hosting | Shared hosting, account example-prod, server s12.hosting.example, PHP and database managed in the provider’s panel |
| Domains and DNS | example.com, www.example.com; registrar: provider A, renewal 14 March 2027; DNS: Cloudflare, zone example.com |
| Certificate | Let’s Encrypt, renewed automatically; monitoring check 30 days before expiry |
Google Workspace; MX, SPF, DKIM and DMARC records in DNS (export in dns/example.com.zone) | |
| Forms | Contact and recruitment forms, sent through the e-mail provider’s SMTP to contact@example.com, copy to the CRM |
| Integrations | Visit statistics (self-hosted, cookieless), newsletter, directions map, CRM |
| Business owner | Name, role, contact |
| Technical owner | Name on the client’s side; Kol.ski within the scope of the operations contract |
| Monthly costs | Hosting 12 €, domain 2 €, 2 premium plugins 8 €, off-site backups 2 € |
2. Access register
Access is always personal, with two-factor authentication wherever the provider offers it. Shared accounts are removed on the day of the handover. The list is reviewed every quarter and on the day any collaboration ends.
| Resource | Who | Type of access | Where it is kept | Last review |
|---|---|---|---|---|
| Hosting panel | Technical owner, Kol.ski on-call | Personal accounts, 2FA | Client’s password manager | 2026-10-01 |
| SFTP and SSH | Kol.ski on-call | Personal keys, no passwords | Keys with their owners, public keys in access/keys.md | 2026-10-01 |
| Database | Application; administrative account | Application account limited to its own database | wp-config.php on the server; password manager | 2026-10-01 |
| WordPress | 2 administrators, 3 editors | WordPress roles, 2FA for administrators | Client’s password manager | 2026-10-01 |
| Domain registrar | Business owner only | Owner’s account, 2FA | Client’s password manager | 2026-10-01 |
| DNS | Technical owner, Kol.ski on-call | Roles: zone editing, no billing access | Client’s password manager | 2026-10-01 |
| Repository | Technical owner, Kol.ski | Personal accounts, SSH keys | Client’s repository provider | 2026-10-01 |
| Revoked | Previous agency: 4 accounts, 1 SSH key, 1 FTP account | Removed 2026-09-15 | Confirmation in access/log.md | – |
3. Backups and restore
What and how often
Database daily, wp-content files daily incremental, a full copy once a week, a configuration copy (wp-config.php, .htaccess, DNS zone export) after every change. Retention: 30 daily and 12 monthly copies.
Where
Off the hosting, in object storage in the client’s account, encrypted. A second copy at the hosting provider, treated as extra, never as the only one. A copy on the same server as the site is not a backup.
Targets
Acceptable data loss (RPO): 24 hours. Recovery time (RTO): 1 hour, confirmed by a test. Last restore test: 2026-10-07, on the staging environment, 25 minutes, result in backups/restore-tests.md.
Restore procedure
- Freeze changes: maintenance mode on production, a note to the business owner.
- Fetch the copy from object storage (latest or the one specified) and verify the checksums.
- Restore the database into a new database and the files into a temporary directory; compare with production.
- Swap the directory and point
wp-config.phpat the new database; clear the caches. - Run the checklist from section 5: home page, subpages, login, form, e-mail, certificate.
- Record in
backups/restore-tests.md: date, copy, duration, who, result. Lift maintenance mode.
4. Emergency procedures
Every procedure has symptoms, steps and escalation. A critical failure is a site down, a break-in or a data leak; it is reported by phone, around the clock, with a response within 15 minutes. Everything else: e-mail or form between 8:00 and 20:00, response within an hour.
The site does not respond
Check the hosting status page and monitoring: server, DNS or certificate. Server: a ticket to the provider with the account number, meanwhile a stand-in page from the cache. DNS or certificate: the procedure below. No cause found after 30 minutes: restore from backup on the standby hosting.
Break-in or suspicious change
Cut off: change administrative passwords, log out all sessions, maintenance mode. Preserve: a copy of the current state for analysis, never overwriting the regular backups. Restore from the last clean copy, update everything, compare the files with the repository. Notify the business owner; where personal data is involved, assess a report to the data protection authority within 72 hours.
Expiring certificate or domain
Monitoring alerts 30 days ahead. Certificate: force the renewal in the hosting panel, check the chain. Domain: renewal by the business owner at the registrar, contact in the service card; after expiry there is the provider’s grace period, do not rely on it.
Forms are not delivered
Send a test submission, check the plugin’s sending log and the SMTP mailbox. Most often: a changed SPF or DKIM record, an expired app password, the e-mail provider’s limit. Until fixed, redirect the form to a backup mailbox and tell the business owner about the gap in submissions.
A failure after an update
Every update has a copy from before. Roll the plugin or theme back to the previous version from the copy, disable the cache, run the checklist. Report the bug to the plugin author, note it in the change log, repeat the update after the fix on staging.
Contacts and escalation
| When | Who | How |
|---|---|---|
| Critical failure | Kol.ski on-call | Phone, around the clock; response within 15 minutes |
| Other reports | Kol.ski | E-mail or form, 8:00–20:00; response within an hour |
| Server-side problem | Hosting provider | Help desk, account number example-prod; provider SLA 4 hours |
| Domain | Registrar | Business owner’s account |
| Business decisions, communication with customers | Business owner | Phone from the service card |
5. Updates and changes
- WordPress core, plugins and theme: reviewed weekly; updates go to staging first (a same-day copy of production), then to production in a window, with a copy taken before.
- Security updates: within 24 hours of release, outside the weekly rhythm.
- Every plugin has, in
plugins.md, the reason it exists and the person responsible for it. Plugins without a reason were removed at the handover: 7 of 18. - Change log
changelog.md: date, what, who, result, how to undo. No entry, no change. - Checklist after every change: home page, 3 subpages chosen by the client, login, form with confirmation, e-mail, certificate, response time.
6. Monitoring
| What | How often | Alert to |
|---|---|---|
| Site availability from two locations | Every minute | Kol.ski on-call; after 5 minutes also the technical owner |
| Certificate and domain validity | Daily | Kol.ski on-call 30, 14 and 7 days before expiry |
| Changes to core and plugin files outside an update | Daily | Kol.ski on-call |
| Administrative logins from new locations | Continuously | Kol.ski on-call and the technical owner |
| Backup completion and size | Daily | Kol.ski on-call when a copy failed or its size deviates |
| Form deliverability | Weekly, a test submission | Kol.ski on-call |
7. Acceptance checklist
- All access recovered, personal, with 2FA; the previous contractor’s accounts removed and confirmed.
- A backup taken off the hosting and restored on staging; recovery time recorded.
- Monitoring running; a test alert reached the on-call and the technical owner.
- Documentation in the client’s repository, secrets in the client’s password manager, nothing in the repository.
- Emergency procedures rehearsed with a person on the client’s side: one restore, one update rollback.
- Monthly costs and renewal dates known to the business owner.
- The date of the next access review and restore test in the calendar.
Handing over your site
Tell us what your site runs on and what is missing from this set: access, backups, procedures, documentation. We will propose a time.
The first conversation is free: 30 minutes online, no preparation and no commitment.