Taking Over Website Maintenance: A Responsible Handover Checklist
Taking responsibility for a website built by another provider starts with more than an administrator login. The new team needs to understand who owns each account, how the site is connected, what can be recovered, and where responsibility begins and ends. Making those conditions visible is the foundation of a calm handover.
You are handing over a working set of relationships
The domain, DNS, email, hosting, CMS, source code, third-party services, analytics and enquiry notifications may all depend on one another. Review access, ownership, dependencies, recovery and maintenance scope together rather than treating them as separate passwords.
1. Separate maintenance, migration and rebuilding
Continuing to operate the current environment is different from moving it to another host or rebuilding parts of the site. An initial review may reveal an old runtime, assets with unclear rights or components that can no longer be updated safely. Those findings do not automatically require a rebuild, but they should be identified before either party assumes that routine maintenance is enough.
2. Record ownership and contract control
Being able to sign in does not necessarily mean the business controls the contract. Record who can renew, change or cancel each service and who receives billing or incident notices. Keep passwords out of a shared inventory; agree a secure transfer and storage method separately.
| Area | What to record |
|---|---|
| Domain and DNS | Registrar, registrant or contract owner, renewal, authorised contact and effects on email |
| Hosting and CDN | Contract holder, plan, billing, runtime, support route and incident contact |
| CMS and source | Administrator access, repository or source location, release method and custom-code owner |
| Assets and licences | Image, font, plugin and third-party-code rights, renewal and permitted use |
| Connected services | Forms, email, booking, payment, maps, analytics and their account owners |
3. Draw the dependencies, including bilingual ones
A DNS change can affect email; a plugin update can affect a form; a consent-setting change can affect measurement. In a Japanese–English site, language routing, translated records and language-specific notifications may add further dependencies. For each service, note why it exists, what stops if it fails and who can make a decision. Leave an item marked as unknown instead of filling the gap with an assumption.
4. Ask whether the backup can actually be restored
Record what is backed up, where it is stored, how often it runs and how long copies are retained. Then identify who can perform a restore and what recent data—such as enquiries or orders—could be lost. Where practical, verify the recovery process without affecting production. A rollback method must fit the particular architecture; restoring an old copy is not automatically safe once new data has entered the system.
5. Transfer access without creating another shared-account problem
Create individual accounts where the platform allows it and grant only the access each role needs. Agree when former-provider access will change, who controls multi-factor authentication and where account recovery leads. When the handover is complete, remove access and recovery details that are no longer required.
6. Test enquiries and measurement end to end
A form that displays correctly may still send to an old mailbox. Submit a real test, confirm delivery and reply routing, and review consent text, spam controls and the completion state. Test telephone links, booking, payment and document downloads where relevant. Record analytics and Search Console separately: they describe different parts of the visitor and search journey.
7. Define what “website maintenance” includes
The word maintenance can cover updates, monitoring, backups, small edits, content production, SEO and support. Define the included systems, review frequency, request route, decision process and work that requires separate investigation. If the existing setup is not yet understood, document how feasibility will be assessed instead of promising a universal response.
| Maintenance area | Questions to settle |
|---|---|
| Updates and monitoring | Which components, how often, how checks are recorded and who decides when there is a problem |
| Backup and recovery | Which data, where it is stored, recovery conditions and treatment of new data |
| Content changes | Request route, copy and asset owner, approval and publishing steps |
| Incidents | Contact route, priorities, initial scope and who contacts third-party providers |
| Improvement work | What is routine and what needs separate discovery, planning or development |
Website handover checklist
- Separate routine maintenance from migration or rebuilding.
- Confirm ownership of the domain, DNS, hosting, CMS and connected services.
- Locate source files, assets, licences and relevant usage conditions.
- Map dependencies and the functions affected by each service.
- Understand what backups contain and how recovery would work.
- Organise individual accounts, permissions, MFA and recovery routes.
- Test enquiries, notifications and important visitor journeys.
- Agree what maintenance includes and what requires a separate decision.
If the server or URLs will change too
Changing the maintenance provider and migrating the site at the same time can make issues harder to isolate. Treat URL mapping, redirects, search entry points, forms and the release decision as a distinct migration plan.
START WITH WHAT IS KNOWN
An incomplete handover pack can still have a clear starting point.
Every site has different contracts, rights and technical conditions. We can begin with the information and concerns you have, then identify what needs to be checked before ongoing support is agreed.
Review and reference
Reviewed 20 August 2026. WordPress’s official Roles and Capabilities documentation is a useful starting point for access design. The checks required depend on the site, its contracts and its connected services; this article does not guarantee the safety or recoverability of a specific environment.
