How to take over a website from another agency: a handover checklist

Summary: Secure ownership first (domain, DNS, hosting, code repository and third-party accounts), take a full backup, then audit the site and document how it works before you change anything.

Why handovers go wrong

The code is rarely the problem when an agency relationship ends. The problems are ownership and knowledge: a domain registered in the agency’s name, hosting on their account, no copy of the source code, and nobody who knows which plugins are safe to update.

A structured handover deals with those risks in the right order. Ownership first, then backups, then understanding, and only then changes.

Step 1: secure ownership

Before the relationship ends, or as soon as you realise it has, make sure your business controls the things that keep the site online.

1. Domain name: registered to your company at a registrar where you hold the login.
2. DNS: you can log in to wherever the DNS records are managed (often the registrar or Cloudflare).
3. Hosting: the hosting account is in your name, or you have admin access and a plan to move it.
4. Code: a copy of the source code in a repository your business owns (for example on GitHub or Azure DevOps).
5. Content management system: an administrator account in your name.
6. Third-party services: analytics, Search Console, tag manager, email sending, payment, maps and any API keys.

Step 2: take a full backup

Before anyone changes anything, take a complete copy of the files and the database, store it somewhere separate from the hosting, and test that it can be restored. If the site breaks during the handover, this backup is your way back.

Step 3: audit what you have

A read-only audit tells you what you are dealing with and what is urgent. It should cover:

• Platform and versions: CMS, framework, language runtime and server, with end-of-support dates.
• Plugins, themes and libraries: what is installed, what is outdated, what is abandoned.
• Security: HTTPS, admin accounts, passwords stored in code, exposed admin pages.
• Hosting: where it runs, what it costs, backups and monitoring.
• Integrations: forms, CRM, payments, email and anything that would break silently.
• Performance and search: page speed, crawl errors, redirects and analytics.

Step 4: document how it works

Write down what the outgoing team would otherwise take with them: how to deploy a change, how to restore from backup, where credentials are stored, which scheduled jobs run, and any quirks (“don’t update plugin X, it breaks the booking form”). Store credentials in a password manager or vault, never in email.

Step 5: fix urgent risks, then improve

Fix critical security issues first, such as outdated software with known vulnerabilities or admin accounts with weak passwords. Then put monitoring and scheduled updates in place. Bigger improvements, redesigns or platform moves come after the site is stable and understood.

If the old agency will not cooperate

Most handovers are cooperative, and a polite, specific list of what you need helps. If an agency is unresponsive, work from what you control: the domain registrar account, the hosting account and any admin logins. If the domain or code is held by the agency, check your contract for ownership terms; many agreements transfer ownership on payment, and a solicitor’s letter usually resolves disputes.

Key takeaways

• Ownership first: domain, DNS, hosting, code and accounts.
• Back up and test a restore before changing anything.
• Audit read-only, then document how the site works.
• Fix urgent security issues before improvements.

Questions, answered