Start with the domain. If you control nothing else, control that.

A website can be rebuilt. Hosting can be replaced. Even a lost mailbox can usually be worked around. Lose control of the domain and the website, email, forms, and customer trust can all leave together.

The rule: the business should be the registrant, the business should control the registrar account, and at least two responsible people should know where the recovery information lives. Your developer may administer the domain. Your developer should not quietly own it.

Domain ownership is a specific thing

The registrar is the company where the domain is registered. The registrant is the person or entity holding the registration. DNS is the set of records that tells browsers and mail systems where to go. These are related, but they are not interchangeable.

ICANN describes the registrant as the individual or entity that enters into the registration agreement with the registrar. The registrant has rights around managing, transferring, renewing, and restoring the domain. Put the company there, not a designer's personal account and not the email address of an employee who left in 2023.

1. Verify the registrar account

Log in yourself. Do not accept a screenshot as proof that an account exists.

  • Record the registrar name and account URL.
  • Confirm the registrant is the company or owner.
  • Replace old administrative and recovery addresses.
  • Turn on multi-factor authentication.
  • Store recovery codes in the business password manager.
  • Check the expiry date, auto-renew setting, and payment method.
  • Confirm the domain is locked against unauthorised transfer.

ICANN maintains a registrant information page with renewal, transfer, and recovery guidance. For a .ca domain, CIRA is the registry, although you normally manage the domain through a registrar.

2. Export the DNS records

DNS is a small collection of text records with an impressive ability to ruin a Friday afternoon. Export it or take a complete snapshot before changing providers.

The handoff should identify at least:

  • A and AAAA records: where the website or other services point.
  • CNAME records: aliases used by hosting, forms, verification, and subdomains.
  • MX records: where incoming email is delivered.
  • TXT records: email authentication and service-verification values.
  • Nameservers: which provider actually hosts the DNS zone.

Do not clean up records during the handoff because one looks unfamiliar. Identify it first. A harmless-looking TXT value may be the only thing proving ownership to a mail provider or search account.

3. Separate website access from email access

The website host and the email provider are often different companies. Moving one does not automatically move the other. Changing nameservers without copying the mail records can produce a beautiful new website and a silent inbox.

Record the email provider, administrator account, paid seats, aliases, forwarding rules, and billing owner. Then verify SPF, DKIM, and DMARC. The Canadian Centre for Cyber Security explains how those three controls work together to reduce domain spoofing.

Do not put mailbox passwords in the handoff document. Put them in a password manager and list only where the credentials are stored.

4. Take control of hosting and deployment

The business needs answers to four questions:

  1. Which company serves the live website?
  2. Which account owns the project?
  3. How does a new version reach production?
  4. Who receives outage and billing notices?

If the site deploys from GitHub, GitLab, or another repository, the business should own the organisation or have administrative access. If a freelancer disappears, somebody else needs enough access to inspect, build, and deploy the code without reconstructing the project from a browser download.

5. Collect the source and build instructions

A useful code handoff contains:

  • the repository URL and default branch;
  • the framework and runtime versions;
  • installation, development, build, and deployment commands;
  • environment-variable names without the secret values;
  • third-party services and where their secrets are stored;
  • licences for fonts, themes, plugins, photographs, or purchased assets;
  • a backup or export that can be restored independently.

"It is on my laptop" is not a deployment system. It is a future anecdote.

6. Trace every form

Submit each public form using a real external address. Confirm where the message arrives, what the visitor sees, whether an automated reply is sent, and who owns the form service account.

Forms often fail quietly after a handoff because the destination belonged to the old developer, an API key expired, or the free plan reached a limit. A green success message proves that the browser displayed a green success message. Check the inbox.

7. Transfer analytics and search accounts

Analytics history belongs with the business. So do Search Console, tag-management, advertising, map listings, consent tools, and any dashboard used to measure enquiries.

Add the owner through the platform's access controls. Do not share one login. Once the owner confirms access, remove accounts that no longer need it. Keep at least two business-controlled administrators for anything that could block recovery.

8. List recurring charges

Create one table with the provider, service, account owner, amount, billing interval, renewal date, and cancellation effect. Include the domain, mailboxes, hosting, plugins, forms, analytics, stock assets, phone numbers, and maintenance.

The cancellation effect matters. Cancelling a stock-photo plan is different from cancelling the domain. One saves $20. The other can remove the business from the internet.

9. Remove access after acceptance

First test the handoff. Then revoke old access. Removing the developer before confirming the recovery path is dramatic but inefficient.

  1. Confirm two business administrators can sign in.
  2. Run a production deployment.
  3. Test the website, forms, email, and analytics.
  4. Rotate shared secrets and old API keys.
  5. Remove people and applications that no longer need access.

The one-page handoff record

Keep a short index containing the domain registrar, DNS provider, host, repository, email provider, form service, analytics property, phone provider, password-manager location, billing owner, and emergency contact. Link to longer technical notes where needed.

Review it twice a year. Ten minutes is enough to catch an expired card, departed administrator, or recovery address that no longer exists.

Need a second pair of eyes?

Send the actual problem.

I will reply with a useful next step, a ballpark, or a referral if this needs a different expert.

Ask Kirill