A website handover should leave your business able to access the right accounts, locate the agreed files, understand how changes reach the live site and know who handles problems. Ask for a written inventory, verify it using your own authorized access and record anything still outstanding before closing the project.
This website handover checklist is for a business receiving a new website or changing the team that maintains one. It covers practical control and continuity. Which assets, permissions and services you are entitled to receive depends on your agreement; an account invitation or a folder of files does not by itself settle intellectual property rights.
1. Agree what the handover includes
Start with the proposal and the final agreed scope. List the pages, languages, integrations and editable materials being delivered. Separate the live website from its source files, design files, content exports and third-party services. A website built in a hosted editor may have a different export process from a custom codebase, so ask what another authorized supplier would need to maintain this particular site.
Write down the handover date, the exact version being accepted and the person responsible for each item. If work continues after launch, identify which version the documentation describes. A recording of an old editor or an archive made before the last correction can be misleading even when every expected folder exists.
Use three simple states: received and checked, received but unverified, and outstanding. “Sent by email” is not the same as “usable by the receiving team”. Add an acceptance note that explains the check, such as opening the design file in the agreed application or signing in to the hosting account with the intended role.
Choose the delivery format early
Keep a short inventory in a shared location the business can retain. Store supporting files in clearly named folders, with a version or date where it matters. Do not turn that inventory into a password document. Record where credentials are managed and who can grant access, while keeping secrets in an appropriate secure system.
2. Check accounts, domain and billing responsibilities
Identify the domain registrar, DNS provider, hosting service, website editor or code repository, and any form, booking or email service the site depends on. These may be separate accounts. Being able to edit a page does not necessarily let you renew the domain, change the billing contact or restore the website.
For each account, record the organization responsible, the invited user, permission level, renewal or subscription owner and recovery contact. Use individual invitations where the platform supports them. Verify that the right people can sign in using their own accounts and complete the tasks their role requires. Follow the provider's process for multifactor authentication and recovery; avoid passing around one shared administrator password.
Ask the current team to explain which DNS records support the website and which support email or other services. Keep a dated record of the configuration before an agreed change. Cloudflare documents importing and exporting DNS records; other providers have their own controls. An exported record list is useful evidence, but it is not a complete backup of every service attached to the domain.
A handover need not involve moving every provider. If a transfer is necessary, agree the receiving account, dependencies, timing and checks first. Do not cancel the existing service merely because a new invitation arrived. Confirm who pays the next renewal and where important notices will go, especially when the original contact is leaving the project.
3. Build an inventory you can actually verify
The following worksheet is a starting point. Replace the examples with your actual systems and agreed deliverables. Assign a responsible person and status to every row. Where an item is outside the project scope, record that explicitly with the next action instead of silently treating it as delivered.
| Item to record | Evidence to request | Receiving team's check |
|---|---|---|
| Domain, DNS and hosting | Account locations, roles, renewal contact and configuration record | Authorized people can find the services and see the required settings |
| Website source or editor | Repository or workspace, accepted version and publishing instructions | The receiving team can open the project and identify the live version |
| Content and design materials | Agreed editable files, exports, asset list and license references | Files open correctly and any usage or editing limits are documented |
| Forms and integrations | Destinations, responsible accounts, dependencies and safe test procedure | An agreed test shows the intended journey without contacting real customers |
| Backups and recovery | Backup location, coverage, date and restore instructions | A safe recovery demonstration covers the relevant parts of the site |
| Support and outstanding work | Contact route, scope, coverage period and issue list | Each unresolved item has an agreed next action and responsible person |
Ask for evidence you can revisit after the call. A short recording can explain a routine content change; a written command or publishing sequence can help a technical maintainer. Neither should expose secret keys. The inventory should point to those materials and say who keeps them current when the site changes.
Check source access separately from publishing access
A code repository and a hosting account serve different purposes. If a repository transfer is agreed, review its integrations and permissions afterwards. GitHub notes that webhooks, secrets and deploy keys remain associated with a transferred repository. A transfer therefore does not replace a review of who and what can still act on the project.
4. Make files and recovery instructions usable
Request the materials named in your agreement in a format the receiving team can use. That might include editable page content, image originals, approved logo files, design documents and source code. List external fonts, stock images, plugins and other dependencies with the account or license information needed to clarify continued use. Do not assume that every third-party asset can be transferred or reused without restrictions.
For a custom build, ask for the supported runtime, dependency installation instructions, build command, configuration variable names and the process for previewing and publishing a change. Keep actual secret values out of the general documentation. A capable maintainer should be able to identify which settings belong to a test environment and which connect to live services.
Define what a backup includes. WordPress documentation explains that a typical WordPress restore needs both the database and the files. For another platform, ask the supplier to describe its equivalent dependencies. A screenshot, a source archive or an export of page text may each be useful, but none should be labelled a complete recovery plan without explaining its limits.
Agree who makes backups, where they are stored, how long they are retained and how restoration is checked. Request a demonstration in a safe environment, with customer data handled appropriately. Record what was restored and what remained outside the exercise. Do not use the live website as an improvised recovery test or assume an untested archive will solve every outage.
5. Run a short acceptance walkthrough
Use the receiving team's own authorized accounts for the walkthrough. Find the accepted website version, open the editor or project, locate the support instructions and demonstrate a routine change in a preview or test environment. The goal is to see whether the next person can operate the site using the delivered materials, rather than depending on explanations that only exist in the supplier's memory.
Review a small set of real customer journeys: read a service, navigate on a phone, reach the enquiry route and inspect the agreed confirmation and error states. Use a safe testing arrangement for forms, bookings and payments. Agree test addresses and destinations in advance so a handover exercise does not send messages to real customers or create unintended orders.
Check that search and measurement accounts, where included, have appropriate access too. Google Search Console distinguishes owners, full users and restricted users, and explains how verification tokens affect verified ownership. A Search Console permission review is separate from access to the website itself. Record the relevant property and role without treating access as proof that Google has indexed every page.
A hypothetical handover for a consultancy
Imagine a consultancy receiving a five-page website. Its manager can edit text, but renewal notices still go to a former supplier and the form's destination is undocumented. The team records both gaps, confirms the billing contact through the provider's process and documents the form route with an agreed test. The manager then repeats a preview edit using the delivered instructions. This is an example of the method, not a reported client result.
6. Define support and review remaining access
Write down what happens after acceptance. Who handles an outage, a failed form, a content change or a subscription renewal? Separate correction of agreed delivery defects from new features and ongoing maintenance. State the agreed contact method, coverage period, charges where applicable and any response commitments. Do not infer round-the-clock monitoring from the existence of a support email address.
Keep a short outstanding-work list with the issue, impact, next action, responsible person and review date. Decide which issues block acceptance and which can be handled afterwards under an explicit agreement. If a booking integration remains unavailable, for example, record the fallback customer route and who decides when the final integration is ready.
Review departing collaborators, invitations, integration tokens and recovery contacts after the receiving team has verified continuity. Retain only the access that supports the agreed ongoing work. Coordinate removal or rotation with the responsible technical person so the cleanup does not unexpectedly stop publishing, forms or another dependent service. Preserve a record of the decisions without storing secret values in it.
7. Put handover requirements in the website brief
The easiest time to agree a useful handover is before work starts. Add your expected editors, internal technical capability, required files, account arrangement and support needs to the website project brief. For an existing site changing suppliers, combine this inventory with a redesign review so responsibility for existing services stays visible.
Before closing the project, confirm that the inventory matches the agreement, required access works, delivered files open, the safe walkthrough is recorded and unresolved work has an owner. Keep the accepted version and handover notes together. That gives your next maintainer a practical starting point when a change or problem arrives.
Digital Studio's website service starts at EUR 2,190 for a one-off build of up to five pages using supplied content, with responsive design, SEO foundations, one lead form and launch on your domain. Specific handover materials, transfers, training and ongoing support should be agreed in writing for your project; this checklist does not add them to the published package. Describe your website and handover needs so the scope can be discussed before work begins.
