Need urgent help with your website?Describe your issue and we will respond as quickly as possible.

Website handover checklist: access, backups and responsibilities

To hand your website over to a new support provider, list its services and accounts, prepare a backup that can be restored, document essential functions and agree who is responsible for each task. Then check that the new provider can do the agreed work while you retain control of the website and its payments.

A CMS login alone is rarely enough. Enquiries may depend on a separate email service, the domain may renew through another account, and the previous developer may hold the source code. This checklist brings those details into one document. It applies to websites built with a CMS, a website builder or custom code; the handover process will depend on the platform.

Define what you are handing over

Changing support providers, moving to another host and transferring domain ownership are separate tasks. A new provider does not automatically mean a new server or a rebuild. Start by recording the goal: for example, keeping enquiry forms working, updating information and fixing issues within an agreed scope.

Write a short description of the website:

  • Its purpose: enquiries, sales, bookings or publishing content.
  • Essential functions: forms, customer accounts, shopping cart, payments, search and language versions.
  • Existing faults and changes already in progress.
  • Who makes decisions and who approves completed work.

If the website is already down, start by diagnosing the failure and preserving the current data. Complete the full handover once essential functions have been restored. For a failure specifically after a WordPress update, see our separate guide to the first checks, in Russian.

What to request from the previous provider

Adapt the table to your website. Remove irrelevant rows and mark unknown details as “needs checking”. Do not replace a confirmed account owner with an assumption.

ComponentWhat the handover should establish
Domain and DNSWhere the domain is registered, who controls the account and DNS records, and who receives renewal notices.
Hosting or platformWhere the website runs, who pays for it and how the new provider gets the access they need.
CMS, code and filesLogin address and user roles; for custom development, the repository and instructions for running or deploying the site.
BackupsDate, contents, storage location, how to retrieve them and the result of a restore test.
Forms and emailWhere enquiries should arrive, which service sends the messages and who manages it.
IntegrationsCRM, payments, delivery and other connections: their purpose, responsible people and access management.
Licences and subscriptionsSeparate charges, whose account holds each licence and whether use can continue after changing providers.
Analytics and work historyConnected systems, who has access, and where to find task records, changes and known limitations.

Also request a list of manual configuration changes and unfinished tasks. “It is all in the admin panel” does not explain where backups come from or why notifications depend on a former employee’s personal account.

Keep control of your accounts

The business owner should retain access to essential services and be able to recover it without relying on one particular contractor. Check the contact email, recovery methods and delivery of renewal notices. For domains, consult ICANN’s guidance on protecting registrar accounts.

Where a service supports separate users, give the provider their own account with permissions appropriate to the task. Do not hand over your entire personal email account to grant access to one website. Keep passwords, recovery codes and API keys out of the shared handover document, and agree in advance how access will be granted.

Protect important accounts with the options available: passkeys, or a unique password with two-step verification. Review the previous provider’s access once the handover is complete. These measures follow NCSC guidance on securing business accounts.

If the website uses shared credentials or an integration key, the specialist should first identify which processes depend on them. Replacing them requires a planned switch and checks; otherwise, removing old access could also stop enquiries reaching you. Transfer ownership of domains or accounts according to the relevant service’s rules.

Check that the backup can be used

“We have a backup” does not tell you what can be restored. For a website with a separate database, check that the backup includes the database, files and uploaded content. For a website builder or cloud platform, check the recovery options and export limitations; these may differ from backing up conventional hosting.

Ask for the backup date, a list of its contents and the result of a restore test in a separate environment, where the platform allows it. The NCSC recommends understanding how to restore important data and check that nothing is missing, as well as making copies. See its backup guidance.

For an online shop or a website that receives enquiries, discuss data added since the last backup. A maintenance handover should not quietly become a rollback that loses new orders. Backups may contain customer information, so grant access only to people who need it for the agreed work.

Agree who is responsible for what

For each recurring task, record who does it, the deadline or trigger, and how completion is checked. For example:

  • Domain and hosting renewals: who receives notices, pays and checks the result.
  • Backups: who monitors creation, storage and restore testing.
  • Updates and development: who approves changes, implements them and checks essential functions.
  • Faults: where to report them, who receives the report and how urgent work is agreed.
  • Content: who supplies facts, edits and publishes material.

Do not assume that “website support” automatically includes round-the-clock responses, new pages, licence fees or every integration. List the terms explicitly so neither side has to guess.

Website handover template

Copy this block into a working document. Add a separate entry for each component in the table above. Do not include secret values in it.

Website:
Purpose of the handover:
Date and owner's contact person:
New provider and agreed scope of work:

Component or service:
Service URL / documentation location:
Account owner:
Person responsible for payment and next renewal:
How access will be granted and required role:
What has been handed over:
What is still missing:
How it was checked and by whom:
Status: not started / in progress / verified

Backup: date, contents and location:
Restore test result:
Known faults and unfinished changes:
Essential functions to check before acceptance:
Who confirms completion of the handover:

If information is missing, record a specific task and owner: “Find out who pays for the email delivery service.” This keeps an unresolved issue from disappearing behind a general “access received” tick.

How to confirm the handover is complete

Test the user journey the website exists to support. For a service business, that might mean sending a clearly labelled test enquiry and confirming that the right person receives it. For a shop, agree how to test ordering, delivery options and payment using the appropriate test mode.

Before closing the handover, confirm that:

  • The owner controls essential accounts and receives important notices.
  • The new provider has the necessary permissions and documentation.
  • Essential functions have been checked and any faults recorded.
  • Backup contents and availability are understood; the restore test result is recorded, or the absence of a test is explicitly noted.
  • Unfinished tasks, renewals and the boundaries of support have named owners.
  • Unnecessary access has been reviewed, and changes to shared keys have included checks of dependent functions.

Illustrative example. A company hands over a small services website. The new specialist can log in to the CMS, but a test enquiry never arrives. They discover that email delivery relies on a separate service managed by the previous provider. The handover remains open until access is granted and delivery has been checked. This is a teaching example, not a client case study.

Frequently asked questions

Do I need to change hosting when I change providers?

Not necessarily. First establish whether the new provider can work with the current hosting and whether it meets the website’s needs. Treat migration as a separate task with its own reasons, steps and checks.

What if the previous developer does not respond?

Collect what the business already holds: invoices, service contact details, its own accounts and project documentation. Discuss account recovery with the relevant service’s support team. A new provider cannot guarantee access to someone else’s account or missing source code. Record unavailable components as limitations.

Is handing over a website archive enough?

An archive may be only part of the handover. You need to know its contents, date, how to run the site and which external services it depends on. On some platforms, granting an account role and supplying documentation matters more than providing files.

How much does a support handover cost?

The scope depends on the documentation, available access, number of integrations and condition of the website. To request an estimate, prepare the URL, the purpose of the handover and a list of known limitations. If you need help, send your website address and describe the support you need.


👍
❤️
😂
😮
😢
😡
🤔
👏
🔥
🥳
😎
👎
🎉
🤯
🚀
₿
Ξ
Ł
Ð
🌕