The Short Version
When you inherit a WordPress site, follow this checklist to secure access, verify backups, set up a staging environment, audit plugins, define deployment processes and plan ongoing maintenance.
- Gather all credentials and audit permissions.
- Confirm a recent, complete backup and test restoration.
- Create a staging site that mirrors production.
- Document every active plugin, theme and custom code.
- Establish version‑control and a deployment pipeline.
- Define a maintenance schedule and handover documentation.
1. Access – the foundation
Collect every account that can affect the site:
- Hosting control panel (cPanel, Plesk, cloud console).
- Domain registrar login.
- WordPress admin user with Administrator role.
- FTP/SFTP or SSH keys.
- Database credentials (usually in
wp‑config.php). - Any third‑party services (CDN, analytics, email, form integrations).
Record the exact usernames, email addresses and the method of authentication. If any credentials are shared, reset passwords and generate new SSH keys to avoid lingering access.
2. Backups – verify before you modify
Locate the most recent backup set. Typical locations are:
- Hosting provider snapshots.
- Plugins such as UpdraftPlus, BackupBuddy or WP‑Engine backups.
- External storage (Amazon S3, Google Drive).
Download the backup files and perform a test restore on a fresh server or local environment. This confirms both the completeness of the files and the integrity of the database.
3. Staging – a safe sandbox
Set up a staging site that is an exact copy of production:
- Clone the database and replace URLs (e.g.,
example.com→staging.example.com) usingwp search-replace. - Disable search engine indexing with
noindex, nofollowmeta tags or theDiscourage search enginesoption. - Restrict access to the staging domain via HTTP authentication or IP allow‑list.
All subsequent testing, plugin updates and code changes should happen on this environment before any production deployment.
4. Plugin and theme audit
Make a spreadsheet that lists every active plugin and theme, noting:
- Name and version.
- Source (WordPress.org, commercial vendor, custom).
- Last update date.
- Known conflicts or security advisories.
For custom code, locate the repository (if any). If the site was built without version control, initialise a Git repository now and commit the current state.
5. Deployment pipeline
A repeatable deployment process reduces risk. A minimal pipeline for a typical WordPress project might look like:
Manual FTP deployment
Upload changed files via FTP, then run wp db import for any database changes. Simple but error‑prone, especially with large sites.
Git‑based CI/CD
Push changes to a Git repository, trigger a CI job that runs composer install, builds assets, and deploys via SSH using rsync. Provides version history and rollback.
Choose the approach that matches the client’s tolerance for risk and the agency’s technical capacity. Document the exact commands and any environment variables required.
6. Ongoing maintenance
Set a cadence for routine tasks:
- Core, theme and plugin updates – at least once a month.
- Security scans – using plugins such as Wordfence or external services.
- Performance monitoring – Lighthouse scores, page‑load metrics.
- Backup verification – rotate backups and test restores quarterly.
Include a clear point of contact for emergencies and a process for logging issues (e.g., a shared Trello board or GitHub Issues).
Key Insight
Never push code directly to production without a staging test; a single unchecked plugin update is a common source of downtime.
7. Documentation – the handover artefact
Compile all the information above into a single, searchable document. Use headings that match the checklist items so future developers can jump straight to the relevant section. Include:
- Credential inventory (with placeholders for passwords).
- Backup location and restoration steps.
- Staging URL and access method.
- Plugin/theme audit table.
- Deployment workflow diagram.
- Maintenance schedule and contact list.
8. Legal and ownership considerations
Confirm who owns the licences for premium plugins and themes. Request transfer of any licences to the client or to the agency that will continue support. Record the licence keys in the credential inventory but keep them encrypted if stored digitally.
9. Performance and SEO sanity check
Run a full Lighthouse audit on both the staging and production sites. Note any differences in score that could indicate missing optimisation steps (e.g., missing image compression or caching headers). Verify that the robots.txt file on staging blocks crawlers.
10. Final sign‑off
Before declaring the handover complete, walk the client or their internal team through the documentation, demonstrate how to trigger a deployment, and confirm that they can access all required accounts.
Takeaway: a structured handover prevents surprise downtime
By following the checklist above you capture every access point, verify that backups work, isolate changes on a staging site and lock in a repeatable deployment process. The result is a transparent transition that protects the client’s brand and gives you a solid foundation for any future white‑label development work.
Need help putting this into practice?
Explore our WordPress Web Design, or tell us about your project so we can discuss the next step.
