You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This report analyzes ten submitted markdown files, each serving as a guide or checklist for a WordPress project handover. The documents are evaluated based on their comprehensiveness, clarity, actionability, and ability to mitigate risk for the incoming owner.
The most bare-bones document, serving as a simple question prompt.
File purpose & intent:
Canonical handbook - wordpress-complete-developer-handoff-guide.md as comprehensive.
Practical companion - wordpress-comprehensive-developer-handoff-guide.md as detailed.
Meeting-day checklist - wordpress-handover-checklist-comprehensive.md as checklist.
Detailed Analysis
1. wordpress-handover-protocol-definitive.md
What it does well:
Authoritative Tone: The document is written with a formal, academic tone that frames the handover not as a simple task, but as a critical process of risk mitigation. The use of citations reinforces its credibility.
Explains the "Why": Its greatest strength is the detailed prose that explains why each question is critical. It masterfully connects technical details (e.g., child themes, license keys) to business risks (e.g., security vulnerabilities, legal liability).
Comprehensiveness: It is exhaustive, covering strategy, legal frameworks, technical architecture, and operational protocols in immense detail.
Highlights Critical Risks: The document excels at identifying and flagging critical risks, such as the danger of an expired plugin license or an untested backup strategy.
Where it's lacking:
Actionability: Due to its density and prose-heavy format, it is less effective as a scannable checklist to be used during a live handover meeting. It's more of an educational document to be studied beforehand.
Excellent Structure: These guides are exceptionally well-organized, moving logically from high-level strategy to granular technical details and final execution steps.
Highly Actionable: They perfectly blend explanatory text with concrete, usable templates (Master Inventory, Plugin Audit, Deployment Runbook, etc.). This makes them ideal "living documents" for the handover process.
Risk-Focused: They explicitly highlight critical risks, such as editing parent themes or the absence of version control, and prescribe best practices.
Practical Tools: The inclusion of an "Exit Interview" section and a "Final Handover Checklist" provides practical tools for the most crucial parts of the transition.
Where it's lacking:
While extremely thorough, the explanatory prose is slightly less detailed than in the "Definitive Protocol," focusing more on the "how" than the deep "why."
3. wordpress-transfer-ownership-checklist.md
What it does well:
Balanced Approach: This document strikes a fantastic balance. It functions as a clear checklist while the "Detailed Considerations" sections provide essential context, explaining the importance of each area.
Clarity and Usability: The structure is clean and easy to follow. The combination of high-level topics, contextual notes, and specific questions makes it highly effective and efficient to use.
Actionable Templates: The inclusion of the Master Credentials and Plugin Audit tables makes it a practical tool for inventory and risk assessment.
Comprehensiveness: It covers all critical domains of a handover thoroughly without being overly verbose.
Where it's lacking:
It is nearly flawless as a checklist. Its only "lacking" area is that it doesn't provide the deep, narrative-style education of the top-ranked guides, which is a deliberate and effective design choice for its format.
Scannability: This document takes the comprehensive knowledge from the "Definitive Protocol" and formats it into a highly scannable and usable checklist with checkboxes.
Direct & Actionable: It is a pure, action-oriented questionnaire, making it perfect for use during a handover meeting to ensure nothing is missed.
Comprehensive: Because it's based on the most detailed guide, it covers all necessary topics thoroughly.
Where it's lacking:
It intentionally strips out the detailed explanatory prose found in its source document, making it less useful as a standalone educational tool. It is best used as a companion to the "Definitive Protocol."
Strong Due Diligence Focus: The guide excels in the early phases of a takeover, with a strong emphasis on legal, ownership, and strategic questioning.
Detailed Questioning: The questions are well-formulated to probe deep into the project's history and business context.
Where it's lacking:
It is more of a guide for inquiry and assessment than a complete operational protocol for executing the final handover. It lacks some of the actionable templates (e.g., deployment runbook, change log) found in the top-tier documents.
6. wordpress-handover-checklist-comprehensive.md
What it does well:
Good Templates: The inventory tables for credentials and plugins are well-designed and highly useful. The plugin audit table correctly identifies and flags risks.
Logical Structure: The checklist is organized into clear, logical sections.
Where it's lacking:
It contains very little explanatory text. It is a list of "what" to check, but offers little insight into "why" these items are important, making it less helpful for less experienced users.
Good Combination: It effectively combines introductory text explaining the importance of due diligence with a comprehensive checklist at the end.
Covers Key Areas: The checklist itself is thorough and touches on all the necessary points.
Where it's lacking:
The structure feels a bit disjointed, almost like two separate documents (a guide and a checklist) were combined. The flow isn't as seamless as the top-ranked documents.
8. wordpress-handoff-checklist-lite.md
What it does well:
Clarity and Simplicity: It's a clean, well-organized, and easy-to-read checklist.
Good for Simple Projects: For a straightforward website handover without complex integrations or legal issues, this checklist is efficient and covers the essential bases.
Where it's lacking:
It lacks depth, templates, and any explanation of risk or best practices. It is not suitable for complex or mission-critical projects.
9. wordpress-handoff-checklist-basic.md
What it does well:
Functional: It serves its purpose as a simple list of topics to discuss.
Where it's lacking:
It's a very simple list of questions with minimal structure. It offers no guidance, templates, or context. It's more of a topic list than a checklist.
10. wordpress-handoff-checklist-simple.md
What it does well:
Quick Prompt: It can serve as a very quick memory jogger for an experienced developer who just wants a list of question categories.
Where it's lacking:
This is the most bare-bones document. It lacks structure, detail, and guidance, making it the least useful for ensuring a truly comprehensive and secure handover.
A complete, practical guide for transferring a WordPress project from one team to another. It merges strategic, legal, operational, and technical handover material into one definitive reference, with checklists and templates you can use immediately.
A successful handover is not just a transaction of files and passwords; it is a comprehensive process of transferring knowledge, responsibility, and control. The stakes of a poorly executed handover are high: security vulnerabilities from lingering access, operational downtime due to unknown dependencies, legal liabilities from ambiguous ownership, and escalating costs from undocumented technical debt. This guide is designed to mitigate those risks.
Use this as a living document during the handover. Bring it to the handover meeting, check off items as you verify them, and keep the inventories up to date.
How to use this guide
Start with the Quickstart and Final Handover Checklist to frame the transfer.
Work top-to-bottom. Each section ends with concrete actions and data to collect.
Log every credential, license, and account in the Master Inventory table.
Security Protocol: Share credentials securely (e.g., via a password manager shared vault like 1Password/Bitwarden or a one-time secret link). Never send passwords via email.
Immediate Action: Change passwords and enable 2FA (Two-Factor Authentication) as soon as access is confirmed.
Final Step: Remove the outgoing developer’s access everywhere before you sign off.
Ownership: You have full administrative and legal control of the domain, DNS, hosting, WordPress, and all integrated services. Billing and renewal responsibility are in your accounts.
Access: All credentials are in your password manager. Every admin login tested successfully.
Security: Passwords rotated, 2FA enabled, previous access fully revoked, and API keys regenerated where applicable.
Backups: Verified working backups (stored off-site) and a documented, tested restore procedure.
Operations: Clear, documented deployment process, update cadence, and monitoring in place.
Knowledge: Architecture, customizations, dependencies, and “quirks” are documented; training delivered.
Strategic overview & History
Understand the purpose and history before changing anything. The technical architecture can only be judged against the business goals it was intended to achieve.
Core Purpose: What problem does the site solve? Primary objectives (e.g., e‑commerce, lead gen, publishing).
Audience: Who is the audience, and how has it evolved? What user personas were defined?
History & Evolution: Key milestones, major feature additions, pivots, redesigns, or platform migrations.
Rationale: A project's history often reveals its compromises. Understanding historical pivots (e.g., a site that had e-commerce "bolted on" later) helps uncover technical debt and anticipate areas of fragility.
KPIs: KPIs for success (conversions, revenue, engagement) and how they’re measured.
Business Rules & Compliance: Any unique business rules, compliance constraints (e.g., industry-specific regulations), or seasonal patterns.
ACTIONS:
Capture the answers above in the project notes.
Identify any misalignments between current architecture and business goals.
Stakeholders & roles
Map the influence and responsibility network to ensure clear communication.
Key Personnel: Decision makers and points of contact (product, content, marketing, tech).
Workflows: Approval workflow for content and technical changes; escalation path for incidents.
Historical Knowledge: Who managed discovery/planning? (These individuals can clarify historical decisions and original requirements).
Post-Handover Management: Who will own the site post-handover (content management, technical maintenance, business decisions).
ACTIONS:
Record stakeholder list with roles and contact info.
Agree on post-handover support window (duration, scope, rates) and communication channels.
Ownership & legal
This is critical. Failure to secure unambiguous ownership of all assets can have catastrophic long-term consequences.
Intellectual Property (IP): Written confirmation of 100% ownership of website, content, custom code, graphics, design elements, and data upon final payment. This is non-negotiable. Identify exceptions (e.g., stock photos).
Licenses: List of all premium themes/plugins and other software licenses.
Rationale: Active licenses are crucial for receiving security updates and support. Expired licenses leave the site vulnerable. Detail transfer or repurchase requirements.
Contracts and SLAs: Ongoing obligations (hosting, maintenance, support); renewal dates, costs, and billing contacts.
Privacy Compliance (GDPR/CCPA): Data collection points (forms, e-commerce), PII (Personally Identifiable Information) storage location and security, retention policies, cookie consent mechanisms, and data sharing agreements.
ACTIONS:
Secure written confirmation of IP transfer.
File copies of agreements; update billing to new owner.
Populate license inventory (Appendix) with keys, renewal dates, and accounts.
Review privacy compliance documentation.
Domain & DNS
Control over the domain registrar and DNS is paramount. Losing control can result in the loss of the domain name.
Rationale: This defines the level of control and performance isolation (e.g., Shared hosting risks "noisy neighbors"; Managed hosting may restrict plugins).
Resource Limits: CPU, RAM, storage, bandwidth. Crucially, PHP memory limits and execution time limits (insufficiency causes errors).
Server Stack & Versions: OS, Web server (Apache/Nginx), PHP + required extensions, MySQL/MariaDB. Control panel (cPanel/Plesk/custom).
Server‑level Security: Web Application Firewall (WAF/ModSecurity), firewall rules, IP restrictions, and allowlists.
Custom Configurations: Any modified php.ini settings, custom .htaccess or nginx.conf rules.
ACTIONS:
Verify access to hosting dashboard and control panel.
Enable 2FA on the hosting account.
Document any non‑standard server configs and required PHP extensions (crucial for future migrations).
Database access & structure
The database stores all content, settings, and user information.
Connection Details: DB host, port, engine/version, database name(s), users and privileges.
Access Method: (phpMyAdmin, Adminer, CLI) and credentials.
Structure: Any custom tables or stored procedures beyond standard WordPress schema (document purpose and schema).
Maintenance: Optimization procedures or cleanup routines for logs/temporary data.
ACTIONS:
Perform a read‑only smoke check of DB access.
Export schema for reference.
Rotate database user passwords.
WordPress access & user management
Ensure a clean audit trail and secure access control by enforcing the Principle of Least Privilege (PoLP).
New Administrator Account: Provide a NEW administrator account for the new owner/team. Do not re‑use existing logins.
User Inventory: Review all users and roles (Admins, Editors, Authors, etc.). Identify accounts to remove or demote.
PoLP Enforcement: Ensure users only have the minimum access required for their role (e.g., writers do not need plugin installation access).
Permissions: Special file permissions (ownership settings, permissions for uploads/cache directories).
SSH Specifics: Sudo privileges and restrictions; location of authorized_keys.
ACTIONS:
Exchange SSH public keys via a secure channel; validate login and permissions.
Store keys and connection profiles in your password manager.
Remove previous developer's SSH keys and FTP accounts.
Email configuration
Document both domain email hosting (mailboxes) and transactional email paths (website-sent emails).
Domain Email Hosting: Where mailboxes are hosted (e.g., Google Workspace/365/hosted). Admin access, account list, alias/forward rules.
Transactional Email Path: How the website sends emails (WordPress default mail, SMTP plugin, or service like SendGrid/Postmark).
Credentials/API Keys: SMTP settings or API keys for the transactional service.
ACTIONS:
Verify SPF, DKIM, DMARC records are correctly configured (See Domain & DNS section).
Document SMTP settings and rate limits.
Regenerate transactional email API keys or SMTP passwords.
Technical Architecture: Themes, Plugins, and Custom Code
Understanding how the website was built is a prerequisite for maintaining and extending it. This section creates the technical blueprint.
Source Code Version Control (Git)
The use of Git is a hallmark of professional development.
Repository: Location (GitHub, Bitbucket, GitLab) and access.
Rationale: The absence of version control is a major red flag, suggesting risky "cowboy coding" practices (e.g., editing live via FTP).
Branching Model: Strategy used (e.g., GitFlow, feature branches). Which branch represents production?
History: Confirm the repository contains the complete commit history.
Theme Structure
The theme controls visual presentation. How it is structured impacts future updates.
Active Theme: Is it commercial (provide source/license) or custom?
Parent/Child Usage: Confirm a child theme is used for all customizations.
CRITICAL RISK: Modifications made directly to a parent theme will be overwritten during updates. If the parent theme is edited, the site becomes difficult or impossible to update safely.
Customization Locations: Where custom CSS, JavaScript, and PHP are stored.
Plugin Ecosystem
Plugins add functionality but also complexity and potential points of failure.
Inventory: Complete list (active/inactive) with version, purpose (rationale for choice), premium/free status, and license details.
Known Issues: Any known conflicts or performance bottlenecks.
Custom Plugins: Any plugins developed specifically for the site. Where is the source code and documentation?
Custom Development & Content Structure
Code Locations: Custom PHP in functions.php, code snippets plugins, or custom theme files.
Content Structure: Custom post types (CPTs), taxonomies, and custom fields (e.g., ACF). How were they created (plugin or code)? How are configurations managed (e.g., ACF JSON sync)?
Page Builders: If used (e.g., Elementor, Divi), document global settings and templates.
Coding Standards: Were WordPress Coding Standards followed? Is the code well-commented?
Rationale: Uncommented code is significantly more expensive and risky to maintain.
ACTIONS:
Populate the Plugin & Theme Audit table (Appendix), highlighting risks.
Verify child theme usage and integrity of parent theme files.
Confirm access to the Git repository and understand the branching strategy.
Third‑party services & integrations
Modern websites are ecosystems of interconnected services. Each requires ownership transfer.
Inventory: Comprehensive list of all integrated services:
Document the exact steps required to "clear all caches" across every layer (Plugin, Server, CDN).
Review CDN configuration and page rules.
Analytics & SEO
Tools for understanding traffic, user behavior, and search performance.
Access: Administrative access to Google Analytics (GA4), Google Tag Manager (GTM), and Google Search Console (GSC).
Tracking Implementation: E-commerce tracking, custom events, goals, and cross-domain tracking.
SEO Configuration: SEO plugin used (Yoast/RankMath), XML sitemap location, meta templates, schema markup implementation.
Status: Current rankings and any history of Google penalties or manual actions.
ACTIONS:
Verify property ownership and administrative access to all tools.
Confirm data streams are active.
Capture baseline metrics before making changes.
Environments, version control & deployment
The process of moving changes to the live site is risk-prone. A disciplined, documented workflow is essential for stability.
Environments
List: Development and Staging sites (URLs, access details).
Rationale: A staging site is crucial for testing updates safely. The absence of one indicates high-risk practices (testing on production).
Sync Procedures: How environments are synchronized (files and database).
Version Control (Git)
See also Technical Architecture section
Repository Access & Branching Model.
Deployment Process
Procedure: The exact, step-by-step process from commit to production (manual vs. automated/CI/CD).
RISK: An ad-hoc, undocumented, memory-based process (e.g., "I FTP these three files...") is fragile, highly susceptible to human error, and a massive operational risk.
Database Changes: How database changes are managed and migrated between environments (e.g., migration scripts, plugins like WP Migrate DB Pro). DB sync is complex and must be documented.
Checklists: Pre-deploy testing checklist and rollback procedures for failed deployments.
ACTIONS:
Document an end‑to‑end deployment runbook (See Appendix for template).
Confirm the staging environment is functional and synchronized.
Strictly avoid making changes via FTP directly to production.
Documentation & training
Comprehensive documentation and training are the bridge to confident, independent management.
Existing Documentation: Technical specs, architecture diagrams, admin user manuals, brand/style guides. Where is it stored?
Rationale: The existence and quality of documentation are strong indicators of a project's health.
Training: Video walkthroughs for common tasks (publishing content, managing products) and custom workflows.
Known Issues: Documentation of known bugs and technical debt.
ACTIONS:
Consolidate all documentation in a central location (e.g., with the repository or a knowledge base).
Schedule a live training/Q&A session.
Maintenance & monitoring
A website requires continuous care. Outdated software is the leading cause of WordPress vulnerabilities.
Update Cadence: Established schedule for WordPress core, theme, and plugin updates.
Testing Procedures: Updates must be tested on staging before being applied to the live site.
Alerts: Who receives alerts if the site goes down or errors occur?
ACTIONS:
Establish a regular maintenance schedule and testing process.
Set up monitoring tools and configure alerting thresholds/recipients.
Final handover checklist
Use this on handover day. Confirm each item before signing off.
Schedule and conduct the formal handover meeting.
Verify Admin Access (Log into every service):
Domain Registrar
DNS Provider (e.g., Cloudflare)
Hosting Control Panel
WordPress Admin Dashboard
SFTP/SSH
Database (e.g., phpMyAdmin)
Email Services (Domain and Transactional)
CDN/WAF
Analytics & SEO Tools (GA, GSC, GTM)
Payment Gateways
Marketing/CRM tools
Git Repository
All other third‑party services listed in the Inventory.
Secure Accounts:
Change ALL passwords and store them in a secure password manager.
Rotate ALL API keys and tokens.
Enable 2FA on all services that support it.
Revoke Previous Access:
Remove/demote the previous developer’s access from ALL systems listed above.
Validate Operations:
Validate backups are running and stored off-site.
Perform a test restore on staging.
Smoke‑test critical user journeys (purchase/checkout, contact forms, login, search).
Confirm Configuration:
Confirm monitoring/alerts are going to the correct recipients.
Update the Master Inventory with final ownership status and renewal details.
Exit interview questions
Ask these open‑ended questions to uncover “unknown unknowns” and institutional knowledge often missed in checklists.
Fragility: What do you consider the most fragile or complex parts of the site? Are there any known pitfalls or stability issues?
Technical Debt: If you had more time or budget, what would you improve or refactor first, and why? (This reveals the developer's assessment of technical debt).
Quirks & Workarounds: Are there any quirks, oddities, or manual workarounds we absolutely must know about? (e.g., "To update X, you have to do this one weird thing first.") This is often the most valuable question.
Lessons Learned: What were the biggest challenges during development (plugin conflicts, brittle integrations, environment gotchas)? What lessons did you learn?
Appendix: Inventories & templates
Use these tables as your single source of truth. Keep them current.
Master Credentials & Services Inventory
Instructions: Fill a row for every integration. Use a secure method for sharing credentials. After transfer, regenerate API keys/tokens and mark status as ✅ Completed.
Service/Platform
Purpose
Login URL
Username/Email
Password/Key Location
Cost
Renewal Date
Owner
Transfer Status
WordPress Admin
CMS
domain.com/wp-admin
new_admin_user
Password Manager
—
—
New Owner
⏳ Pending
Domain Registrar
Domain Control
[URL]
[Email]
Password Manager
$/yr
YYYY‑MM‑DD
New Owner
⏳ Pending
DNS Provider
DNS/WAF/CDN
[URL]
[Email]
Password Manager
$/mo
Monthly
New Owner
⏳ Pending
Hosting
Server/cPanel
[URL]
[Email]
Password Manager
$/yr
YYYY‑MM‑DD
New Owner
⏳ Pending
SFTP/SSH
File Access
[Host/IP]
[User]
SSH Key/PM
—
—
New Owner
⏳ Pending
Database
Data Storage
[URL/Host]
[User]
Password Manager
—
—
New Owner
⏳ Pending
Email (Domain)
Mailboxes
[URL]
[Email]
Password Manager
$/mo
Monthly
New Owner
⏳ Pending
Email (Transactional)
Website Emails
[URL]
[Email]
API Key in PM
$/mo
Monthly
New Owner
⏳ Pending
Backup Service
Backups
[URL]
[Email]
Password Manager
$/mo
Monthly
New Owner
⏳ Pending
Analytics (GA/GTM)
Tracking
[URL]
[Email]
Password Manager
—
—
New Owner
⏳ Pending
Payment Gateway
Payments
[URL]
[Email]
Password Manager
Fees
—
New Owner
⏳ Pending
Git Repository
Version Control
[URL]
[Email]
Password Manager/SSH
$/mo
Monthly
New Owner
⏳ Pending
Plugin & Theme Audit & Risk Assessment
Component
Type
Version
Purpose
Premium?
License Status
Renewal Date
Notes/Risks/Dependencies
[Theme Name]
Parent Theme
x.x.x
Base framework
Premium
Active
YYYY‑MM‑DD
Core visual framework. DO NOT edit directly.
[Child Theme Name]
Child Theme
x.x.x
Customizations
Custom
N/A
N/A
All customizations (CSS/PHP) live here.
WooCommerce
Plugin
x.x.x
E‑commerce
Free
N/A
N/A
Critical for sales; complex settings. Test updates thoroughly.
Wordfence
Plugin
x.x.x
Security/WAF
Premium
Active
YYYY‑MM‑DD
Firewall rules configured. Do not deactivate.
WP Rocket
Plugin
x.x.x
Caching
Premium
Active
YYYY‑MM‑DD
Key for site speed. Purge after deployment.
ACF PRO
Plugin
x.x.x
Custom fields
Premium
Expired/Missing
YYYY‑MM‑DD
CRITICAL RISK: Site depends on this. Cannot update without a valid license.
Classic Editor
Plugin
x.x.x
Editor UI
Free
N/A
N/A
Indicates site may not be compatible with Block Editor (Technical Debt).
New Owner/Incoming Representative: ____________________
Conclusion
A successful handover delivers complete control, deep system knowledge, and safe, repeatable operations. It is built on three principles: Complete Ownership Transfer, Comprehensive Knowledge Transfer, and Documented Operational Procedures. The handover is only complete when ownership is fully transferred, all credentials have been rotated, previous access is revoked, and critical operational paths (backups, deployment) have been tested end‑to‑end.
A complete, practical guide for transferring a WordPress project from one team to another. It merges strategic, legal, operational, and technical handover material into one definitive reference, with checklists and templates you can use immediately.
Use this as a living document during the handover. Bring it to the handover meeting, check off items as you verify them, and keep the inventories up to date.
How to use this guide
Start with the Quickstart and Final Handover Checklist to frame the transfer.
Work top-to-bottom. Each section ends with concrete actions and data to collect.
Log every credential, license, and account in the Master Inventory table.
Change passwords and enable 2FA as soon as access is confirmed.
Remove the outgoing developer’s access everywhere before you sign off.
Ownership: You have full administrative control of domain, DNS, hosting, WordPress, and all integrated services. Billing and renewal responsibility are in your accounts.
Access: All credentials are in your password manager. Every admin login tested successfully.
Security: Passwords rotated, 2FA enabled, previous access fully revoked, and keys regenerated where applicable.
Backups: Verified working backups and a tested restore procedure.
Operations: Clear, documented deployment process, update cadence, and monitoring in place.
Knowledge: Architecture, customizations, and “quirks” are documented; training delivered.
Strategic overview
Understand the purpose and history before changing anything.
What problem does the site solve? Primary objectives (e.g., e‑commerce, lead gen, publishing).
Who is the audience, and how has it evolved?
Key milestones, major feature additions, pivots, or redesigns.
KPIs for success (conversions, revenue, engagement) and how they’re measured.
Any unique business rules, compliance constraints, or seasonal patterns.
Actions
Capture the answers above in the project notes.
Identify any misalignments between current architecture and business goals.
Stakeholders & roles
Decision makers and points of contact (product, content, marketing, tech).
Approval workflow for content and technical changes; escalation path for incidents.
Who managed discovery/planning; who will own the site post-handover.
Actions
Record stakeholder list with roles and contact info.
Agree on post-handover support window and communication channels.
Ownership & legal
Written confirmation of 100% ownership of website, content, custom code, and data upon final payment.
List of premium themes/plugins and other licenses; transfer or repurchase details.
Contracts and SLAs (hosting, maintenance, support); renewal dates and costs.
Privacy compliance (GDPR/CCPA): data collection points, storage, retention, and policies.
Actions
File copies of agreements; update billing to new owner.
Populate license inventory with keys, renewal dates, and accounts.
Domain & DNS
Registrar, account owner, renewal date, and auto‑renew status.
DNS provider (registrar, Cloudflare, etc.) and complete record set (A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification records).
Subdomains, redirects, staging domains, and special rules.
Actions
Gain registrar and DNS admin access; transfer account ownership where needed.
Export current DNS zone file and attach to this document.
Hosting & server infrastructure
Hosting provider, plan name, cost, renewal date, and geographic region.
Environment type (shared, VPS, dedicated, managed WordPress) and resource limits (CPU, RAM, storage, bandwidth, PHP memory/time limits).
Server stack and versions (OS, Web server, PHP + extensions, MySQL/MariaDB), control panel (cPanel/Plesk/custom).
Server‑level security (WAF/ModSecurity), firewall rules, and any allowlists.
Actions
Verify access to hosting dashboard and server console (as applicable).
Document any non‑standard server configs and required PHP extensions.
Database access & structure
DB host, port, engine/version, database name(s), users and privileges.
Access method (phpMyAdmin, Adminer, CLI) and credentials.
Custom tables or stored procedures beyond standard WordPress schema.
Backup schedule, retention, and restore process.
Actions
Perform a read‑only smoke check of DB access; export schema for reference.
WordPress access & user management
Provide NEW administrator account for the new owner/team. Do not re‑use existing logins.
Inventory of all users and roles; identify accounts to remove or demote.
A successful handover delivers complete control, deep system knowledge, and safe, repeatable operations. Use this guide, keep inventories current, and validate backups and access regularly. The handover is complete only after ownership is transferred, credentials are rotated, previous access is revoked, and critical paths are tested end‑to‑end.
Handing over a WordPress website is not only about sharing files and passwords. It is about making sure the new owner has everything they need to run, update, and grow the site without surprises.
Project intent and purpose
Why was this website built?
What was the main goal (e.g., sell products, share information, get leads, etc.)?
Who is the website for?
What demographic? Who are the main users or customers?
How has the website changed over time?
Any big updates or changes that drastically changed the direction?
How do you measure success?
What numbers or results matter most (e.g., sales, signups, visits, etc.)
Responsibilities and roles
Who manages the website now?
Who makes decisions and who updates content?
Who helped plan the website?
Anyone important to know about for future questions?
Ownership and legality
Do we fully own the website, code, and content after payment?
Are there any ongoing contracts (e.g. hosting, support, etc.)?
Are there any paid themes or plugins?
Please list them, with license info and renewal dates.
How is user data handled?
Are there privacy policies or special rules to follow?
Provide login details for where the site is hosted.
Storage or database access:
SFTP/SSH and database login info.
Domain hosts and addresses:
Login for where the domain is registered.
List all additional services in use…
List all connected services (email, payments, analytics, etc.) with logins or transfer steps.
Security measures
Share passwords securely ( not by email).
Change passwords and enable two-factor auth (after handover).
Remove old users and review user access levels.
Implementation & current state
Is the code in a version control system (like Git)?
If yes, share access.
What theme is used?
Is it custom or from a marketplace? Is a child theme used for changes?
List of plugins:
What do they do? Are any custom-built?
Any custom code?
Where is it and what does it do?
How is content organized?
Any special post types, fields, or page builders used?
Hosting & deployments
Who is the hosting provider?
What plan are we on?
What are the limits?
e.g. storage, bandwidth, etc.
How do you update the live site?
Please describe the steps.
Are there established environment?
e.g. dev, test, stage and/or prod?
Is caching enabled or are you using a CDN?
If not automatic, outline how to clear the server cache.
PHP/MySQL versions? etc.
List current semver's and any other version constraints.
Who provides the SSL certificate?
Does it renew automatically?
Backups & security
What security plugins or tools are used?
How are user roles and permissions managed?
How are backups handled?
How often, where are they stored, and how do we restore them?
Any past security issues?
How were they fixed?
Maintenance & monitoring
How often are updates done (WordPress, themes, plugins)?
How are updates tested before going live?
Do we have access to Google Analytics and Search Console?
Is uptime or performance monitored?
Who gets alerts if the site goes down?
Documentation & training
Can you provide a training session or video walkthroughs for common tasks?
Is there any documentation or guides?
Where can we find them?
Additional information
Go through the checklist together and confirm all accesses.
Remove old users.
Change all passwords.
Enable two-factor authentication (2FA).
Set a date for the final handover.
Due on 08/14/2025
Final questions
Are there any tricky parts or things to watch out for?
If you had more time, what would you improve?
Are there any odd workarounds or “gotchas” that we should be aware of?
What were the biggest challenges and/or lessons learned?
Conclusion
A good handover means the new owner has full control, understands how everything works, and knows how to keep the site running smoothly. Use this checklist to make sure nothing is missed and everyone feels confident moving forward.
How do I access the hosting account (e.g., control panel URL, username, password)?
Are there any multi-factor authentication (MFA) or additional security measures in place?
Server Details
What type of hosting plan is being used (e.g., shared, VPS, dedicated)?
What is the server operating system (e.g., Linux, Windows)?
Are there any specific server configurations or settings I should be aware of (e.g., PHP version, memory limits, caching setups)?
Domain and DNS
Is the domain registered through the hosting provider or a separate registrar?
How do I access the domain management panel (if separate)?
Are there any custom DNS settings or records that need to be maintained?
2. WordPress Website
Admin Access
What is the URL for the WordPress admin dashboard?
What are the admin login credentials (username and password)?
Are there any additional security measures for the admin area (e.g., 2FA, IP restrictions)?
Themes and Plugins
Which theme is currently active, and is it a custom or third-party theme?
Are there any child themes in use?
What plugins are installed and activated? Are there any custom or premium plugins?
Are there specific versions of themes or plugins that must be maintained for compatibility?
Customizations
Are there any custom code modifications in the theme or plugins (e.g., via functions.php or custom templates)?
Are there any custom post types, taxonomies, or fields (e.g., via ACF or other plugins)?
Is there any custom CSS or JavaScript added to the site (and where is it located)?
3. SSH and Server Access
SSH Provider and Credentials
Is SSH access provided through the hosting service or a separate provider?
What are the SSH login credentials (username, password, or key file)?
What is the SSH host address and port number?
Are there any specific SSH configurations or commands I should use to connect?
File System Access
What is the root directory path for the WordPress installation?
Are there any specific directories or files that require special permissions?
Is there an SFTP or FTP setup in addition to SSH, and if so, what are the credentials?
4. Database Access
Database Details
What is the name of the WordPress database?
What are the database credentials (username, password, host)?
How do I access the database (e.g., via phpMyAdmin, command line)?
Database Management
Are there any custom tables or database modifications beyond standard WordPress?
Is there a backup schedule for the database, and how can I access or restore backups?
5. Custom Configurations and Server Files
Custom Server Files
Are there any custom PHP files outside of the WordPress core (e.g., in the root directory)?
Are there modifications to the .htaccess file (for Apache) or nginx.conf (for Nginx)?
Are there any cron jobs or scheduled tasks set up on the server?
Environment-Specific Settings
Are there different configurations for development, staging, and production environments?
Is there a wp-config.php file with custom constants or settings?
6. Backup, Updates, and Security
Backup Procedures
What is the current backup strategy for the website (e.g., frequency, storage location)?
Are backups automated, and if so, how can I access or manage them?
Update Schedule
How are updates handled for WordPress core, themes, and plugins (e.g., manual or automatic)?
Is there a specific time or process for applying updates to avoid downtime?
Security Measures
What security plugins or measures are in place (e.g., firewalls, malware scanners)?
Are there any custom security configurations (e.g., in .htaccess or server settings)?
Is SSL/TLS enabled, and how is the certificate managed (e.g., auto-renewal)?
7. Development Workflow and Version Control
Staging and Testing
Is there a staging or development environment? If so, how do I access it?
What is the process for testing changes before deploying to the live site?
Version Control
Is version control (e.g., Git) used for the project? If so, where is the repository hosted (e.g., GitHub, Bitbucket)?
What is the branching strategy (e.g., main branch for production, feature branches for development)?
Are there any specific deployment scripts or tools used to push changes to the server?
Documentation
Is there any existing documentation for the project (e.g., setup guides, code comments)?
Are there any known issues or bugs that need attention?
8. Additional Information
Third-Party Integrations
Are there any third-party services integrated with the website (e.g., payment gateways, APIs, email services)?
What are the credentials or API keys for these services, and where are they stored?
Monitoring and Analytics
Is there any monitoring or analytics setup (e.g., Google Analytics, server monitoring tools)?
How can I access these tools or reports?
Client or Team Access
Are there other team members or clients who have access to the website or hosting?
What are their roles and permissions?
By gathering answers to these questions, the new developer will have all the necessary information to take over the WordPress project effectively, ensuring continuity and minimizing disruptions.
WordPress Project Handover: Comprehensive Due Diligence Checklist
A successful WordPress handover is not just about sharing files and passwords—it's a process of transferring knowledge, responsibility, and control. This checklist combines strategic, technical, operational, and legal considerations to ensure a seamless transition and minimize risks for the new owner.
CRITICAL RISK - Site layouts depend on this. CANNOT UPDATE WITHOUT a valid license.
❌
Really Simple SSL
Plugin
7.0.5
Manages SSL certificate
Free
N/A
Redundant - Hosting provides SSL. Can likely be removed after verification.
❌
Classic Editor
Plugin
~1.6.3
Disables Gutenberg editor
Free
N/A
Indicates site may not be compatible with modern block editor. Creates technical debt.
Tip: Attach all relevant files (configurations, SSH keys, documentation, license files) and ensure all credentials are up to date and securely stored.
Conclusion
A robust handover ensures the new owner has full control, understands the website's architecture and processes, and is equipped to maintain and grow the site with confidence. Use this checklist to guide the transition, reduce risk, and set the stage for long-term success.
WordPress Project Handoff: Complete Due Diligence Guide
A successful WordPress project handover is not just about sharing files and passwords—it's a comprehensive process of transferring knowledge, responsibility, and control. This guide provides a structured approach to ensure a seamless transition while minimizing risks and establishing a solid foundation for future management.
A successful WordPress handover is built on three fundamental principles:
Complete Ownership Transfer - Full legal and administrative control of all digital assets
Comprehensive Knowledge Transfer - Deep understanding of technical architecture and business context
Documented Operational Procedures - Clear, tested processes for ongoing maintenance and development
By systematically working through this guide, you transform a potentially risky handover into a foundation for long-term success. The upfront investment in due diligence pays dividends in reduced future costs, improved security, and confident independent management of your digital asset.
Remember: A handover is not complete until you have verified access to every system, changed all credentials, removed previous developer access, and tested critical functionality. Take the time to do it right—your website's future health depends on it.
The handover of a WordPress project is a critical inflection point in the lifecycle of a digital asset. It is frequently misconstrued as a simple, transactional event involving the exchange of files and passwords. This perspective is dangerously incomplete. A successful handover is not an event but a comprehensive process of knowledge transfer, moving far beyond the delivery of technical components to encompass the full strategic, legal, and operational context of the website[^1]. The ultimate objective is to de-risk the transition by eliminating dependency on the departing developer, thereby empowering the new owner with complete and unencumbered autonomy over their digital property.
The stakes of a poorly executed handover are exceptionally high. An incomplete transfer can precipitate a cascade of negative consequences that manifest long after the original developer has departed. These risks include severe security vulnerabilities stemming from lingering, unauthorized access to critical systems[^3]; operational downtime caused by unknown dependencies or undocumented, fragile workflows[^5]; significant legal liabilities arising from ambiguous ownership of intellectual property or non-compliance with data privacy regulations[^6]; and escalating future costs as the new team grapples with undocumented technical debt that is difficult and expensive to remediate[^8]. Many of these issues can be traced back to a failure to ask the right questions at the right time.
This guide provides a structured, exhaustive set of questions designed to serve as a definitive due diligence protocol for any WordPress project handover. It is engineered to be a practical tool, enabling the incoming owner or team to proactively identify, assess, and mitigate the myriad risks inherent in the transition process. By systematically addressing each area—from high-level strategy to the most granular technical detail—the new owner can ensure a truly complete and seamless transfer of control, establishing a firm foundation for the future management, maintenance, and growth of the website.
Before any technical examination of the website can be meaningful, it is imperative to establish a deep understanding of its business context. The technical architecture, features, and code are merely instruments designed to serve a strategic purpose. Their quality and appropriateness can only be judged against the business goals they were intended to achieve. This section provides the questions necessary to uncover the why behind the website, clarifying its purpose, history, stakeholders, and the legal framework that governs it.
Understanding the original intent and historical evolution of a project is fundamental. It provides the context for all subsequent technical decisions and can reveal architectural layers or features that may no longer align with the current business strategy. This historical perspective is a map to understanding the site's current state and its potential hidden complexities.
What was the original business problem this website was built to solve? What were the primary goals and objectives defined at the project's inception?
This foundational question seeks to establish the core rationale for the website's existence[^2]. A clear answer, such as to generate qualified leads for our consulting services or to sell handmade goods directly to consumers, provides a lens through which all features and design choices can be evaluated. A vague or non-existent answer may indicate a lack of strategic direction from the outset, which can often translate into a disjointed and ineffective website.
Who was the target audience defined at the project's outset, and has that audience evolved over time?
A website's design, content, and functionality should be tailored to its intended users[^5]. Understanding the defined audience helps assess the appropriateness of the user experience (UX) and user interface (UI). Furthermore, inquiring about the evolution of this audience can highlight areas where the site may need to be adapted to meet new user needs or demographic shifts.
Can you provide a brief history of the project, including key milestones, major feature additions, or significant strategic pivots?
This question is not merely about creating a timeline; it is a powerful diagnostic tool for uncovering technical debt[^1]. A project's history is often a story of its compromises. For example, a website that began as a simple brochure site and later had e-commerce functionality bolted on may suffer from significant architectural weaknesses. The theme may not be optimized for online sales, or the chosen e-commerce plugin might be poorly integrated, leading to performance issues and maintenance nightmares. Understanding these historical pivots allows the new owner to probe deeper into the implementation of major features and anticipate areas of fragility that are not immediately apparent from a surface-level review.
What were the key performance indicators (KPIs) used to measure the website's success?
Knowing the metrics that matter—such as lead conversion rates, average order value, or user engagement time—clarifies what aspects of the site are considered most valuable[^2]. This information is crucial for prioritizing future development efforts and ensuring that any changes made do not negatively impact the site's primary commercial or strategic functions.
A website does not exist in a vacuum. It serves and is managed by a network of individuals, each with their own set of expectations and responsibilities. Identifying these stakeholders is essential for establishing clear lines of communication and understanding the project's internal political landscape.
Who are the key internal and external stakeholders involved with the website? Who has the final authority for approving changes?
This question aims to create a definitive map of influence and responsibility[^1]. The answer should identify the project owner, marketing team members, content editors, and any other individuals who have a vested interest in the site's operation. Crucially, it must clarify the approval workflow, which will prevent future delays and conflicts when changes need to be implemented.
Which stakeholders were involved in the original 'Discovery' or research phase of the project?
The initial research or Discovery phase is where the foundational requirements and strategies for a project are established[^10]. Identifying the participants of this phase provides a direct line to the sources of the original project vision. If questions arise later about why a particular feature was built in a certain way, these are the individuals who will likely hold the answer.
The handover process involves the transfer of a valuable business asset, and with it comes a host of commercial and legal responsibilities. Failing to clarify these details can lead to severe financial and legal repercussions, including loss of ownership, unexpected costs, and data privacy violations.
Can you confirm in writing that upon final payment, our organization will have 100% ownership of the website, its design, all custom-developed code, and all content created specifically for the project?
This is arguably one of the most critical questions in the entire handover process. It directly addresses the fundamental issue of asset ownership[^7]. Ambiguity in contracts or verbal agreements has led to numerous disputes where developers claim ownership of the work, effectively holding the client's website hostage[^11]. A clear, written confirmation of a complete transfer of intellectual property rights is non-negotiable.
Are there any third-party or premium software licenses (for themes, plugins) that need to be transferred or repurchased? Please provide a comprehensive list of all such software, including license keys, original purchase dates, renewal dates, and annual costs.
Modern WordPress sites are often built upon a foundation of premium themes and plugins. These components require active licenses to receive crucial security updates and technical support[^5]. If these licenses are registered to the departing developer, they may expire without the new owner's knowledge, leaving the site vulnerable to security exploits or causing critical features to cease functioning. A complete inventory of these licenses is essential for both security and financial planning.
Are there any ongoing service level agreements (SLAs), hosting contracts, or other contractual obligations with your company or external third parties that we will be inheriting?
This question aims to uncover any hidden or recurring financial commitments associated with the website[^1]. The new owner must be aware of all contracts they are assuming, whether for specialized hosting, maintenance retainers, or other third-party services. This prevents unexpected invoices and ensures continuity of essential services.
What data privacy agreements or policies are in place to comply with regulations such as GDPR or CCPA? Where is user data stored, and what measures are in place to protect it?
In the modern regulatory environment, data privacy is a significant area of legal liability[^6]. The new owner must understand how the website collects, stores, and manages personally identifiable information (PII). This includes data from contact forms, e-commerce transactions, and user registrations. The developer should be able to point to the relevant privacy policy pages and explain the technical safeguards that have been implemented to ensure compliance.
# Part II: The Keys to the Kingdom: Access, Credentials, & Third-Party Services
This section constitutes a non-negotiable inventory of all access points required to control the website and its surrounding ecosystem. The primary goal is to achieve full, exclusive administrative control over every component. A handover cannot be considered complete until every credential has been securely transferred and the previous developer's access has been systematically and verifiably revoked from every platform. Failure to do so represents a critical and ongoing security risk[^3].
These are the fundamental access points for managing the website's content, hosting environment, and domain name. Without these, the new owner is effectively locked out of their own property.
Please provide credentials for a new, unique Administrator-level user for the WordPress dashboard.
It is a critical best practice to never take over an existing user account[^8]. A new, dedicated administrator account should be created for the new owner. This ensures a clean audit trail and prevents any ambiguity about who performed which actions. Once the new owner has confirmed their access, all other administrator accounts, including the one used by the departing developer, should be demoted or deleted.
What are the login details for the website's hosting control panel (e.g., cPanel, Plesk, or a custom provider dashboard)?
The hosting control panel is the gateway to the server environment. It allows for the management of files, databases, email accounts, and other server-level configurations[^8]. Access to this panel is essential for troubleshooting, performing backups, and managing the underlying infrastructure of the website.
What are the login details for the domain registrar (e.g., GoDaddy, Namecheap) where the site's domain name is managed?
Control over the domain registrar account is paramount[^13]. This account governs the ownership of the domain name itself, as well as the DNS settings that direct traffic to the web server. Losing control of this account can result in the loss of the domain name, a catastrophic event for any business. The new owner must ensure that the account is transferred into their name and that they control the billing information for renewals.
For more advanced management, maintenance, and development, direct access to the server's file system and database is often required.
Please provide SFTP (Secure File Transfer Protocol) or SSH (Secure Shell) credentials for direct file access to the server.
SFTP/SSH access allows for the direct manipulation of WordPress core files, themes, and plugins[^4]. This level of access is necessary for manual updates, troubleshooting complex issues, and managing file permissions. Each user who requires this access should have their own unique credentials.
What are the credentials for direct database access, including the Database Name, Username, Password, and Hostname?
The WordPress database is the heart of the website, storing all content, settings, and user information. Direct access via a tool like phpMyAdmin (often available through the hosting control panel) is sometimes necessary for complex data migrations, repairs, or manual cleanup[^8]. These credentials should be treated with the utmost security.
Modern websites are rarely monolithic; they are ecosystems of interconnected services. Each of these services represents an access point that must be controlled.
Please provide a comprehensive list of all third-party services integrated with the site. This must include, but is not limited to: Payment Gateways (e.g., Stripe, PayPal), Content Delivery Networks (CDNs) like Cloudflare, Email Marketing Platforms (e.g., Mailchimp, ConvertKit), CRM systems, Analytics platforms (e.g., Google Analytics, Google Tag Manager), and any other services connected via an API key.
This question forces a thorough inventory of the entire digital ecosystem[^5]. Many critical site functions, such as payment processing or email list sign-ups, depend on these external services. Without a complete list, the new owner may be unaware of a dependency until it fails.
For each service identified, what are the login credentials or API keys, and what is the process for transferring ownership of these accounts to us?
It is not enough to simply have the login details; legal and administrative ownership of these third-party accounts must be transferred[^5]. This often involves the departing developer adding the new owner as an administrator, who then removes the developer's access. For services using API keys, these keys should be regenerated after the handover to invalidate the old ones.
The method by which credentials are transferred is as important as the credentials themselves. Insecure practices can expose sensitive information and undermine the entire handover process.
ACTION ITEM: Insist on Secure Credential Sharing.
Under no circumstances should passwords or API keys be sent in plain text via email, as this is a major security vulnerability[^13]. The new owner should insist on the use of a secure sharing method, such as a one-time, self-destructing note service (e.g., Privnote) or, preferably, a shared vault within a reputable password manager (e.g., 1Password, Bitwarden).
ACTION ITEM: Immediate Credential Rotation & 2FA Activation.
Upon receiving all credentials, the new owner's first action should be to log in to every single service, change the password to a new, strong, and unique one, and enable two-factor authentication (2FA) wherever possible. This immediately secures the accounts under the new owner's control.
ACTION ITEM: Systematic Revocation of Old Access.
The final and most crucial step of the access transfer is to systematically remove the previous developer's user accounts from every platform: WordPress, hosting, domain registrar, CDN, and all other third-party services[^3]. This step should be performed methodically, using the inventory created as a checklist. The handover is not complete until this de-provisioning process is finished.
To facilitate this critical process, the use of a centralized inventory document is strongly recommended. The following table provides a template for creating a single source of truth for all access points, which serves as both an inventory and a dynamic checklist for the transfer of ownership.
This structured approach transforms a potentially chaotic and insecure exchange into a systematic and auditable process. It forces a complete inventory, preventing omissions of forgotten but critical services like a transactional email API. By including columns for cost and renewal dates, the table evolves from a simple access log into a vital financial and operational planning tool, preventing unexpected service disruptions due to non-payment[^7]. The Ownership Transfer Status column acts as a progress tracker, providing a clear visual indicator of what has been completed and what remains, ensuring that the critical final step of revoking the old developer's access is never overlooked[^4].
# Part III: Deconstructing the Technical Architecture
Understanding how a website was built is a prerequisite for being able to effectively maintain, troubleshoot, and extend it. This section focuses on creating a comprehensive blueprint of the site's technical construction. The questions are designed to uncover the development practices, tools, and structural decisions that define the website's functionality and, by extension, its future maintainability.
The use of a version control system (VCS) like Git is a hallmark of professional web development. It provides a complete history of changes, facilitates collaboration, and enables safe deployment and rollback procedures.
Is the website's code managed in a version control system like Git? If so, please provide access to the repository (e.g., on GitHub, Bitbucket, or GitLab).
The answer to this question is a primary indicator of the developer's professionalism. If the code is managed in a repository, it suggests a structured and disciplined workflow[^8]. If the answer is no, or if the developer is unfamiliar with the concept, it is a major red flag. It implies that changes were likely made directly on the live server via FTP, a practice that is highly prone to error and offers no way to track changes or revert mistakes.
What is the branching strategy used in the repository (e.g., GitFlow, feature branches)? Which branch represents the code currently running on the live production site?
Understanding the branching strategy is key to safely contributing new code. A common practice is to have a main or master branch that reflects the live site, a develop branch for integrating new features, and separate feature branches for individual tasks. Knowing this structure prevents accidental deployments of unfinished work to the production environment.
Can you confirm that the repository contains the complete and unabridged history of the project's development?
A repository with a shallow or very recent commit history may indicate that version control was not used consistently throughout the project's life. A complete history is an invaluable diagnostic tool, allowing the new owner to see when and why specific changes were made.
The WordPress theme controls the entire visual presentation of the site. The way it has been structured and customized has profound implications for future updates and maintenance.
What theme is the site built on? Is it a pre-built commercial theme from a marketplace, or is it a fully custom theme built from scratch?
This question establishes the foundation of the site's design[^10]. If it is a commercial theme, the new owner will need to know where to find its documentation and support channels. If it is a custom theme, all documentation must come from the departing developer.
If it's a commercial theme, is a child theme being used for all customizations? Can you provide explicit confirmation that no modifications have been made directly to the parent theme's files?
This is a critically important technical question. The WordPress best practice for customizing a commercial theme is to use a child theme[^5]. A child theme inherits all the functionality and styling of the parent theme but allows customizations to be stored in separate files. This structure ensures that when the parent theme is updated (for example, to patch a security vulnerability), the custom modifications are not overwritten and lost. If the developer has edited the parent theme's files directly, the site becomes un-updateable, posing a massive long-term security and maintenance risk.
Where are the theme's original purchase files and official documentation located?
For any commercial theme, having access to the original .zip file and the official documentation is essential for troubleshooting and understanding its built-in features and options.
Plugins extend the core functionality of WordPress, but they also add complexity and potential points of failure. A thorough audit of the plugin stack is essential for assessing the site's health and security.
Please provide a complete list of all installed plugins. For each plugin, can you briefly explain its purpose and the rationale for why it was chosen over alternatives?
This question forces a justification for each component of the site's software stack[^5]. It helps identify plugins that may be redundant, unnecessary, or not the best tool for the job. A site with an excessive number of plugins can suffer from poor performance and an increased attack surface.
Which of these plugins are premium (paid) versions? Please provide the associated license keys and account information required to receive future updates and technical support.
As with premium themes, premium plugins require active licenses for updates[^12]. An expired license can leave a plugin vulnerable to known exploits. This information should be recorded in the Master Credentials & Services Inventory.
Are there any custom-built plugins developed specifically for this site? If so, where is their source code managed, and is there documentation for their functionality?
A custom plugin represents a piece of bespoke software that the new owner will be responsible for maintaining[^11]. It is crucial to have access to its source code (ideally in the same Git repository as the theme) and comprehensive documentation explaining what it does and how it works.
Are there any known conflicts between plugins in the current stack, or are there any plugins known to cause performance issues?
This question seeks to uncover latent problems that may not be immediately obvious. An experienced developer will often be aware of subtle conflicts or performance bottlenecks caused by specific combinations of plugins.
# The Definitive WordPress Handover Protocol: A Comprehensive Due Diligence Questionnaire
The handover of a WordPress project is a critical inflection point in the lifecycle of a digital asset. It is frequently misconstrued as a simple, transactional event involving the exchange of files & passwords. This perspective is dangerously incomplete. A successful handover is not an event but a comprehensive process of knowledge transfer, moving far beyond the delivery of technical components to encompass the full strategic, legal, & operational context of the website1. The ultimate objective is to de-risk the transition by eliminating dependency on the departing developer, thereby empowering the new owner w/complete & unencumbered autonomy over their digital property.
The stakes of a poorly executed handover are exceptionally high. An incomplete transfer can precipitate a cascade of negative consequences that manifest long after the original developer has departed. These risks include severe security vulnerabilities stemming from lingering, unauthorized access to critical systems2; operational downtime caused by unknown dependencies or undocumented, fragile workflows3; significant legal liabilities arising from ambiguous ownership of intellectual property or non-compliance w/data privacy regulations4; & escalating future costs as the new team grapples w/undocumented technical debt that is difficult & expensive to remediate5. Many of these issues can be traced back to a failure to ask the right questions at the right time.
This guide provides a structured, exhaustive set of questions designed to serve as a definitive due diligence protocol for any WordPress project handover. It is engineered to be a practical tool, enabling the incoming owner or team to proactively identify, assess, & mitigate the myriad risks inherent in the transition process. By systematically addressing each area—from high-level strategy to the most granular technical detail—the new owner can ensure a truly complete & seamless transfer of control, establishing a firm foundation for the future management, maintenance, & growth of the website.
Before any technical examination of the website can be meaningful, it is imperative to establish a deep understanding of its business context. The technical architecture, features, & code are merely instruments designed to serve a strategic purpose. Their quality & appropriateness can only be judged against the business goals they were intended to achieve. This section provides the questions necessary to uncover the why behind the website, clarifying its purpose, history, stakeholders, & the legal framework that governs it.
Understanding the original intent & historical evolution of a project is fundamental. It provides the context for all subsequent technical decisions & can reveal architectural layers or features that may no longer align w/the current business strategy. This historical perspective is a map to understanding the site's current state & its potential hidden complexities.
What was the original business problem this website was built to solve? What were the primary goals & objectives defined at the project's inception?
This foundational question seeks to establish the core rationale for the website's existence6. A clear answer, such as to generate qualified leads for our consulting services or to sell handmade goods directly to consumers, provides a lens through which all features & design choices can be evaluated. A vague or non-existent answer may indicate a lack of strategic direction from the outset, which can often translate into a disjointed & ineffective website.
Who was the target audience defined at the project's outset, & has that audience evolved over time?
A website's design, content, & functionality should be tailored to its intended users3. Understanding the defined audience helps assess the appropriateness of the user experience (UX) & user interface (UI). Furthermore, inquiring about the evolution of this audience can highlight areas where the site may need to be adapted to meet new user needs or demographic shifts.
Can you provide a brief history of the project, including key milestones, major feature additions, or significant strategic pivots?
This question is not merely about creating a timeline; it is a powerful diagnostic tool for uncovering technical debt1. A project's history is often a story of its compromises. For example, a website that began as a simple brochure site & later had e-commerce functionality bolted on may suffer from significant architectural weaknesses. The theme may not be optimized for online sales, or the chosen e-commerce plugin might be poorly integrated, leading to performance issues & maintenance nightmares. Understanding these historical pivots allows the new owner to probe deeper into the implementation of major features & anticipate areas of fragility that are not immediately apparent from a surface-level review.
What were the key performance indicators (KPIs) used to measure the website's success?
Knowing the metrics that matter—such as lead conversion rates, average order value, or user engagement time—clarifies what aspects of the site are considered most valuable6. This information is crucial for prioritizing future development efforts & ensuring that any changes made do not negatively impact the site's primary commercial or strategic functions.
A website does not exist in a vacuum. It serves & is managed by a network of individuals, each w/their own set of expectations & responsibilities. Identifying these stakeholders is essential for establishing clear lines of communication & understanding the project's internal political landscape.
Who are the key internal & external stakeholders involved w/the website? Who has the final authority for approving changes?
This question aims to create a definitive map of influence & responsibility1. The answer should identify the project owner, marketing team members, content editors, & any other individuals who have a vested interest in the site's operation. Crucially, it must clarify the approval workflow, which will prevent future delays & conflicts when changes need to be implemented.
Which stakeholders were involved in the original 'Discovery' or research phase of the project?
The initial research or Discovery phase is where the foundational requirements & strategies for a project are established7. Identifying the participants of this phase provides a direct line to the sources of the original project vision. If questions arise later about why a particular feature was built in a certain way, these are the individuals who will likely hold the answer.
The handover process involves the transfer of a valuable business asset, & w/it comes a host of commercial & legal responsibilities. Failing to clarify these details can lead to severe financial & legal repercussions, including loss of ownership, unexpected costs, & data privacy violations.
Can you confirm in writing that upon final payment, our organization will have 100% ownership of the website, its design, all custom-developed code, & all content created specifically for the project?
This is arguably one of the most critical questions in the entire handover process. It directly addresses the fundamental issue of asset ownership.8 Ambiguity in contracts or verbal agreements has led to numerous disputes where developers claim ownership of the work, effectively holding the client's website hostage9. A clear, written confirmation of a complete transfer of intellectual property rights is non-negotiable.
Are there any third-party or premium software licenses (for themes, plugins) that need to be transferred or repurchased? Please provide a comprehensive list of all such software, including license keys, original purchase dates, renewal dates, & annual costs.
Modern WordPress sites are often built upon a foundation of premium themes & plugins. These components require active licenses to receive crucial security updates & technical support.3 If these licenses are registered to the departing developer, they may expire without the new owner's knowledge, leaving the site vulnerable to security exploits or causing critical features to cease functioning. A complete inventory of these licenses is essential for both security & financial planning.
Are there any ongoing service level agreements (SLAs), hosting contracts, or other contractual obligations w/your company or external third parties that we will be inheriting?
This question aims to uncover any hidden or recurring financial commitments associated w/the website.1 The new owner must be aware of all contracts they are assuming, whether for specialized hosting, maintenance retainers, or other third-party services. This prevents unexpected invoices & ensures continuity of essential services.
What data privacy agreements or policies are in place to comply w/regulations such as GDPR or CCPA? Where is user data stored, & what measures are in place to protect it?
In the modern regulatory environment, data privacy is a significant area of legal liability.4 The new owner must understand how the website collects, stores, & manages personally identifiable information (PII). This includes data from contact forms, e-commerce transactions, & user registrations. The developer should be able to point to the relevant privacy policy pages & explain the technical safeguards that have been implemented to ensure compliance.
# Part II: The Keys to the Kingdom: Access, Credentials, & Third-Party Services
This section constitutes a non-negotiable inventory of all access points required to control the website & its surrounding ecosystem. The primary goal is to achieve full, exclusive administrative control over every component. A handover cannot be considered complete until every credential has been securely transferred & the previous developer's access has been systematically & verifiably revoked from every platform. Failure to do so represents a critical & ongoing security risk.2
These are the fundamental access points for managing the website's content, hosting environment, & domain name. Without these, the new owner is effectively locked out of their own property.
Please provide credentials for a new, unique Administrator-level user for the WordPress dashboard.
It is a critical best practice to never take over an existing user account5. A new, dedicated administrator account should be created for the new owner. This ensures a clean audit trail & prevents any ambiguity about who performed which actions. Once the new owner has confirmed their access, all other administrator accounts, including the one used by the departing developer, should be demoted or deleted.
What are the login details for the website's hosting control panel (e.g., cPanel, Plesk, or a custom provider dashboard)?
The hosting control panel is the gateway to the server environment. It allows for the management of files, databases, email accounts, & other server-level configurations5. Access to this panel is essential for troubleshooting, performing backups, & managing the underlying infrastructure of the website.
What are the login details for the domain registrar (e.g., GoDaddy, Namecheap) where the site's domain name is managed?
Control over the domain registrar account is paramount10. This account governs the ownership of the domain name itself, as well as the DNS settings that direct traffic to the web server. Losing control of this account can result in the loss of the domain name, a catastrophic event for any business. The new owner must ensure that the account is transferred into their name & that they control the billing information for renewals.
For more advanced management, maintenance, & development, direct access to the server's file system & database is often required.
Please provide SFTP (Secure File Transfer Protocol) or SSH (Secure Shell) credentials for direct file access to the server.
SFTP/SSH access allows for the direct manipulation of WordPress core files, themes, & plugins11. This level of access is necessary for manual updates, troubleshooting complex issues, & managing file permissions. Each user who requires this access should have their own unique credentials.
What are the credentials for direct database access, including the Database Name, Username, Password, & Hostname?
The WordPress database is the heart of the website, storing all content, settings, & user information. Direct access via a tool like phpMyAdmin (often available through the hosting control panel) is sometimes necessary for complex data migrations, repairs, or manual cleanup5. These credentials should be treated w/the utmost security.
Modern websites are rarely monolithic; they are ecosystems of interconnected services. Each of these services represents an access point that must be controlled.
Please provide a comprehensive list of all third-party services integrated w/the site. This must include, but is not limited to: Payment Gateways (e.g., Stripe, PayPal), Content Delivery Networks (CDNs) like Cloudflare, Email Marketing Platforms (e.g., Mailchimp, ConvertKit), CRM systems, Analytics platforms (e.g., Google Analytics, Google Tag Manager), & any other services connected via an API key.
This question forces a thorough inventory of the entire digital ecosystem3. Many critical site functions, such as payment processing or email list sign-ups, depend on these external services. Without a complete list, the new owner may be unaware of a dependency until it fails.
For each service identified, what are the login credentials or API keys, & what is the process for transferring ownership of these accounts to us?
It is not enough to simply have the login details; legal & administrative ownership of these third-party accounts must be transferred3. This often involves the departing developer adding the new owner as an administrator, who then removes the developer's access. For services using API keys, these keys should be regenerated after the handover to invalidate the old ones.
The method by which credentials are transferred is as important as the credentials themselves. Insecure practices can expose sensitive information & undermine the entire handover process.
ACTION ITEMInsist on Secure Credential Sharing.
Under no circumstances should passwords or API keys be sent in plain text via email, as this is a major security vulnerability10. The new owner should insist on the use of a secure sharing method, such as a one-time, self-destructing note service (e.g., Privnote) or, preferably, a shared vault within a reputable password manager (e.g., 1Password, Bitwarden).
ACTION ITEMImmediate Credential Rotation & 2FA Activation.
Upon receiving all credentials, the new owner's first action should be to log in to every single service, change the password to a new, strong, & unique one, & enable two-factor authentication (2FA) wherever possible. This immediately secures the accounts under the new owner's control.
ACTION ITEMSystematic Revocation of Old Access.
The final & most crucial step of the access transfer is to systematically remove the previous developer's user accounts from every platform: WordPress, hosting, domain registrar, CDN, & all other third-party services2. This step should be performed methodically, using the inventory created as a checklist. The handover is not complete until this de-provisioning process is finished.
To facilitate this critical process, the use of a centralized inventory document is strongly recommended. The following table provides a template for creating a single source of truth for all access points, which serves as both an inventory & a dynamic checklist for the transfer of ownership.
This structured approach transforms a potentially chaotic & insecure exchange into a systematic & auditable process. It forces a complete inventory, preventing omissions of forgotten but critical services like a transactional email API. By including columns for cost & renewal dates, the table evolves from a simple access log into a vital financial & operational planning tool, preventing unexpected service disruptions due to non-payment8. The Ownership Transfer Status column acts as a progress tracker, providing a clear visual indicator of what has been completed & what remains, ensuring that the critical final step of revoking the old developer's access is never overlooked.11
# Part III: Deconstructing the Technical Architecture
Understanding how a website was built is a prerequisite for being able to effectively maintain, troubleshoot, & extend it. This section focuses on creating a comprehensive blueprint of the site's technical construction. The questions are designed to uncover the development practices, tools, & structural decisions that define the website's functionality and, by extension, its future maintainability.
The use of a version control system (VCS) like Git is a hallmark of professional web development. It provides a complete history of changes, facilitates collaboration, & enables safe deployment & rollback procedures.
Is the website's code managed in a version control system like Git? If so, please provide access to the repository (e.g., on GitHub, Bitbucket, or GitLab).
The answer to this question is a primary indicator of the developer's professionalism. If the code is managed in a repository, it suggests a structured & disciplined workflow.5 If the answer is no, or if the developer is unfamiliar w/the concept, it is a major red flag. It implies that changes were likely made directly on the live server via FTP, a practice that is highly prone to error & offers no way to track changes or revert mistakes.
What is the branching strategy used in the repository (e.g., GitFlow, feature branches)? Which branch represents the code currently running on the live production site?
Understanding the branching strategy is key to safely contributing new code. A common practice is to have a main or master branch that reflects the live site, a develop branch for integrating new features, & separate feature branches for individual tasks. Knowing this structure prevents accidental deployments of unfinished work to the production environment.
Can you confirm that the repository contains the complete & unabridged history of the project's development?
A repository w/a shallow or very recent commit history may indicate that version control was not used consistently throughout the project's life. A complete history is an invaluable diagnostic tool, allowing the new owner to see when & why specific changes were made.
The WordPress theme controls the entire visual presentation of the site. The way it has been structured & customized has profound implications for future updates & maintenance.
What theme is the site built on? Is it a pre-built commercial theme from a marketplace, or is it a fully custom theme built from scratch?
This question establishes the foundation of the site's design.7 If it is a commercial theme, the new owner will need to know where to find its documentation & support channels. If it is a custom theme, all documentation must come from the departing developer.
If it's a commercial theme, is a child theme being used for all customizations? Can you provide explicit confirmation that no modifications have been made directly to the parent theme's files?
This is a critically important technical question. The WordPress best practice for customizing a commercial theme is to use a child theme3. A child theme inherits all the functionality & styling of the parent theme but allows customizations to be stored in separate files. This structure ensures that when the parent theme is updated (for example, to patch a security vulnerability), the custom modifications are not overwritten & lost. If the developer has edited the parent theme's files directly, the site becomes un-updateable, posing a massive long-term security & maintenance risk.
Where are the theme's original purchase files & official documentation located?
For any commercial theme, having access to the original.zip file & the official documentation is essential for troubleshooting & understanding its built-in features & options.
Plugins extend the core functionality of WordPress, but they also add complexity & potential points of failure. A thorough audit of the plugin stack is essential for assessing the site's health & security.
Please provide a complete list of all installed plugins. For each plugin, can you briefly explain its purpose & the rationale for why it was chosen over alternatives?
This question forces a justification for each component of the site's software stack3. It helps identify plugins that may be redundant, unnecessary, or not the best tool for the job. A site w/an excessive number of plugins can suffer from poor performance & an increased attack surface.
Which of these plugins are premium (paid) versions? Please provide the associated license keys & account information required to receive future updates & technical support.
As w/premium themes, premium plugins require active licenses for updates12. An expired license can leave a plugin vulnerable to known exploits. This information should be recorded in the Master Credentials & Services Inventory.
Are there any custom-built plugins developed specifically for this site? If so, where is their source code managed, & is there documentation for their functionality?
A custom plugin represents a piece of bespoke software that the new owner will be responsible for maintaining9. It is crucial to have access to its source code (ideally in the same Git repository as the theme) & comprehensive documentation explaining what it does & how it works.
Are there any known conflicts between plugins in the current stack, or are there any plugins known to cause performance issues?
This question seeks to uncover latent problems that may not be immediately obvious. An experienced developer will often be aware of subtle conflicts or performance bottlenecks caused by specific combinations of plugins.
Beyond the theme & plugins, custom code can be added in various places within WordPress. Locating & understanding all custom code is vital for preventing accidental breakage.
Is there any custom PHP code that has been added to the theme's functions.php file or implemented via a code snippets plugin?
The functions.php file is a common location for developers to add custom functionality, from simple tweaks to complex features3. A code snippets plugin is another popular method. All such code must be documented & understood, as it can have a significant impact on the site's behavior.
Where is custom CSS or JavaScript stored? Is it located in the theme customizer's 'Additional CSS' field, within the child theme's stylesheet, or loaded via other methods?
Custom styling (CSS) & interactivity (JavaScript) can be injected in multiple ways9. A systematic developer will consolidate all custom code in the child theme's
style.css & scripts.js files. A less organized approach might scatter code across theme options panels, customizer fields, & even within the content of individual pages. A full inventory is needed to ensure that styles are not lost or overridden during future development.
Was a specific coding standard (e.g., the official WordPress Coding Standards) followed during the development of custom code? Is the custom code well-commented to explain its purpose & logic?
Code that adheres to a standard is easier for other developers to read & understand. More importantly, well-commented code is exponentially easier & cheaper to maintain5. Code without comments forces the new developer to spend significant time reverse-engineering its purpose, which increases costs & the risk of introducing new bugs.
The way content is structured in the WordPress database dictates how it can be managed & displayed. Understanding this structure is key to managing the site's information architecture.
Does the site utilize custom post types, custom fields, or custom taxonomies? If so, how were these created (e.g., w/custom code in functions.php, or w/a plugin like Advanced Custom Fields (ACF) or Custom Post Type UI)?
These features allow for the creation of structured content beyond standard posts & pages (e.g., Team Members,Events,Products)3. Knowing how they were implemented is crucial for maintenance. If they were created w/a plugin like ACF, the new owner must understand how to manage the field groups.
If the site uses a page builder (e.g., Elementor, Beaver Builder, Divi) or a framework like ACF, are there any global settings, saved templates, or reusable blocks that I should be aware of?
Modern page builders & frameworks often include powerful systems for creating global elements (like headers & footers) & reusable content templates12. Understanding where these global settings are controlled is essential to avoid making a change on one page that unintentionally affects the entire site.
Are there any custom database tables that were created for the site, separate from the standard WordPress tables? If so, what is their purpose & what is their schema?
While less common, some plugins or custom solutions create their own tables in the database5. These tables will not be understood by standard WordPress functions, & their purpose must be thoroughly documented.
To consolidate this architectural audit, a detailed inventory of all active software components is invaluable. The following table provides a template for this audit, functioning as both an inventory & a risk assessment tool.
CRITICAL RISK - Site layouts depend on this. CANNOT UPDATE WITHOUT a valid license.
❌
Really Simple SSL
Plugin
7.0.5
Manages SSL certificate
Free
N/A
Redundant - Hosting provides SSL. Can likely be removed after verification.
❌
Classic Editor
Plugin
~1.6.3
Disables Gutenberg editor
Free
N/A
Indicates site may not be compatible w/modern block editor. Creates technical debt.
This systematic audit transforms a simple list of plugins into a powerful strategic document. It immediately highlights critical dependencies & risks. For instance, the Missing/Expired license for ACF PRO is a red alert; it means a core component of the site cannot receive security updates & may break in a future version of WordPress. The presence of the Classic Editor plugin signals that the site is built on older technology & will require significant effort to modernize. This table provides the new owner w/an immediate, prioritized action plan for stabilizing & improving the website.
# Part IV: The Hosting Environment & Deployment Pipeline
A website's code is only one half of the equation; the infrastructure it runs on is the other. The hosting environment dictates the site's performance, security, scalability, & reliability. This section delves into the specifics of the server & the processes used to deploy changes, which together form the operational foundation of the website.
Understanding the specifics of the hosting plan is the first step in assessing the site's infrastructural capabilities & limitations.
Knowing the provider & plan name allows the new owner to look up the official specifications, features, & support policies13. Different hosts & plans offer vastly different levels of performance & service.
Who is the hosting provider? What is the specific name of the hosting plan (e.g., 'Managed WordPress - Grow', 'VPS Level 3')?
Every hosting plan has resource constraints13. Exceeding these limits can result in overage fees or, in a worst-case scenario, the suspension of the website. The PHP memory limit is a particularly important figure, as insufficient memory can cause errors & crashes, especially on sites w/many plugins or high traffic.
What are the key resource limits of this plan, such as storage space, monthly visits or bandwidth, & the PHP memory limit?
The type of hosting defines the level of control, responsibility, & performance isolation.14
Is this a shared, VPS (Virtual Private Server), dedicated, or managed WordPress hosting environment?
Shared Hosting - The cheapest option, but resources are shared w/many other websites, leading to potential performance & security issues (the noisy neighbor effect).
VPS Hosting - Offers a dedicated slice of server resources, providing better performance & more control than shared hosting.
Dedicated Hosting - An entire physical server is dedicated to the website, offering maximum performance & control but requiring expert management.
Managed WordPress Hosting - A specialized environment optimized specifically for WordPress. The host manages security, backups, & updates, offering convenience at a higher price point. It may also come w/restrictions on which plugins can be used.15
This is a critical piece of financial information needed for budgeting & ensuring the continuity of service8. This data should be logged in the Master Credentials & Services Inventory.
What is the current cost of the hosting plan, & what is its renewal date?
The software running on the server can have a major impact on the website's compatibility & security.
What versions of PHP & MySQL/MariaDB is the server currently running?
WordPress relies on PHP (the programming language) & MySQL or MariaDB (the database software). Using outdated versions of this software can expose the site to serious security vulnerabilities & prevent the use of modern themes & plugins3. Conversely, a site built on old code may not be compatible w/the latest PHP versions.
Are there any specific server configurations (e.g., custom php.ini settings) or required PHP extensions that are critical for the site to function properly?
Sometimes, a specific plugin or theme requires a non-standard server setting or a particular PHP extension to be enabled. This information is crucial for disaster recovery or if the site ever needs to be migrated to a new hosting environment. Without this knowledge, the site may fail to work correctly on a new server.
Is there a Web Application Firewall (WAF) active at the server level (e.g., ModSecurity or a provider-specific firewall)?
A WAF provides an important layer of security by filtering malicious traffic before it even reaches WordPress16. Understanding if a server-level WAF is in place helps to form a complete picture of the site's security posture.
The process of moving changes from a development environment to the live production site is one of the most risk-prone activities in website management. A disciplined, well-documented workflow is a sign of a mature development practice, while an ad-hoc process is a recipe for disaster.
A staging site is a private clone of the live site used for testing changes safely12. Professional hosting providers often include one-click staging environments. The absence of a staging site means that updates & changes are likely being tested directly on the live site, a practice that is extremely risky & can easily lead to public-facing errors or downtime.
Is there a dedicated staging or development environment? If so, how is it kept in sync w/the production site?
This question probes the very core of the developer's operational discipline17. A developer's ability to clearly articulate a repeatable, logical deployment process is a strong indicator of the project's overall stability. If the developer cannot provide a clear, step-by-step process, or if the process is overly complex & manual (First I FTP these three files, then I go into the database & manually copy this one table...), it reveals a massive operational risk. This undocumented, memory-based process is fragile & highly susceptible to human error. It signals that the new owner's first priority must be to stabilize & document this workflow to prevent a catastrophic failure during the first critical security update.
Please provide the exact, step-by-step process for deploying changes from development to production. For example: '1. Pull latest changes to the staging branch. 2. Test functionality on the staging site. 3. Take a manual backup of the production site. 4. Push changes from the staging branch to the production branch. 5. Clear all server & plugin caches.' Is this process documented?
This is a notoriously difficult aspect of WordPress development. While files can be easily managed w/Git, synchronizing database changes is more complex. The developer should be able to explain their solution, whether it involves a specialized plugin (like WP Migrate DB Pro) or a carefully documented manual process.
How are database changes (e.g., from a plugin settings update or a change made in the theme customizer) migrated from the staging environment to the production site?
Website speed is critical for user experience & search engine optimization (SEO). Caching is the primary technique used to improve performance.
What caching layers are in place? Please specify any caching plugins (e.g., WP Rocket, W3 Total Cache), server-side caching technologies (e.g., Varnish, Redis, Memcached), or CDN-level caching.
A modern WordPress site often has multiple layers of caching3. Understanding each layer is essential for troubleshooting issues where changes do not appear on the live site.
What is the specific procedure for clearing or purging all caches when a change is made but is not visible on the live site?
This is a common & frustrating problem. The developer should provide a clear, step-by-step guide for purging every layer of cache, from the browser cache to the plugin cache, server cache, & CDN cache.
Is a Content Delivery Network (CDN) like Cloudflare or StackPath being used? If so, are there any specific page rules, firewall settings, or other configurations that I should be aware of?
A CDN improves performance & security by distributing the site's assets across a global network of servers. However, misconfigured CDN settings can cause a wide range of issues, from incorrect content being displayed to the site being completely inaccessible. Access to & knowledge of the CDN configuration is essential.
An SSL certificate encrypts the connection between the user's browser & the web server, which is essential for security & is a requirement for modern websites.
Who is the provider of the SSL certificate (e.g., Let's Encrypt, a premium commercial provider)? Is it configured to renew automatically?
Most hosts now provide free SSL certificates from Let's Encrypt that renew automatically8. However, it is crucial to confirm this. An expired SSL certificate will cause browsers to display prominent security warnings to visitors, effectively killing traffic to the site until it is fixed.
# Part V: Operations, Security, & Maintenance Protocols
A website is not a static, one-time creation; it is a living system that requires continuous care & attention to remain healthy, secure, & functional. This section covers the ongoing operational procedures that form the core of a responsible website management strategy. Neglecting these protocols is a leading cause of website hacks, data loss, & performance degradation.
A robust backup strategy is the single most important defense against a wide range of catastrophic events, including server failure, hacking, or a critical error during an update.
What is the complete backup strategy? Please specify the tools used (e.g., hosting provider's built-in backup, a WordPress plugin like Duplicator or UpdraftPlus), the frequency of the backups (e.g., daily, weekly), & what, specifically, is included (e.g., full files & database).
A comprehensive answer to this question should detail a multi-faceted strategy11. Relying on a single backup method is risky. A good strategy might involve daily automated backups from the hosting provider combined w/a separate, plugin-based backup solution.
Where are the backups stored? Is at least one copy stored in a secure, off-site location (e.g., Amazon S3, Dropbox, Google Drive)?
This is a critical detail. Backups stored on the same server as the website are of limited use if the entire server is compromised or fails11. A fundamental principle of disaster recovery is to maintain at least one copy of the backups in a geographically separate, secure, off-site location.
Most importantly: Can you walk me through the documented procedure for a full site restoration from a backup? When was the last time a restoration was successfully tested?
This question cuts to the heart of operational readiness. An untested backup is not a reliable strategy; it is merely a hope. Many organizations have discovered, to their horror, that their backups were corrupted or incomplete only when they desperately needed them. A mature operational plan focuses not just on the act of creating backups, but on the proven ability to restore service from them. The developer should be able to provide a clear, documented procedure for restoration. The question When was the last time this was tested? separates a developer who has simply installed a backup plugin from one who has implemented a genuine, business-saving disaster recovery plan. The absence of a tested restoration procedure should be considered a critical risk that must be remediated immediately.
Given WordPress's popularity, it is a constant target for malicious actors. A proactive security posture is not optional; it is a fundamental requirement of website ownership.
What security plugins (e.g., Wordfence, Sucuri, iThemes Security) are installed? What are their key configurations, such as login attempt limits, file change detection, & firewall rules?
Security plugins provide essential hardening & monitoring capabilities11. The new owner must understand which tools are in place & how they have been configured to protect the site. For example, knowing the login attempt limit is crucial for preventing brute-force attacks.
What are the established policies for user roles & permissions? Is the Principle of Least Privilege (PoLP) enforced?
The Principle of Least Privilege is a foundational security concept which dictates that users should only be granted the minimum level of access necessary to perform their job functions11. For example, a content writer does not need the ability to install plugins or change theme settings. Enforcing PoLP dramatically reduces the site's attack surface & limits the potential damage that can be caused by a compromised user account.
Have there been any security breaches, malware infections, or hacking attempts in the past? If so, how were they resolved, & what specific measures were put in place to prevent a recurrence?
Understanding the site's security history can reveal persistent vulnerabilities. If the site has been compromised before, the new owner must know how the breach occurred, how the site was cleaned, & what steps were taken to close the security hole.
Outdated software is the leading cause of WordPress security vulnerabilities. A regular, disciplined update process is therefore a critical security function.
What is the established schedule & process for updating the WordPress core, themes, & plugins?
There should be a regular, predictable cadence for performing updates (e.g., weekly or bi-weekly)17. Updates should not be applied haphazardly as they become available. A disciplined process ensures that updates are managed in a controlled manner.
How are updates tested before being applied to the live site?
This question links directly back to the staging & deployment workflow discussed in Part IV. The only safe way to apply updates is to first test them on a staging site to ensure they do not cause conflicts or break functionality12. Applying updates directly to a live production site without testing is a high-risk gamble.
It is impossible to manage what is not measured. Monitoring tools provide essential visibility into the site's health, performance, & user behavior.
Are there any tools in place for uptime monitoring? Who receives alerts if the site goes down?
Uptime monitoring services (e.g., Uptime Robot, Pingdom) constantly check if a website is online & send immediate alerts if it becomes unavailable16. This allows the owner to respond to downtime quickly, often before clients or customers notice.
How is website performance monitored? Are there any analytics or logging tools configured to track errors or performance degradation over time?
Beyond simple uptime, tools can be used to monitor server response times, page load speeds, & application errors. Proactive performance monitoring can help identify & fix issues before they significantly impact the user experience.
Please provide administrative access to the site's Google Analytics & Google Search Console profiles.
These two tools are the industry standard for understanding website traffic & search performance. Google Analytics provides detailed insights into user behavior, while Google Search Console offers crucial data on how the site is performing in Google search results, including any indexing errors or manual penalties. Access to both is non-negotiable for any serious website owner.
# Part VI: The Handover Execution & Post-Transition Support
The final phase of the handover process deals w/the logistics of the knowledge transfer itself and, crucially, establishes clear & unambiguous expectations for the relationship between the new owner & the departing developer moving forward. This is where the process is formalized & the transition of responsibility is officially completed.
Comprehensive documentation & training are the bridge that allows the new owner to confidently take control of the website. They are the tangible outputs of the knowledge transfer process.
What project documentation is available (e.g., technical specifications, user manuals, design style guides), & where can it be found?
The existence & quality of documentation are strong indicators of a project's overall health & the developer's professionalism1. A well-documented project is significantly easier & less costly to maintain. The absence of any documentation is a major red flag, suggesting that all critical knowledge resides solely in the head of the departing developer.
Are you available to conduct a live training session for our team? Could you provide recorded video walkthroughs for common tasks, such as adding a new blog post, updating an e-commerce product, or managing contact form entries?
While written documentation is essential, live or recorded training can be far more effective for demonstrating workflows & user interfaces6. Video walkthroughs are particularly valuable as they create a reusable training asset that can be used to onboard future team members, reducing long-term dependency on any single individual.
This is the culminating event of the handover process, where control is officially & verifiably transferred. It should be conducted methodically to ensure no steps are missed.
Agree on a specific date & time for the final handover: _______,
Scheduling a formal handover meeting ensures that both parties are available & focused on completing the transition.
Use the Master Credentials & Services Inventory table as a final checklist:Go to Checklist
During the handover meeting, the new owner should systematically go through the inventory table created in Part II.
The new owner logs into every single service to confirm access.
This step verifies that all credentials provided are correct & functional.
The new owner changes all passwords & enables Two-Factor Authentication (2FA).
This is the critical step of securing all accounts under the new owner's exclusive control.
The new owner confirms that the previous developer's user accounts have been removed from all systems.
This final de-provisioning step officially completes the transfer of control & mitigates the risk of unauthorized future access.2
It is unrealistic to expect a perfectly flawless transition. Minor issues or questions will inevitably arise. Defining the terms of post-handover support in advance is crucial for managing expectations & preventing future disputes.
What is the specific duration & scope of the post-handover support period? (e.g. "14 days for critical", "site-breaking bug fixes only").
The terms of this support window should be explicitly defined in writing1. It should be clear that this period is for addressing unforeseen issues related to the existing state of the site, not for new feature development or general consulting.
What are the designated communication channels (e.g. "a specific email address") & the expected response times for support requests during this period?
Establishing clear communication protocols prevents confusion & frustration10. Knowing whether to expect a response within a few hours or a few business days helps to manage expectations appropriately.
What are your standard hourly rates for any work that may be requested after the formal support period ends?
It is wise to establish the cost of potential future work now, even if none is anticipated8. Having a rate sheet in writing prevents disagreements over pricing should the new owner wish to re-engage the developer for new projects or more extensive support down the line.
# D. The Exit Interview: Uncovering the Unknown Unknowns
This final set of open-ended questions is designed to elicit the kind of nuanced, contextual information that is often missed in a standard checklist. This is an opportunity to tap into the departing developer's unique, ingrained knowledge of the project's quirks & subtleties.
From your expert perspective, what do you consider to be the most fragile or technically complex part of this website?Every project has a weak point or a piece of convoluted code that the developer knows to handle w/extreme care. This question encourages them to reveal it, allowing the new owner to be aware of the risk.
If you were given another week to work on this project, what is the first thing you would fix or improve?This question often uncovers the developer's own assessment of the project's technical debt.1 Their answer can provide a valuable starting point for the new owner's own improvement roadmap.
Are there any quirks, oddities, or manual workarounds that we should be aware of? For example, (e.g. "To update the CEO's photo, you have to do this one weird thing in the media library", etc.)This is often the most valuable question of the entire handover. It is designed to capture the undocumented, informal knowledge that is essential for the smooth day-to-day operation of the site. These are the details that are never written down but can cause hours of frustration for a new team.
What were the biggest challenges you faced during the project? What were the most important lessons learned?This question provides insight into the project's history from a different angle.1 Understanding the past struggles—whether w/a particular plugin, a server configuration, or a third-party API—can help the new owner avoid repeating them in the future.
The successful handover of a WordPress project is a direct result of a diligent, systematic, & comprehensive process of inquiry. It is an exercise in proactive risk management, not an expression of mistrust. The exhaustive set of questions detailed in this guide is designed to form the backbone of this process, ensuring that the transfer of responsibility is built upon a foundation of clarity, security, & complete knowledge.
The core principles underpinning a successful handover are threefold:
Full & Unambiguous Ownership - The new owner must secure complete legal & administrative control over every digital asset, from the domain name & source code to all associated third-party service accounts.
Complete System Knowledge - The new owner must possess a deep understanding of the website's technical architecture, its operational dependencies, & the strategic goals it is designed to serve. This knowledge is the prerequisite for effective maintenance & future development.
Clear & Documented Processes - The ongoing health of the website depends on robust, repeatable processes for security, backups, updates, & deployments. These processes must be clearly documented & tested.
"By methodically pursuing the answers to these questions, the incoming owner transforms the handover from a moment of high risk into an opportunity to establish a stable & secure foundation for the future. This upfront investment of time & diligence is the most effective strategy for protecting the value of the digital asset, ensuring business continuity, & dramatically reducing the long-term costs & complexities of website ownership. The ultimate goal is to achieve a state of confident, informed, & truly independent control." —@dylarcher
WordPress Project Takeover: A Guide to Due Diligence
A successful WordPress project takeover is not just about receiving files and passwords; it is a meticulous process of due diligence designed to ensure a seamless transfer of knowledge, ownership, and control. This guide provides a comprehensive framework for the incoming owner or team to de-risk the transition, uncover hidden liabilities, and establish a stable foundation for future management and development.
The process is framed as a series of critical questions. The goal is not to express distrust, but to achieve absolute clarity. An inability or unwillingness on the part of the seller or outgoing developer to provide clear, verifiable answers to these questions should be considered a significant red flag.
1. Foundational & Strategic Inquiry
Before diving into technical specifics, it is crucial to understand the strategic context and historical landscape of the project.
What is the primary purpose and business model of the website?
(e.g., e-commerce, lead generation, content publishing, SaaS)
This clarifies the core business objectives that the website must support. Every technical decision should ultimately align with this purpose.
What are the key performance indicators (KPIs) for success?
(e.g., conversion rate, monthly recurring revenue, number of active users, lead form submissions)
This defines what "success" looks like and ensures that future work is focused on metrics that matter.
Who were the original stakeholders and what was the initial vision?
Understanding the project's origin story can provide invaluable context for its current state, including its technical architecture and feature set.
How has the website evolved over time? Have there been major pivots?
This can uncover layers of legacy code, abandoned features, or "technical debt" that may complicate future development.
2. Ownership, Legal & Compliance
This is arguably the most critical phase of the takeover. Failure to secure unambiguous ownership of all assets can have catastrophic long-term consequences.
Is there a formal contract or statement of work that explicitly transfers 100% of the intellectual property—including all custom code, graphics, and content—to us upon final payment?
You must have this in writing. Without it, you may not truly own the work you paid for.
Are there any ongoing contracts, licenses, or service level agreements (SLAs) that we will be inheriting?
This includes hosting, premium plugin licenses, maintenance plans, and third-party service subscriptions. Request copies of all agreements.
How is user data collected, stored, and managed? Is the site compliant with relevant privacy regulations (e.g., GDPR, CCPA)?
Verify the existence of a clear privacy policy, cookie consent mechanisms, and processes for handling user data requests. Non-compliance can lead to severe legal and financial penalties.
3. Technical & Infrastructure Deep Dive
This section focuses on gaining complete administrative control and a deep understanding of the technical stack.
Domain, DNS & Hosting
Who is the domain registrar? Provide full account credentials.
Who is the hosting provider? Provide full account credentials for the hosting control panel (e.g., cPanel, SiteGround, WP Engine).
What are the server specifications? (e.g., Shared/VPS/Dedicated, OS, PHP version, memory limits).
Are there any custom DNS records or a Content Delivery Network (CDN) in place? (e.g., Cloudflare). Provide full account credentials.
WordPress & Database Access
What are the credentials for ALL administrator-level WordPress accounts?
What is the direct access information for the database? (Host, DB Name, DB User, DB Password).
Is there a database management tool like phpMyAdmin? Provide access.
Code & Version Control
Is the project under version control? (e.g., Git). Provide access to the repository (e.g., GitHub, Bitbucket).
What is the branching strategy and deployment process? Is it manual (FTP) or automated (CI/CD)?
Where is custom code located? (e.g., a child theme, custom plugin). Request a full code walkthrough.
Provide a complete list of all plugins and themes (active and inactive). Note which are premium and provide license keys and proof of transfer.
Security, Backups & Email
What security measures are in place? (e.g., security plugin, Web Application Firewall (WAF)). Provide access and configurations.
What is the backup solution? (e.g., plugin, server-level). Confirm the schedule, storage location, and—most importantly—the tested restore procedure.
How are transactional emails (e.g., password resets, form notifications) handled? (e.g., via a third-party service like SendGrid or Postmark). Provide credentials.
4. The Exit Interview: Uncovering "Tribal Knowledge"
The final step is a formal exit interview with the outgoing developer or team. This is where you uncover the "tribal knowledge"—the undocumented quirks and manual workarounds that are critical for smooth operation.
What are the most fragile or complex parts of the site?
This question encourages honesty about technical debt and potential problem areas.
If you had another month to work on this project, what would you improve?
This often reveals the developer's own assessment of the site's weaknesses and opportunities for improvement.
Are there any quirks, oddities, or manual processes we should be aware of?
This is perhaps the most valuable question of the entire handover. It is designed to capture the undocumented, informal knowledge that is essential for the smooth day-to-day operation of the site. These are the details that are never written down but can cause hours of frustration for a new team.
What were the biggest challenges you faced during the project? What were the most important lessons learned?
Understanding past struggles—whether with a particular plugin, a server configuration, or a third-party API—can help the new owner avoid repeating them.
Conclusion
A successful WordPress project handover is a direct result of a diligent, systematic, and comprehensive process of inquiry. It is an exercise in proactive risk management, not an expression of mistrust. By methodically pursuing the answers to these questions, the incoming owner transforms the handover from a moment of high risk into an opportunity to establish a stable and secure foundation for the future. This upfront investment of time and diligence is the most effective strategy for protecting the value of the digital asset, ensuring business continuity, and dramatically reducing the long-term costs and complexities of website ownership.
Appendix: Comprehensive Handover Checklist
Project Overview & Intent
What is the primary purpose of the website? (e.g., e-commerce, lead generation)
Are there unique business rules or workflows?
How has the website evolved over time?
What are the key performance indicators (KPIs) for success?
Stakeholders & Roles
Who are the main points of contact?
Who manages the website now, and who will after handover?
Who participated in the original planning/discovery phase?
Ownership & Legal
Do we fully own the website, code, and content after payment?
Are there ongoing contracts (hosting, support, SLAs)?
Are there paid themes or plugins? (List all with license info, renewal dates, and transfer steps)
How is user data handled? (GDPR, CCPA compliance)
Domain & Hosting
What is the domain name and registrar? (Include login, renewal date, DNS management details)
Who is the hosting provider and what is the plan? (Include login, plan limits, renewal date, server type)
Are there custom DNS records or CDN settings? (Document all A, CNAME, MX, TXT records)
Server & Infrastructure
Server IP address(es) and control panel access (cPanel, Plesk, etc.)
Are there specific server configurations (PHP version, memory limits)?
Is there a Web Application Firewall (WAF)?
Database
Database host, type, version, name(s), and user credentials.
phpMyAdmin or other DB management tool access.
Are there custom tables or modifications?
Backup schedule and restore procedures for the database.
WordPress Access
Admin URL, usernames, and passwords for all admin/editor accounts.
2FA or security plugins in use.
List of all user roles and permissions.
FTP/SFTP/SSH Access
FTP/SFTP/SSH host, port, credentials, and key pairs.
Root directory path for WordPress installation.
Email
Email provider and account credentials.
SMTP settings and email forwarding/alias rules.
Plugins, Themes & Custom Code
List of all active/inactive plugins (with versions and license keys).
List of all installed themes (active/inactive, parent/child).
WordPress Project Handover: Comprehensive Due Diligence Checklist
Introduction
The handover of a WordPress project is a critical process that goes beyond sharing files and passwords. It involves transferring strategic, technical, operational, and legal knowledge to empower the new owner with full control and autonomy. A poorly executed handover can lead to security vulnerabilities, operational downtime, legal liabilities, and increased costs due to undocumented technical debt. This comprehensive checklist combines detailed due diligence questions with practical steps to ensure a seamless transition, reduce risks, and establish a solid foundation for the website's future management and growth.
Table of Contents
Project Overview & Intent
Stakeholders & Roles
Ownership & Legal
Domain & Hosting
Server & Infrastructure
Database
WordPress Access
FTP/SFTP/SSH Access
Email
Plugins, Themes & Custom Code
Integrations & Third-Party Services
Backups & Recovery
Security
Performance & Caching
Analytics & SEO
Environments & Deployment
Documentation & Training
Support, Maintenance & Monitoring
Final Handover & Exit Interview
Appendix: Inventory Tabular Data
1. Project Overview & Intent
Understanding the website's business context and history is essential for evaluating its technical decisions and anticipating future needs.
Detailed Considerations:
The original intent provides a lens to assess features and design choices.
Historical evolution can reveal technical debt or misaligned functionalities.
Questions to Ask:
What was the original business problem this website was built to solve? What were the primary goals (e.g., e-commerce, lead generation, content hub)?
Who was the target audience at the outset, and has it evolved over time?
Can you provide a brief history of the project, including key milestones, major feature additions, or strategic pivots?
What are the key performance indicators (KPIs) used to measure success (e.g., sales, signups, traffic)?
Are there any unique business rules or workflows that the website must adhere to?
2. Stakeholders & Roles
Identifying the network of individuals involved ensures clear communication and responsibility mapping.
Detailed Considerations:
Stakeholders influence decision-making and provide historical context.
Questions to Ask:
Who are the key internal and external stakeholders (client, marketing team, etc.)? Who has final authority for approving changes?
Who manages the website currently, and who will after handover?
Which stakeholders participated in the original planning or discovery phase?
3. Ownership & Legal
Clarifying ownership and legal obligations prevents disputes and ensures compliance.
Detailed Considerations:
Ambiguity in ownership can lead to intellectual property conflicts.
Ongoing contracts affect financial planning.
Questions to Ask:
Can you confirm in writing that upon final payment, we own 100% of the website, design, custom code, and content?
Are there any ongoing contracts (e.g., hosting, support, SLAs)? List details.
Are there paid themes or plugins? Provide license keys, purchase dates, renewal dates, and costs.
What data privacy policies are in place (e.g., GDPR, CCPA)? Where is user data stored, and how is it protected?
4. Domain & Hosting
Control over the domain and hosting is critical for operational continuity.
Detailed Considerations:
Domain registrar and hosting access are foundational assets.
Questions to Ask:
What is the domain name and registrar (e.g., GoDaddy, Namecheap)? Provide login credentials, renewal date, and DNS details (A, CNAME, MX, TXT).
Who manages DNS (registrar, Cloudflare, etc.)?
Who is the hosting provider and what is the plan (e.g., shared, VPS, managed)? Include login, plan limits, renewal date, and server type.
5. Server & Infrastructure
Server details impact performance, security, and scalability.
Detailed Considerations:
Specific configurations may be critical for functionality.
Questions to Ask:
What are the server IP address(es) and control panel access (e.g., cPanel, Plesk)?
What are the server OS, PHP, and MySQL/MariaDB versions?
Are there custom server configurations (e.g., PHP memory limits, caching)?
Is a Web Application Firewall (WAF) active (e.g., ModSecurity)?
6. Database
The database stores all content and settings, requiring secure access and management.
Detailed Considerations:
Custom tables may indicate bespoke functionality.
Questions to Ask:
What are the database host, type, version, name(s), and user credentials?
Provide phpMyAdmin or other DB management tool access.
Are there custom tables beyond standard WordPress? What is their purpose and schema?
What is the backup schedule and restore procedure?
7. WordPress Access
Administrative access to WordPress is essential for content and configuration management.
Detailed Considerations:
A new admin user ensures a clean transition.
Questions to Ask:
What is the admin URL? Provide credentials for a new admin user (e.g., for dylarcher@gmail.com).
List all admin/editor accounts, roles, and permissions.
Is 2FA or any security plugin in use?
8. FTP/SFTP/SSH Access
Direct server access enables advanced maintenance and troubleshooting.
Detailed Considerations:
Secure credentials prevent unauthorized access.
Questions to Ask:
Provide FTP/SFTP/SSH host, port, credentials, and key pairs (private/public).
Where is the authorized_keys file located?
What is the root directory path for the WordPress installation?
Are there specific file/folder permissions or restrictions?
9. Email
Email services tied to the website must be transferred.
Detailed Considerations:
Email configurations affect communication workflows.
Questions to Ask:
What is the email provider (e.g., Gmail, server-based)? Provide credentials if managed.
What are the SMTP settings (host, port, username, password)?
Are there email forwarding or alias rules?
10. Plugins, Themes & Custom Code
The software stack defines functionality and maintenance needs.
Detailed Considerations:
Customizations impact updateability and stability.
Questions to Ask:
List all active/inactive plugins (with versions, purposes, and license keys).
List all installed themes (active/inactive, parent/child, customizations).
Are there custom plugins/themes? Provide location and documentation.
Is custom code in functions.php, a snippets plugin, or elsewhere (e.g., CSS/JS)? Document its purpose.
Are custom post types, taxonomies, or fields used (e.g., via ACF)? How are they implemented?
Plugin & Theme Audit Table:
Done?
Component Name
Type
SemVer
Purpose
Premium/Free
License Key/Status
Notes/Risks
❌
Astra
Parent Theme
4.1.5
Base theme framework
Freemium
PRO license active
Do not edit directly
❌
Astra Child
Child Theme
1.x
Custom CSS/PHP
Custom
N/A
Customization hub
❌
WooCommerce
Plugin
8.0.1
E-commerce functionality
Free
N/A
Critical for sales
11. Integrations & Third-Party Services
External services are vital dependencies that must be controlled.
Detailed Considerations:
Ownership transfer prevents service disruptions.
Questions to Ask:
List all connected services (e.g., payments, analytics, CRM, APIs) with credentials/API keys.
What is the process for transferring ownership of these accounts?
12. Backups & Recovery
A robust backup strategy protects against data loss.
Detailed Considerations:
Tested restores ensure reliability.
Questions to Ask:
What backup solution is used (e.g., plugin, server, third-party)? Specify tools, schedule, retention policy, and storage location.
Are backups stored off-site (e.g., S3, Dropbox)?
Provide the documented restore procedure. When was it last tested?
13. Security
Proactive security measures safeguard the website.
Detailed Considerations:
Past issues inform current vulnerabilities.
Questions to Ask:
What security plugins/tools are used (e.g., Wordfence)? Detail configurations (firewall, login limits).
What is the SSL certificate provider, expiry, and renewal process?
How are user roles and permissions managed (e.g., Principle of Least Privilege)?
Any past security issues? How were they resolved?
14. Performance & Caching
Performance optimization enhances user experience and SEO.
Detailed Considerations:
Caching layers require specific management.
Questions to Ask:
What caching is in place (e.g., WP Rocket, server-side, CDN)? Provide credentials if applicable.
What is the procedure for clearing caches?
Is a CDN used (e.g., Cloudflare)? Detail settings.
15. Analytics & SEO
Analytics and SEO tools provide visibility into performance.
Detailed Considerations:
Access ensures ongoing monitoring.
Questions to Ask:
Provide Google Analytics, Tag Manager, and Search Console access.
What SEO plugin is used (e.g., Yoast)? Detail settings.
Where is the sitemap located?
16. Environments & Deployment
Deployment processes affect update safety and reliability.
Detailed Considerations:
Staging reduces live site risks.
Questions to Ask:
Are there development/staging/production environments? Provide URLs and access.
What is the step-by-step deployment process (e.g., Git, manual)? Is it documented?
Is version control used (e.g., Git repo URL, branching strategy)?
17. Documentation & Training
Documentation and training facilitate independent management.
Detailed Considerations:
Training bridges knowledge gaps.
Questions to Ask:
Where is project documentation (e.g., readme, specs, guides) located?
Are training sessions or video walkthroughs available for common tasks?
What are known issues or technical debt?
18. Support, Maintenance & Monitoring
Ongoing care ensures website health.
Detailed Considerations:
Clear schedules prevent neglect.
Questions to Ask:
What is the maintenance schedule (updates, backups, testing)?
Are uptime/performance monitoring tools in place? Who receives alerts?
What is the post-handover support period, communication channels, and hourly rates?
19. Final Handover & Exit Interview
The formal handover completes the transition.
Detailed Considerations:
Exit interview uncovers critical insights.
Steps to Complete:
Schedule a handover meeting for [insert date, e.g., 08/14/2025].
Use inventory tables as checklists; new owner logs into every service.
Change all passwords and enable 2FA.
Remove old users and revoke previous developer access.
Exit Interview Questions:
What are the most fragile or complex parts of the site?
If you had more time, what would you improve?
Are there any quirks, oddities, or manual workarounds?
What were the biggest challenges and lessons learned?
Tip: Attach relevant files (configurations, SSH keys, documentation, licenses) and store credentials securely.
Conclusion
A successful handover ensures the new owner has full control, a deep understanding of the website's architecture, and the processes to maintain and grow it confidently. By addressing these questions and steps, the transition becomes a foundation for long-term success, minimizing risks and empowering independent management.
