Planning a new site? Ask ARCHV to define the handover in your proposal.

An administrator login is useful, but it may be only one part of a website. The live site can depend on a domain account, hosting, a content system, source files, forms, email delivery, analytics, and paid assets. If the agreement says only “website handover,” ask for the specific items before launch.

Make an account inventory

List every account needed to keep the site running and to make normal changes:

  • Domain registrar and DNS. Who is the registrant? Who can update records or renew the domain?
  • Hosting or site platform. Who pays, who can grant access, and what happens if the plan is canceled?
  • Content system. Who can edit pages and publish new content? Is training included?
  • Form and booking tools. Where do submissions go? Who can change recipients or export the data?
  • Analytics and search tools. Which account owns the property and who has administrator access?
  • Code repository and deployment. If the site is custom-built, what source and deployment permissions are included?

You may not need direct control of every technical account. You do need to know the owner, access route, renewal obligation, and how to leave or change providers.

Identify what transfers

Ask for the final approved design files, copy, images, and source files that your agreement says you receive. Put third-party licenses in a separate list. A stock photo, font, plugin, template, or platform account may have terms that limit transfer. A promise that “you own everything” is too broad unless it specifies each asset and right.

For a redesign, include old URLs, redirect rules, content exports, and a record of what was retired. If migration was not in the agreed scope, say so and plan it separately. ARCHV's redirect and content migration guide covers that decision.

Confirm what works at the moment of transfer

Before accepting the package, test a live contact submission, a representative mobile page, key navigation links, and any booking or checkout path in scope. Note where the confirmation message and inquiry data go. Ask who fixes an in-scope defect found after launch and how quickly you must report it. Record the date at which ongoing maintenance becomes the client's or a new provider's responsibility.

If payment is tied to handover, align this checklist with the contract's acceptance process. Do not assume a blog checklist overrides signed terms. A short, documented acceptance meeting can prevent a long argument later.

One sentence to put in the proposal

“At handover, please provide an inventory of the agreed files, accounts, licenses, renewal costs, working lead paths, and the named owner for postlaunch fixes, with any exclusions stated before final approval.”

ARCHV's website page says ownership, access, recurring costs, and after-launch support should be confirmed in the proposal and handover. ICANN's domain registration guidance distinguishes the registrant from the registrar; confirm which business entity holds the domain. The exact assets and correction window depend on the signed project scope. If you are comparing offers, use the website quote review or contact ARCHV to make those terms visible.