Final revisions can distract from practical questions. Where is the latest copy? Who can publish a change? Can your team open the project without the developer? Keep the answers in an accessible record, rather than scattered messages.
This checklist covers the deliverables from a new website commission. The broader process is covered in our guide to commissioning a business website. Here we focus on the files, access, checks and arrangements needed at handover.
The short answer: what accepting a website involves
You need a verified website version, the agreed access and materials, operating instructions and a list of unresolved issues. Each item should explain where the result is, who can use it and how it was checked. This lets someone return to the project months later without reconstructing every conversation.
The package depends on the platform and scope. Custom development may include a repository and setup instructions; a website builder may involve transferring the project and an available export. Agree the contents beforehand: this checklist helps define them, but does not automatically include every item in development.
What belongs in the handover package
Create one index linking to current materials. Mark each item as delivered, not applicable or outstanding. A blank cell does not explain whether something was forgotten or never agreed.
| Deliverable | What to record | How to check it |
|---|---|---|
| Code or platform project | Repository and version, or permitted export with its limitations | The assigned person opens the project and files |
| Content and source materials | Final copy, images and agreed design files; sources and usage terms | Files are accessible; language versions match the published content |
| Account access | Service, project name, user and agreed role | A business representative signs in with their own account |
| Instructions | Setup, updates, publishing and recovery procedure | The responsible person can find and explain the required action |
| Third-party services | Purpose, responsible person and location of billing terms | The list matches the actual integrations |
| SEO and forms, where agreed | Checked URLs, settings and the test enquiry result | Dated findings identify who confirmed the result |
| Open issues | Limitations, deferred work, assigned people and dates | Every item has a clear completion criterion |
For agreed search preparation, request the completed checks described in our guide to SEO before website launch. A statement that ‘SEO is done’ does not describe individual pages or confirm their Google rankings.
Verify access by signing in yourself
A business representative should sign in to the agreed services and find the website. Watching the developer's account does not verify your access. Check the role: viewing files, editing content and publishing may require different permissions.
- Accept the invitation and open the correct project, not just the service homepage.
- Demonstrate an agreed action safely, such as viewing settings or creating a draft.
- Record the role, check date and person who can help if access is lost.
Keep passwords, secret keys and recovery codes out of the handover document; use an agreed secure exchange method. The detailed guide to domain, hosting and email access covers account control and renewals. The handover package can link to that current service register.
Clarify what the code, content and export include
For delivered code, identify the version matching the live website and explain setup and publishing. List required settings without exposing secrets. Ask a specialist to use those instructions to run the delivered version in a test environment. For a hosted platform, clarify what remains within the service and what can be exported. An archive of pages may not reproduce forms, the editor or other server functions.
Collect final copy, used images and the source files included in the agreement. Record the source and known usage terms for fonts, photographs, templates and third-party components. Identify any separate subscription or purchase needed for your project. Having a file does not, by itself, explain its permitted uses.
Handover also does not mean every block can be changed through an admin panel. The editing method should fit the team; our guide to CMS needs for infrequently updated websites explores that decision. If a developer makes changes, record how to request and publish them.
Repeat a real user journey at the handover meeting
Work through the agreed deliverables together. Check the main journey from beginning to end: a visitor finds the service, submits a test enquiry and the recipient confirms receipt. A success message alone does not prove email delivery. Clearly label the test and avoid real customer details.
An illustrative example, not a XEVOR case study: a small furniture repair workshop receives its website with an estimate form. The owner opens it on her phone, submits a labelled test and finds the email in the business inbox. She then uses her own account to find the project and checks the agreed method for updating opening hours.
The record retains the checked URL, date, test recipient and instruction link. A new gallery suggested during the meeting goes on a separate request list. This keeps verification of the delivered website clear alongside ideas for its next version.
A ready-to-use handover record
Copy this template into a shared document. Check that the assigned people can open its links. It is a working team record; agree any contractual documentation separately.
- Project, live URL, date and delivered version: …
- Handover participants and business representative: …
- Code or platform project, materials and usage terms: …
- Verified access: service → user → role → sign-in date: …
- Update, publishing and recovery instructions; responsible people: …
- Connected services and link to their register: …
- Checked journey, result and recipient confirmation: …
- Open issues: remaining work → assigned person → date → verification: …
- Fault reporting channel and agreed arrangements for further work: …
Explain why an item does not apply, such as CMS editing being outside the scope. Do not mark an outstanding item complete on a promise to send it later. Add its completion date after verification.
What to agree before development starts
- Which files, access permissions and instructions are included?
- What platform limitations apply, and what can be exported?
- Who will update content, and is training needed?
- Where is the result checked, who accepts it and how are issues recorded?
- Which post-publication checks are included, and who closes outstanding items?
When planning a business website, discuss handover alongside pages and features. Tell XEVOR about the project and how your team will use it: who will change content and which materials you need. This helps define the deliverables before work begins.
Distinguish fixes from the next piece of work
A broken agreed form, a new calculator and a scheduled dependency update are different tasks. For a fault, record expected behaviour, actual results and steps to reproduce it. Compare these with the agreed scope and correction terms. Estimate new features separately, and agree response times rather than assuming them.
The handover record provides a starting point for the first month after launch. Regular checks and work boundaries are explained in our guide to website maintenance scope. Any ongoing technical support should reflect the platform, available access and specific tasks.
Website handover questions
Is a link to the finished website enough?
It lets you view the result, but does not explain access, materials or future changes. Check the agreed package and retain instructions identifying the responsible people.
Is source code always handed over?
That depends on the platform and agreed scope. Establish whether you will receive a repository, a project within a service or an available export, and which functions it covers.
Does the owner need to run the code personally?
No. An assigned specialist can perform technical verification. The owner should know where the current version is, who has access and how to request and check a change.
What if some access has not been provided?
Keep an open item naming the service, required role, responsible person and due date. Identify which agreed actions remain unavailable, then repeat the check once access is provided.
Does handover mean maintenance is included?
No. Correction periods, post-launch checks and ongoing maintenance each need a defined scope. Keep the agreed reporting channel, responsible person and process for estimating new work.