Website handover checklist: what a business should receive at launch

The starting point

The new site is live. The forms work. Everyone signs off on the design. Then somebody asks a simple question: who controls the domain account?

The question belongs in the project plan, not in an emergency email six months later.

A proper website handover leaves the business able to edit, operate, measure, recover, and move the website within the agreed platform and licence limits. A login link alone is not enough.

Start with the accounts the business depends on

List every service involved in running the site. For most marketing websites, the list starts with the domain registrar, DNS, hosting or website platform, CMS, business email, forms, analytics, and Search Console.

For each one, record four things:

• Who owns the account?
• Who pays the recurring charge?
• Who has administrator access?
• Who responds when something breaks?

A contractor might need admin access to finish the work. The business should still know which account is the source of control and how access will continue after the project.

Keep ownership, access, and licences separate

These words often get mixed together.

Ownership means who controls an account or holds the relevant rights.

Access means which people are allowed to use an account.

A licence describes permission to use software, images, fonts, templates, or other assets under certain terms.

A business might own a domain, pay for a CMS subscription, receive editable Figma files, and use licensed assets without owning the underlying third-party intellectual property. The handover should explain each part in plain language.

A password document does not resolve ownership. Use a proper password manager or approved access-sharing method. Avoid emailing recovery codes or API keys inside an ordinary handover document.

Test the handover instead of trusting the checklist

I would ask the business owner or nominated team member to complete a few ordinary tasks before closing the project.

• 1. Sign in to the domain registrar and find the renewal settings.
• 2. Sign in to the CMS and make a safe draft edit.
• 3. Find the hosting or deployment account and identify the billing owner.
• 4. Open Google Analytics and Search Console with the correct level of access.
• 5. Submit a test enquiry and confirm delivery to the right destination.
• 6. Locate the agreed design or source files, plus any documented restrictions.
• 7. Find the backup or recovery procedure and the person responsible for restoring the site.

These checks reveal gaps faster than a long attachment list.

Document what happens after launch

A handover should answer ordinary operational questions.

• Who updates service pages?
• Who publishes new articles?
• Who reviews form submissions?
• Who fixes a broken integration?
• Who renews the domain and third-party licences?
• How are urgent fixes reported?
• What does the warranty or support window include?
• What work needs a new quote?

If a monthly partner handles these jobs, name the responsibilities. If the in-house team handles them, provide clear editing instructions and training where agreed.

Protect search and measurement during the transition

Existing sites carry history. Before replacing pages or moving platforms, confirm redirect plans, canonical URLs, sitemap updates, and analytics continuity.

A redesign launch should not quietly detach the business from Search Console or reset the tracking account without a reason.

Save a list of important URLs and key events before launch. After launch, test them again. Tracking might look fine in a dashboard while forms or real events fail, so use real test actions.

Finish with an acceptance record

Keep one short document showing:

• Assets delivered.
• Account owners.
• Access tests completed.
• Known open issues.
• Support owner.
• Relevant renewal dates.
• Final approval and date.

The aim is not paperwork for its own sake. The aim is a website the business understands and controls after the delivery team leaves.