DEV Community

Cover image for Handing a client website over properly: the checklist we run before we call a project done
Brightcode
Brightcode

Posted on

Handing a client website over properly: the checklist we run before we call a project done

#webdev #beginners #devops #github

By the Brightcode team, a small web development agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

Launch day feels like the end of a project. For the client, it's the start of owning something. If the handover is sloppy, they find out months later, usually when the domain is about to expire and the renewal email goes to a developer who left two jobs ago.

We take over a fair number of sites from other teams, and the problems we find are usually about who owns what, and rarely in the code. The domain sits in a freelancer's personal account. The only Google Search Console owner is an ex-employee. The .env file lives on one laptop.

So we treat handover as a deliverable with its own checklist, below.

1. Make a list of every account the site depends on

Before you transfer anything, write down every service the site touches. A plain Markdown table in the repo is enough:

| Service            | Used for                 | Owner account        | Renews     |
|--------------------|--------------------------|----------------------|------------|
| Domain registrar   | example.in               | client@example.in    | 2027-03-14 |
| DNS / CDN          | DNS, SSL, cache          | client@example.in    | free plan  |
| Hosting            | production + staging     | client@example.in    | monthly    |
| GitHub             | code, CI                 | client org           | free plan  |
| Email sending      | contact form, order mail | client@example.in    | free tier  |
| Search Console     | indexing, sitemap        | client = owner       | -          |
| GA4                | analytics                | client = admin       | -          |
| Theme / plugins    | premium licences         | client@example.in    | yearly     |
Enter fullscreen mode Exit fullscreen mode

Look at the "Owner account" column first. If any row says your agency email, the rest of this checklist fixes it.

2. Domain: in the client's name, with the details right

The domain is the one thing that can take the whole business offline. ICANN's registrant guidance puts the responsibility on the domain holder, who must keep the contact details accurate and up to date. If those details are yours, you're the holder, not the client.

What we check:

  • The registrant name and email are the client's, and the client can log in to the registrar.
  • Auto-renew is on, with a card the client controls.
  • The client knows where to find the transfer (Auth/EPP) code. ICANN's FAQ explains that this code is needed to move a domain between registrars.
  • Registrar transfer lock is on.

One tip: if the client plans to change registrars soon, do that before you change the registrant details. Some registrars apply a transfer lock after contact changes.

3. DNS: export it before anyone touches it

Export the full DNS zone as a file and commit it (no secrets live in DNS, but double-check TXT records). When someone breaks email six months later by "cleaning up" records, you'll have the old zone to compare against.

# quick snapshot of the records that matter, for the handover doc
for t in A AAAA CNAME MX TXT NS CAA; do
  echo "== $t"; dig +short example.in $t
done > dns-snapshot-$(date +%F).txt
Enter fullscreen mode Exit fullscreen mode

Note which TXT records are for what: SPF, DKIM, DMARC, Search Console verification, and any other site verification. Unlabelled TXT records are the ones that get deleted.

4. Code: transfer the repository, don't email a zip

If the code lives in your GitHub organisation, transfer the repository to the client's organisation. GitHub's docs say issues, pull requests, the wiki and stars move with it, and links to the old location redirect to the new one. They also note that webhooks, secrets and deploy keys stay associated after the transfer. So review those on purpose:

  • Rotate deploy keys and any tokens your team created.
  • Re-check repository and environment secrets, and remove ones you no longer need.
  • After the transfer, ask the client to remove your team or reduce it to the access you need for support.

GitHub also warns that if you create a new repo with the old name in your account, the redirect to the transferred repo breaks. Don't reuse the name.

5. Secrets: out of the repo, into the client's hands

Every value in .env (API keys, SMTP passwords, payment gateway keys) should:

  • not be in Git history (scan before transfer, and rotate anything that ever was),
  • be stored in a password manager or secret store the client controls,
  • be regenerated for anything your team saw in plain text, where the provider allows it.

Payment gateways and email providers matter most. If a key leaks after you've left, nobody will know whose job it was to rotate it.

6. Search Console and analytics: client as owner, you as user

Google Search Console has two kinds of owners. A verified owner proved ownership with a token, like a DNS record or an HTML file. A delegated owner was added by a verified owner. Google notes a property must have at least one verified owner. If the only one leaves, nobody can manage it.

So at handover:

  • The client verifies themselves as an owner, ideally on a Domain property through a DNS TXT record they control.
  • Your agency drops to a full or restricted user.
  • If you were verified with a token, remove the token. Google's help says a former verified owner can regain access while their token stays on the site.

In GA4, make the client an Administrator before you remove yourself. GA4 won't let the last Administrator delete themselves, so do it in that order.

7. Licences and paid add-ons

Premium themes, page builder licences, Shopify apps and plugin subscriptions should be bought in the client's account, or moved there. Otherwise updates stop the day your agency licence lapses, and nobody notices until a security patch can't be installed.

8. Write the one-page runbook

The last file in the repo is a HANDOVER.md:

## How to deploy
## How to roll back
## Where backups are and how to restore one
## Who to call for: domain, hosting, email, payments
## Cron jobs / scheduled tasks and what they do
## Known quirks
Enter fullscreen mode Exit fullscreen mode

Keep it short. People read a one-page runbook. A 30-page document mostly goes unopened.

The test we use

Ask yourself: if our agency disappeared tomorrow, could the client hire someone else and be fully working within a day? If the answer is no, the handover isn't finished.

In our own website development projects this checklist is part of launch, not an afterthought. For custom web apps we add database backups and access to the production logs, because in that work the code and data belong to the client.

Sources

Brightcode is a web development team in Delhi NCR. After launch, we look after sites through managed hosting and care and website maintenance.

Top comments (0)