Website Handoff Checklist: What to Collect Before a Developer Leaves

A developer or agency relationship is ending. Maybe it was planned, maybe it was not. Either way, the question for the owner is the same: what do you need in your hands before the last invoice is paid?

The problems a rough handoff causes are often mundane but costly. It is a renewal notice that goes to a former contractor’s inbox. A domain registered under someone else’s name. A site that works, but nobody can say how it is deployed or where the backups go.

This checklist is about the handover: the inventory of what you should hold, and the paper trail that explains it. It is not about removing a person’s access. That is a separate job, covered in website access cleanup when an employee or vendor leaves.

Start with ownership, not with files

For each asset below, write down two things: who the legal owner is, and who has administrative control today. If those are different people, that is the first thing to fix.

Ask for these in writing, in one place:

• Domain name. The registrar, the account the domain sits in, the registrant name on record, the renewal date, and where renewal notices go.
• DNS. Where DNS is managed, who can edit it, and a current export of the records.
• Hosting. The hosting account, the plan, who is listed as owner, and who pays the bill.
• The website itself. The CMS or codebase, its admin accounts, and where the live copy is deployed from.
• Email and sending services. The mail provider, any transactional email service, and who controls the domain-authentication records.
• Analytics and search tools. Whether your own account is listed as an owner on each property, not just a viewer.
• Paid and third-party accounts. Ad accounts, tag managers, booking or form tools, payment processors, and any plugin or software licenses.

The test is simple. Could you, as the business owner, log in or recover each of these without calling the person who is leaving? If not, it is not yet handed over.

Collect what explains the site

Access gets you in. Documentation lets the next person keep the site running. Ask for:

• A site map of the setup. What runs where: the website, any staging copy, the database, the CDN or firewall, and how they connect.
• Deployment notes. How a change gets from a developer’s machine to the live site, and what has to be run or approved.
• A list of plugins, themes, or dependencies, with the reason each one is there and any that are customized.
• Scheduled jobs and integrations. Anything that runs on a timer or connects to another system, such as form routing, a CRM sync, or an automated report.
• The change history. If a log exists, take it. If you do not have one, a website change log is worth starting before the handover so you can compare against it.
• Known issues. Open bugs, deferred updates, and anything the outgoing party would warn a successor about.

If a document does not exist, say so on the checklist. A recorded gap is more useful than an assumption.

Confirm the backups, and that you can reach them

Ask where backups are stored, how often they run, how long they are kept, and who can restore from them. Then ask for one thing that matters more than the answers: a restore you have seen work. Backups are recovery, not a security plan, and a backup that only the departing party can open is not yours yet.

Handle credentials as a transfer, not an email

Do not collect passwords in a message thread. A better pattern:

1. Move each account to a business-owned login, or add a business-owned administrator.
2. Use a password manager or a shared vault the business controls.
3. Confirm each login works from the business side before anything is removed.
4. Only then have the outgoing party’s access removed.

If an account cannot be transferred, record why and what the workaround is, for example a vendor-owned tool the business pays for through a subscription.

Get the commercial paper

The handover is also a contractual one. Make sure you hold:

• The agreement or statement of work, and its termination or transition terms.
• Any license or ownership language covering the design, code, copy, and images.
• A list of recurring charges that are tied to the old arrangement.
• Contact details for any third party the outgoing party managed on your behalf.

We are not lawyers and this is not legal advice. If ownership of work product is unclear, raise it with counsel before the relationship ends, not after.

Do a walk-through before you sign off

Schedule one session, ideally with the outgoing party and the person taking over. Go down the list and have each item shown, not described. Record the date, who attended, what was handed over, and what is still open. Both sides keep a copy.

What this checklist does not promise

A handover list does not guarantee nothing will go wrong afterward. It does not replace a security review, and it does not tell you whether the site itself is in good shape. It tells you what you hold, what you do not, and who is responsible for the difference.

Where to go from here

If you would rather have the checklist run against your own site, you can ask for a handover-readiness review through our website support and maintenance page, or contact us directly. Either way, write the list down before the handover day, not on it.