Handover checklist for a domain

A handover works when the successor can renew the name, change where the site points and recover the account without contacting anyone who has left. Each item below should be checked while the departing volunteer is still willing to help, and recorded in writing rather than explained in a conversation.

Before the volunteer leaves

1. The registrar. Establish which company the name is actually registered with, which is not always the company that sends the invoices or hosts the site. Public registration data confirms it independently, as described in WHOIS and RDAP.
2. The account. Record the login identity used at the registrar, whether it is a personal address, a role address or a shared one, and how the password is stored.
3. The registrant of record. Check whether the registry lists the organisation or an individual. If it lists an individual who is leaving, the registrant has to be changed, which is a separate process from changing the account.
4. The recovery mailbox. Identify which address receives password resets, because whoever reads that mailbox controls the domain regardless of what any other record says.
5. The second factor. Find out whether sign in requires a code, where that code is generated, and whether backup codes exist. A code generator on a departing volunteer's phone is the most common cause of a locked account.
6. The payment method. Note how renewals are paid and whose card or account is behind it, and replace anything personal with something the organisation controls.
7. The renewal date. Write down the expiry date of every name the group holds, including redirects and old campaign names that nobody has thought about in years.
8. Every name, not just the main one. List them all. Groups routinely discover a second or third registration only when it lapses and something stops working.
9. The DNS settings. Take a copy of the current records before anything changes, including the mail entries and any verification records placed there by other services.
10. The hosting and the site. Record where the website files live, who supplies the hosting, how it is paid for, and how the site is edited.
11. The mailboxes. List the addresses that exist on the domain, who reads each one, and which forwarding rules are in place, since these break first when anything moves.
12. Other services tied to the domain. Certificates, mailing tools, payment providers and social accounts often authenticate against an address on the domain and will fail quietly when it changes hands.

At the point of transfer

1. Change the contact address first. Update the account contact and the registrant details to the organisation's own addresses before the departing volunteer's mailbox is closed.
2. Add the successor before removing the predecessor. Confirm the new person can sign in and make a change while the old access still exists as a fallback.
3. Make a test change. Editing a minor DNS record and seeing it take effect proves the access is real, which reading a password does not.
4. Remove the old access deliberately. Take the departing volunteer off the account, reset any shared credential, and note the date it was done.

Recording it

1. Write one page and keep it with the club's records. Registrar, account, recovery mailbox, second factor, payment method, renewal dates and current access, stored where the bank mandate and insurance documents are kept rather than on a personal drive.
2. Put the review in the annual cycle. Confirming these details once a year, at the same meeting each time, catches the drift that accumulates between handovers.
3. Name the office, not the person. Record which role holds the domain so the next handover has a starting point, a decision discussed in who should hold the account.
4. Minute it. A line in the minutes recording that the domain is held for the organisation is the evidence that matters if control ever has to be reclaimed.