A website project is not complete because a page is live. Before closing the work, the business should receive usable access, current documentation, and evidence for the important customer path—together with a plain statement of what the provider will and will not support afterward.

That is a handover checklist, not a legal opinion or a promise that every custom build can move intact into another platform. It is a way to make the practical receipts visible before the project fades from memory.

Ask for a closeout packet, not a pile of passwords

The point is not to copy every credential into a document. It is to make sure the business can reach the accounts that matter, knows who controls each one, and has an appropriate recovery path. Use a password manager, role-based access, or the provider’s own invitation system where available.

For the domain-registration receipt, an RDAP result can identify the registrar, but the closeout evidence should be the account and recovery route the business has actually tested; public results may be redacted.

Use this handover table to record the receipt. “Access received” should mean the owner or an authorized business representative has tested the correct sign-in or recovery route—not merely that someone said an invitation was sent.

Item Accountable owner Access received Evidence to retain Limitation to state plainly
Domain registration Business-designated registrant or account owner Registrar account and recovery path tested Registrar name, renewal date, recovery contact, lock status A public lookup may be redacted and does not resolve legal ownership
DNS and email routing Business owner with technical administrator Nameserver or DNS account identified; email path documented Provider name, account owner, current records or export Do not change DNS or mail routing merely to test handover
Website hosting or deployment Business and agreed technical owner Account invitation or documented support route Host, billing responsibility, release or deployment reference A custom implementation may not be portable to another builder
Website source and assets Business and agreed repository or storage owner Repository or asset-library access tested Current repository/location, image and document inventory Access does not promise another provider will understand or convert the implementation
Content and brand materials Business owner Original files or canonical storage location received Inventory of logos, photos, copy, licenses, and known gaps Use only materials the business is entitled to use
Analytics and tags Business-controlled account owner Appropriate account role verified Property IDs, access roles, measurement notes Data may be incomplete and should not be treated as a revenue record
Search and business profiles Business-controlled account owner Owner or manager access verified where available Profile URLs, roles, unresolved verification issues Platform verification and edits remain the platform’s decision
Forms, notifications, and data export Business owner and system operator Owner can perform or observe a scoped test Test date, result, delivery or storage receipt, export path A delivery receipt does not prove a person read or acted on a message
Documentation and known exceptions Provider prepares; business accepts as a record Current document received and read Contacts, dependencies, renewals, update process, exception list Documentation is a snapshot and needs an owner after close
Support and exit boundary Both parties Contact route and boundary acknowledged Included support window, paid-change process, emergency contacts if any It is not an open-ended maintenance, migration, or response guarantee

Check the customer path once, with evidence

For a service website, a closeout packet should include a limited test of the path a ready customer would use: find the relevant page, understand the next step, submit or complete that step where appropriate, and confirm the defined receipt or storage outcome.

Record what was tested, when, and what it proved. Avoid a vague “everything works” note. A form submission can show that a defined record was created or that an alert was accepted by a provider; it does not prove an inbox placement, a human response, a qualified lead, or future performance.

Keep asset access separate from portability

It is reasonable to ask for access to the domain, approved content, accounts, data export where the system provides one, and current documentation. Those are practical handover interests.

It is different to assume that a custom site, hosting setup, analytics configuration, or form workflow can be converted into another vendor’s native format without additional work. The business should ask for the real export or source it will receive and the limitation that applies. A provider change has its own operational process; see How to Change Web Designers Without Losing Your Website, Domain, Email, or Leads.

Finish with a support boundary

Write down what happens after close:

  • who receives an access or billing question;
  • which account renewals the business must monitor;
  • which corrections are included, if any;
  • how a new request is scoped; and
  • which unresolved items remain with a platform, provider, or the business.

This prevents “handover” from becoming an implied permanent support relationship. It also gives a future provider an honest starting point rather than a claim that no dependency exists. Choosing a host and assigning ongoing responsibility are separate decisions; the hosting responsibility guide explains that distinction.

Before calling the project closed, choose one critical account or asset from the table. Have the person who will own it verify access through the supported recovery route, then save that receipt with the closeout record.

Sources