Website Project Handoff Checklist
A website project handoff checklist covers every task that must be completed before a web project transfers from your studio to the client — credentials, DNS, CMS training, post-launch scope boundaries, and the final invoice. Work through each section in order. All items must be checked before the final invoice is sent.
The checklist
Section 1 — Pre-handoff delivery audit
Confirm everything is complete before initiating handoff.
- All agreed pages are live and accessible at the correct URLs
- All pages reviewed at mobile (375px), tablet (768px), and desktop (1280px+) breakpoints
- Cross-browser check completed (Chrome, Firefox, Safari minimum)
- All forms on the site have been tested end-to-end (submission → confirmation → notification)
- 404 page is configured and styled
- All agreed redirects are in place and tested
- Page speed reviewed — no obvious large uncompressed images or render-blocking scripts
- Favicon, Open Graph images, and social preview images are in place
- Google Analytics (or agreed analytics) is firing on all pages — confirmed in real-time view
- Google Search Console property set up and domain verified
Section 2 — Content and copy sign-off
- All copy matches the final approved draft (confirm version reference)
- All images have appropriate alt text
- No placeholder text ("Lorem ipsum") remains on any page
- All links (internal and external) tested — no broken links
- Legal pages in place: Privacy Policy, Terms of Service (client-supplied or noted as outstanding)
- Cookie consent banner configured if required by jurisdiction (GDPR / CCPA)
- Copyright year and business name correct in footer
Section 3 — Credentials and access transfer
Transfer all credentials before the final invoice.
- Domain registrar access: login credentials or transfer confirmation provided to client
- DNS access: nameserver or DNS record management confirmed with client
- Hosting control panel: client has an account with sufficient permissions (or server details handed over)
- SSL certificate: confirm it is valid, auto-renewing, and in the client's name or their hosting account
- CMS admin account: client's own admin account created with their email — studio's staging/dev accounts removed or downgraded
- Email hosting: MX records confirmed, client has access to email admin panel
- Third-party integrations: all API keys regenerated in the client's own accounts (not yours)
- Payment gateway (if applicable)
- CRM / marketing platform (if applicable)
- Booking tool (if applicable)
- Other: _______________
- Repository access: if client is technical, has been added to the repo with appropriate permissions
- Staging environment: either handed over or decommissioned — document the decision
Section 4 — CMS training and documentation
- CMS training session completed or scheduled
- Screen recording or written guide provided for the operations the client will perform
- Adding / editing blog posts or news items
- Updating team or service pages
- Managing products or listings (if applicable)
- Media library usage
- "How to..." reference document provided (links to CMS knowledge base, if applicable)
- Client knows how to contact hosting support independently
- Client knows what changes require a developer (vs what they can do themselves)
Section 5 — Post-launch scope boundary
Agree on what is and is not included post-handoff.
- Warranty / support period agreed and documented (duration, what it covers)
- Post-launch bug definition agreed: what counts as a bug vs a new feature request
- Ongoing maintenance or hosting retainer discussed — client knows what happens when the warranty expires
- Scope change request process explained — client knows to use the scope change request form for any additions
- Out-of-scope work rates provided in writing
Section 6 — Final invoice and project close
- All approved scope change requests (SCRs) reviewed — overage fees included in final invoice
- Final invoice itemised against agreed deliverables
- Any outstanding deposits or previous payments confirmed and reconciled
- Final invoice sent
- Client sign-off on the completed project received (email, typed form, or signed document)
- Project status updated to "Complete" in internal project database
- Time entries reconciled — no unbilled hours remaining
- Project files archived to agreed location (agency drive + client copy if agreed)
- Internal project debrief / notes filed for future reference
- Client added to onboarding or nurture sequence (if applicable)
Handoff summary record (for your files)
| Field | Value |
|---|---|
| Project name | — |
| Client name | — |
| Handoff completed by | — |
| Handoff date | — |
| Site URL | — |
| Hosting provider | — |
| Domain registrar | — |
| CMS platform | — |
| Support / warranty period | from [date] to [date] |
| Final invoice amount | — |
| Final invoice date | — |
| Client sign-off confirmed? | Yes / No |
| Notes | — |
How to use this checklist
Work through each section in sequence before the project is marked complete. Build it as an Ascend Database with one record per project, or use an Ascend Form that the project lead submits before the final invoice is approved. The handoff summary columns become the record.
Why web project handoffs go wrong
Most web project handoffs go wrong in one of three places. The first is credentials: the client ends up locked out of their own DNS, or the studio's development API keys remain in production. The second is scope: the client expects ongoing changes to be covered by the project fee; the studio expected to invoice for them. The third is the invoice itself: a rushed handoff misses approved scope changes, and the final bill doesn't reflect the work done.
A website project handoff checklist is the system that catches all three before they become a client relationship problem or a revenue loss.
The section most handoff checklists skip
Credentials and DNS are standard. The section missing from most website project handoff processes is the post-launch scope boundary conversation — and it's the one that generates the most disputes.
"Does this include fixing bugs after launch?" is a question both sides should have answered in writing before the site goes live, not after the first bug report arrives. The checklist forces that conversation by requiring it to be checked off before the invoice goes out. What counts as a bug. How long the warranty runs. What happens when it expires. What a new feature request costs.
Done in advance, it's a ten-minute conversation. Done after the first post-launch request, it's a difficult one.
Third-party integrations: the credentials trap
The most common credentials problem in web project handoffs isn't the hosting login — it's the API keys. A payment gateway, CRM, booking system, or marketing platform integrated during the build is often connected using the studio's own account or a shared key. When the project ends, those credentials stay in place. The client is now dependent on your account, and you're responsible for renewals and security.
The checklist addresses this directly: every third-party integration is checked off only once the client has their own account and the connection runs through it. If you built it with a staging key, it gets regenerated in production under the client's credentials.
The final invoice prompt
A common revenue leak in web projects: approved scope changes that were invoiced separately but then missed in the final invoice reconciliation. The final invoice section of this website project handoff checklist requires reviewing every approved scope change request against the invoice before it goes out. The five minutes this takes is a clean way to confirm nothing is missed — and the signed scope change requests are already the documentation.
Use the scope change request form template during the project so that documentation is ready at handoff.
Related templates
Website Discovery Call Checklist
Discovery is where the project scope is set — the handoff closes the cycle.
Scope Change Request Form Template
Every approved change request gets reconciled in the final invoice section.
Client Project Database Template
Update the project record to "Complete" once the handoff is done.
Frequently asked questions
What should a website project handoff checklist include?+
At minimum: a delivery audit (all pages, forms, redirects tested), credentials transfer (domain, hosting, CMS, third-party integrations), CMS training and documentation, agreement on post-launch scope and warranty, and final invoice reconciliation. A handoff summary record rounds it out — a single document confirming the project was properly closed.
When should I send the website handoff checklist?+
Work through it before sending the final invoice. The checklist is a pre-condition for the invoice — this ensures credentials are transferred, the scope boundary conversation has happened, and all approved change orders are included in the bill.
What credentials should be transferred at website handoff?+
Domain registrar, DNS management, hosting control panel, CMS admin (client's own account — not yours), SSL certificate management, email hosting admin, and any third-party integration API keys — all in the client's name and accounts.
How do I handle the post-launch scope boundary?+
Agree on a warranty period, what it covers, the rate for out-of-warranty work, and how the client should request changes. Send it in writing and get a confirmation before the invoice is paid.
What counts as a bug versus a new feature request after launch?+
A bug is behaviour that does not match what was agreed in scope or approved during review. A new feature is anything the client didn't ask for during the project, changed their mind about, or sees on another site after launch.
Can I use this checklist in Ascend?+
Yes. Build it as an Ascend Database where each project has a handoff record, or as an Ascend Form the project lead completes before the final invoice is approved. The handoff summary columns become the record.
What should I do with the completed handoff checklist?+
File it with the project records. It's the evidence that the handoff was properly completed — useful if a dispute arises later. The handoff summary record at the end of the checklist is a one-page reference for both parties.
Related checklist
Website Discovery Call Checklist
The checklist that starts the cycle — cover goals, scope, timeline, budget, and technical requirements before any work begins.
Close projects cleanly, every time.
A checklist on paper relies on someone remembering to run it. When the checklist is a record in your project database — required before the final invoice is created — the close process is part of the workflow, not an afterthought. Ascend keeps project records, time entries, and invoices connected. The free tier covers one client end to end.
Start with Ascend free