Website Handover Checklist: What You Should Receive When Your Project Ends

On this page

1. Agree the handover before work starts
2. Logins and access
3. Documentation
4. Training
5. Licences and renewals
6. Backups and source files
7. Support terms after launch
8. Handover sign-off checklist

The last day of a website project is easy to rush. The site is live, everyone is relieved and the final invoice goes out. But what you receive at handover decides how easily you can run, update and, if needed, move your website for years to come. Here's what a proper handover should include, whoever builds your site.

This is different from making sure accounts are registered in your name in the first place; for that, see the website ownership checklist. Handover is the moment you confirm you've actually received everything.

Agree the handover before work starts

The easiest time to agree what you'll receive is before the project begins. Add a short handover list to your quote or contract, alongside payment terms and ownership; the website design contract checklist covers what else to agree. Then, on handover day, you're ticking off a list rather than negotiating.

Logins and access

You should receive, or already hold, working access to everything the site depends on:

• Your own WordPress Administrator account, not a shared developer login
• Domain registrar and DNS, including Cloudflare or similar if used
• The hosting control panel, which gives SFTP and database access
• Business email admin
• Google Analytics, Search Console, Tag Manager and Google Business Profile, with you as owner
• Payment gateway, courier, CRM, booking and email marketing accounts connected to the site
• Any service used to send website emails (SMTP) or block spam

Credentials should be shared securely, ideally through a password manager, not pasted into a WhatsApp chat or email. Log in to each one yourself before you sign off, then change the passwords. If your developer will keep maintaining the site, they should have their own separate account that you can remove later.

Documentation

A short handover document saves hours for you and for any developer who works on the site later. It doesn't need to be long, but it should cover:

• How the site is built: theme, child theme, page builder or block editor
• A list of plugins and what each one does
• Where any custom code lives and what it does
• How forms work: where entries are stored and who receives the emails
• Integrations such as payments, WhatsApp, CRM or booking, and which account each is connected to
• Caching, security and scheduled tasks worth knowing about
• Known limitations and settings not to change

Passwords and API keys don't belong in this document. Keep them in your password manager instead.

Training

You should be able to handle everyday updates without calling your developer. A good handover includes a live walkthrough, ideally recorded, showing how to:

• Edit text and images on pages
• Add blog posts, team members, projects or products
• Manage orders, bookings or enquiries, if your site takes them
• Update menus and the footer
• Check form entries and where they go

Short written notes or screen recordings are worth asking for too. They're useful when a new staff member takes over the website.

Licences and renewals

Item	What to confirm
Premium theme and page builder	Whose account holds the licence, the licence key and the renewal date
Premium plugins	The same; a lapsed licence usually means no more updates
Fonts and stock images	That the licence covers use on your business website
Domain and hosting	Renewal dates, auto-renew and the payment method on file
Other paid tools	Plans and who is billed for forms, booking, email or chat services

If a licence stays in your developer's name, get that in writing, along with what happens if you part ways.

Backups and source files

• A full backup (files and database) taken at launch and stored somewhere you control
• Automatic backups scheduled, with at least one test restore done; see the backup and restore guide
• Design files, such as Figma files, if a designer was involved
• Logo files in vector formats, plus brand colours and fonts
• Original photos and videos, not only the compressed versions on the site
• Custom theme or plugin code, and access to the code repository if one was used
• Details of any staging site and how to use it

Support terms after launch

Launch is rarely the end of small fixes. Before you sign off, be clear about:

• How long the free bug-fix period lasts and what it covers
• What counts as a bug and what counts as a new request; see bug or change request?
• How to report problems and typical response times
• Who is responsible for WordPress, theme and plugin updates from now on
• Maintenance plan options, if you want ongoing help
• What happens in an emergency, such as the site going down or being hacked

Handover sign-off checklist

1. I've logged in to WordPress, hosting, domain, email and Google accounts myself
2. Passwords are changed and stored in our password manager
3. I have the handover document and the training recording
4. Licences and renewal dates are listed, with the account each one is under
5. A launch backup is stored in our own storage
6. Design files, brand assets and original media have been delivered
7. Support terms are agreed in writing

Only when every item is ticked is the project truly finished.

Want a developer who hands everything over properly, or ongoing help after launch? See hire a WordPress developer or WordPress maintenance.