Website Strategy
Website Handover Checklist: What You Should Receive When Your Site Launches
Use a website handover checklist to confirm account access, source files, content tools, integrations, documentation, training and support after launch.
A website handover gives the owner control and a clear operating path
A website is not fully handed over just because its pages are live. The owner needs the agreed access, source materials, account information, editing guidance and responsibilities required to operate it. Some assets or services remain governed by third-party licences; identify those separately rather than assuming the project transfers every external dependency.
Clarify handover requirements in the proposal or project agreement. Ownership, usage rights, hosting, licences and support terms depend on the agreement and provider, so document what applies to your project.
Confirm accounts, ownership and access
| Item | What to confirm |
|---|---|
| Domain and DNS | The business has access to the registrar and knows who manages DNS |
| Hosting or platform | Owner and administrator accounts are identified; billing responsibility is clear |
| Website administration | The right staff have named accounts and appropriate roles |
| Analytics and search tools | The business can access the properties and reports it uses |
| Forms and integrations | Credentials, provider ownership and notification destinations are recorded securely |
| Third-party licences | Paid themes, plugins, fonts, apps or subscriptions and renewal terms are listed |
Do not send passwords in a public document. Use the approved password manager or account invitation flow, then remove temporary access that is no longer required.
Collect the files and documentation your team will actually use
- The agreed source code, design files, content exports and original assets.
- A list of page templates, editable content areas and changes that require technical help.
- Instructions for routine updates such as adding a project, changing a service or replacing an image.
- A record of hosting, deployment, backup and recovery responsibilities.
- The final URL and redirect map for any pages moved during the project.
- Open issues, known limitations and any post-launch tasks.
A handover pack should match the project’s technology and the client’s role. A short walkthrough plus a few task-based instructions can be more useful than a long generic manual.
Test the site with the people who will own it
- Ask the business owner to sign in using their own account.
- Have the content editor update one agreed field or page.
- Submit forms and confirm the correct team receives the message.
- Check the site on the devices and browsers relevant to the audience.
- Review backups, analytics, redirects and the documented support route.
- Record acceptance and any agreed remaining work.
A handover is also the right time to confirm who pays for renewals, who updates third-party systems and how incidents are reported. Do not assume a developer will monitor a site indefinitely unless a support arrangement says so.
Separate defect support from ongoing changes
A launch warranty or defect window may cover agreed problems with delivered work. New features, content updates, platform changes and third-party failures may require a separate scope. Ask what response times apply, what access is needed and how work is prioritised after launch.
| Question | Why ask |
|---|---|
| What counts as a defect? | Sets a shared expectation for launch-related problems |
| Who monitors uptime and backups? | Makes operational ownership visible |
| How are changes requested and estimated? | Prevents unplanned work from becoming ambiguous |
| Which vendor issues are excluded? | Identifies dependencies outside the website build |
| How is access ended? | Supports secure account and credential management |
| Item | Record at handover |
|---|---|
| Domain | Registrant/account owner, renewal date and recovery contact. |
| Hosting or platform | Account owner, billing responsibility and access roles. |
| Code and content | Delivery location, licences and the process for routine edits. |
| External services | Named accounts, recurring subscriptions and who can remove access. |
| Support | What is included, who handles incidents and how extra work is scoped. |
Keep credentials in an appropriate private password manager rather than a public handover document. The scope and pricing guide separates build deliverables from ongoing responsibilities.
Questions about website handover
Should the client own the domain?
The business should know who controls the domain and billing and should have appropriate owner access. Confirm the arrangement in the project agreement.
Do I receive source code after a website project?
That depends on the agreed deliverables and any third-party licences. State code, design and content handover terms before the project starts.
What access should I receive?
Access to the business-owned domain, platform, hosting, analytics and relevant integrations, with account roles appropriate to each person’s responsibilities.
Is handover the same as ongoing maintenance?
No. Handover explains how the agreed site is delivered and operated. Ongoing monitoring, updates and new work need a defined support arrangement.
What should I do with the developer’s temporary access?
Review it after launch and remove access that is no longer needed. Keep any ongoing support access limited and documented.