What to collect at website handoff

Start with a handoff record

Use a handoff checklist to compare what was agreed with what has been received and checked. It is useful at a new-site launch, a rebuild or a change of maintainer. Start it before the final meeting so missing invitations, files or decisions have time to be resolved.

• Download the blank handoff checklist (Markdown)
• Download the account and responsibility inventory (CSV)
• Download a completed fictional handoff record (Markdown)

The blank files contain prompts rather than claims that anything has passed. Use Not checked, Confirmed, Needs action or Not applicable, and attach an evidence reference to each confirmed item. Record the reviewer, date and scope of the check. The completed example shows how to document a review that still has open actions.

Keep the original project agreement beside the record. A checklist helps verify that agreement; it does not automatically add deliverables, unrestricted licenses or ongoing support. If the project is still being planned, use the website preparation guide to settle responsibilities earlier.

Map the accounts behind the website

Record each service separately, even when one provider supplies several. Website editing access does not necessarily include the domain, billing, form inbox or deployment settings.

The domain name, DNS and hosting may have different providers. Record business email separately before changing DNS or closing an old account. A website move should not accidentally cancel the service carrying its email.

For renewals, note the next due date, billing contact and who checks completion. Verify the arrangement in the provider account. ICANN's registrant guidance requires current account information and, when auto-renew is used, current payment details. An enabled auto-renew setting is not proof that a future payment will succeed.

Confirm access with the recipient's account

Have the person taking responsibility sign in through their own authorized account. Confirm the role and the actual site, repository or property they can see. Record an invitation as pending until it has been accepted and checked. Use individual invitations and appropriate roles where the provider supports them.

The shared checklist should contain account names and access tasks, not passwords, recovery codes, API keys or private customer records. Arrange secrets through an appropriate separate access process. Record where recovery instructions are held and which authorized role can use them, without copying the secrets themselves.

Distinguish an access invitation from a transfer. For example, GitHub's repository-transfer documentation explains that the original owner remains a collaborator after a transfer. Review ongoing access deliberately; changing the owner does not by itself remove everyone who previously worked on the project. Confirm the new owner can manage the repository before changing access that a current deployment still needs.

Collect usable files and understand their limits

Ask for the deliverables named in the agreement: source repository or export, original content, editable design files, approved media, brand assets and license records as applicable. Write down where the working source lives and which version corresponds to the live website.

For a code-managed site, the next maintainer needs enough documentation to install dependencies, build, review and publish it. Include the supported runtime, build commands, deployment process and names of required configuration values. Secret values belong in the designated secret-management process, not in the readme or public source. Have a qualified maintainer check a fresh copy in a suitable test environment.

A ZIP is not necessarily a portable website. Webflow's code-export documentation lists features that do not carry over as working hosted functionality, including CMS data, form processing and search. Ask what a particular export contains and what would have to be rebuilt or reconnected. Do not close the original service simply because a download finished.

For licensed fonts, images, themes, plugins and other purchased material, record the provider, license holder, permitted use, renewal responsibility and any transfer or reuse restrictions to clarify. Keep proof of the agreed rights with the project files. A file being present does not settle those rights.

Check forms and measurement separately

Trace one agreed visitor action from the public page through its destination and follow-up. Coordinate test submissions with the recipient, use clearly labeled test data, and confirm both the visible response and actual delivery. A success message alone does not show that the right person received the request.

Record where submissions are stored, who can access them, who follows up and which retention decisions apply. For bookings or payments, use the provider's supported test process and agree what can safely be exercised. A staging hostname does not prove its connected services are isolated.

If analytics is already part of the site, identify the correct account and property. Google Analytics distinguishes account-level from property-level access; make sure the recipient has the permission needed for their responsibility. A view-only report link is not a substitute for agreed administration access. The handoff does not require adding a new tracking system.

For Search Console, confirm an appropriate verified owner and review the previous owner's access when responsibilities change. Google's ownership guidance explains that retained verification tokens can allow a removed owner to verify again, and that removing shared tokens can affect other services. Have the authorized maintainer review the actual methods before removing anything.

Check the recovery method

Record what is copied, where it is held, retention, who restores it and what a restore would replace. Include any database, uploaded content or external records separately from the application files. WordPress's backup guidance, for example, identifies both files and the database as necessary for a typical full restoration.

Ask for a recent recovery-test record or agree an appropriate test. A maintainer should use a safe location and prevent test copies from triggering real messages, orders or other customer actions. Record what was restored, what was checked, and which connected services were outside the test.

If only the copy's existence was confirmed, say so. Mark the restore exercise as Not checked with a named next action. Knowing this limitation is more useful than labeling an untested archive as a fully verified backup.

Practise routine edits and agree ongoing care

Use the actual editor or documented workflow to practise a normal task: update approved wording, replace an image, add an article or revise opening hours. Confirm who can draft, review and publish, and how to undo an incorrect change. Use a preview where appropriate and avoid turning a training exercise into an unapproved live edit.

Collect concise instructions for the tasks the owner will actually do. Include page/image conventions, content approval, where form notifications arrive, how to request help and which changes require a builder. Assign content accuracy, technical updates, renewals, recovery and service alerts to named roles.

Agree the initial correction period, support contact, response expectations and exclusions in the project terms. A finished build does not automatically include unlimited updates or emergency coverage. The maintenance checklist can become the recurring log after handoff. Plainview's Website Care covers a separately agreed routine scope for a compatible site; new features, substantial redesigns and urgent or after-hours support need separate arrangements.

Close the handoff with specific open actions

For each open item, name the action owner, due date, evidence needed and whether it prevents acceptance or belongs in an agreed follow-up. Keep the decision explicit rather than quietly changing Needs action to Confirmed. The final record should distinguish the website's launch approval from acceptance of outstanding handoff work.

Use the website project planner to record responsibilities for an upcoming build, or discuss website planning and development if the site itself still needs work. The handoff is ready to close when the agreed materials are usable, responsibilities are understood and any remaining exceptions have been expressly agreed.