A website handover gives your team the access, files and guidance it needs to run the site. It is complete when you can use the site, reach support and recover from a problem without relying on an informal favor. A password and a working homepage are only part of the handover.
Use this website handover checklist when you accept a finished site or move its care to a new provider. Use it in a joint session with your developer. You do not need to manage a server yourself. Do not change live DNS settings or restore a backup over your live site just to complete a check.
The practical standard is simple: for every important system, record who controls it, what your team can actually do, who pays for it and who helps when it stops working. Mark untested items as untested, not complete.
Ask your agency to list the services below, including the provider name, account identifier, responsible business contact, renewal date and agreed support contact. A small brochure site may need fewer entries than an online store.
Keep passwords, recovery codes and API keys out of this shared checklist. Ask your team to use an approved password manager or the provider’s invitation system. The checklist should reference where access is managed without exposing the credentials.
Watching a developer use their own account does not prove that your account works. Ask for your own account with the access you need. Sign in and save the result of each agreed check. Use a separate everyday editing account where appropriate rather than treating administrator access as the default for every employee.
Check: open the relevant account settings with your agency and confirm the business contact, billing contact and recovery arrangements. For a shared agency service, ask what happens if that service ends and what export or transfer route is available.
Pass condition: the business can identify who controls the account, how access is recovered and what happens on exit. Any dependency on the agency is explicit and accepted.
If it fails: record the missing access or transfer task with a responsible person and date. Do not remove the existing administrator before a replacement has verified the necessary access.
Check: on staging or an agreed test page, change a sentence, replace an image, preview the result on mobile and restore the original content. Ask the developer to show which areas are safe for your team to edit and which require development work.
Pass condition: a person who will actually maintain the content can repeat the task using the documentation.
If it fails: request a short recording or written instructions for that exact workflow. A tour of every dashboard menu is less useful than completing the task your staff need next week.
Check: submit clearly labeled test information through each important inquiry or booking path. Confirm the expected response on screen and receipt in the intended mailbox or business system. Avoid using real customer information in test records.
Pass condition: the designated employee can find and act on the inquiry. Record any expected processing delay rather than assuming every integration is immediate.
If it fails: ask the responsible provider to trace the delivery path. A success message alone is not enough acceptance evidence. Coordinate tests involving payments, subscriptions or outbound messages so they do not accidentally charge customers or trigger real campaigns.
Check: sign in to the correct analytics property and confirm that you can see the reports your business needs. Record the property identifier so a similarly named test property is not mistaken for production.
Google Analytics distinguishes access at account and property levels, and adding or removing users requires the appropriate Administrator role. Check the scope of access, not simply whether a login works. See Google’s guidance on Analytics user management.
Pass condition: reporting and access administration have named owners with suitable permissions. You do not need to give every person administrative control.
Check: ask for the latest backup time, its storage location, retention policy and the documented restore procedure. Agree how much recent work the business could tolerate losing and who is authorized to request recovery.
For a typical WordPress website, a full recovery needs both the database and the website files. A folder of images or a content export is not the same as a complete recovery package. The official WordPress backup documentation explains the two parts.
Pass condition: the responsible technical person can provide evidence of a restore test in an isolated environment and explain any exclusions. Record the test date and outcome. A backup dashboard showing a green status is useful, but it is not a restore demonstration.
If it fails: keep recovery marked unverified and agree a safe test. Before testing, the technical owner should isolate outgoing email, payments and integrations so the restored copy cannot act on live customers. Do not restore over the live site just to complete this checklist.
Separate the completed project from ongoing operations. Ask for a list of renewals with the currency, payer, billing cycle and consequences of cancellation. Include hosting, domain, premium plugins, fonts, stock assets and external services where applicable. Do not assume an agency subscription transfers to your business.
Name an owner for each task after launch. Include updates, backup checks, urgent problems, content edits, license renewals and checks on connected systems. State how to request help, the agreed support hours and how urgent issues are escalated. If the provider and your US team work in different time zones, write down the time zone explicitly.
Also distinguish defect fixes covered by the agreement from new features and routine maintenance. Ask for unclear terms to be clarified in writing; this checklist is an operational aid, not a determination of contractual rights.
This is a hypothetical example, not a Techfusion Gear client case study. A service business receives its website login and confirms that the contact form displays a thank-you message. During the handover session, the office manager submits a labeled test inquiry but cannot find it in the sales inbox.
The useful record is not “contact form done.” It is “customer inquiry delivery unverified; developer to trace delivery; office manager to confirm receipt after retest.” Keep the existing delivery arrangement in place until the replacement works. Once the test succeeds, save the result and remove the test record according to the team’s normal process.
This small distinction makes the checklist useful: it records an outcome that matters to the business, rather than a feature that exists on a page.
Please prepare a handover session covering our domain and DNS, hosting, website access, inquiry delivery, reporting, agreed files, licenses and backups. For each system, identify the account controller, business contact, renewal responsibility and support contact.
During the session, we would like our team to sign in, complete one safe content edit, verify a test inquiry and review recovery-test evidence. Please list anything that cannot transfer or still depends on your service, together with the agreed next step. Share credentials through our approved secure method, not in this document.
Copy the fields below into your project document and repeat them for each system. Store screenshots in a restricted project folder, excluding secrets and unnecessary personal information.
Do not mark the handover complete if a key business task fails. Keep missing access and untested recovery on the open-issues list. Lower-impact items can remain on an agreed exception list, with an owner and deadline. Use your actual agreement for payment and formal signoff decisions.
Once replacement access and services are verified, have the technical owner review obsolete accounts and credentials and remove or rotate them in a coordinated way. Avoid a blanket password reset that disconnects live integrations.
No. Also identify domain, hosting, recovery, reporting, license and support responsibilities. One dashboard login does not establish that all of those arrangements are in place.
Not necessarily. An ongoing managed arrangement may meet your needs. Make its responsibilities, costs, access and exit process explicit rather than assuming a move is required.
Coordinate removal with the responsible technical person after replacement access and ongoing services have been verified. Retain only access that is still agreed and needed.
If you are still choosing a provider, our website development company evaluation guide helps you raise ownership and support questions before delivery. For a new project, discuss handover deliverables as part of the scope, not as an extra request at the end.
Techfusion Gear offers website design and development services. Bring your current system list and unresolved checks when discussing a project or transition, so the conversation starts with what your business needs to operate safely.