A website handover checklist in Kenya should establish whether your business can operate its website after the launch meeting ends. Seeing the homepage online is only one part of acceptance. You also need to know who controls the domain, how routine updates happen, where enquiries arrive and who handles a problem when the original developer is unavailable.
This guide is for business owners receiving a new site or moving between suppliers. It focuses on operational handover rather than choosing a platform or negotiating a project price. If you are planning the build, discuss these requirements with your website developer before the work begins.
Start with a list of accounts and responsibilities
Ask the developer to list the services the website depends on. That may include the domain registrar, hosting provider, content management system, email delivery service, analytics tools and any separately billed integrations. For each service, record its purpose, the business contact responsible and the renewal arrangement.
The list should identify account ownership without containing passwords. Store credentials through your normal secure process, not inside a general handover document that may be emailed widely. Confirm that the appropriate business representative can sign in using their own authorised access. A screenshot of someone else's dashboard does not establish that your business can manage the service.
Distinguish between ownership and day-to-day support. A developer can provide hosting or manage renewals under an agreed service arrangement, but the responsibilities should be clear. Ask what happens if that arrangement ends, which records you receive and how the business requests an orderly transfer. Agree those practical details before a disagreement makes them urgent.
Check domain, hosting and renewal arrangements separately
Your domain name and website hosting may come from different providers. Record both. Ask who receives renewal notices, what the billing cycle is and how the business will know when action is needed. Do not assume paying for the website design also covers every future subscription indefinitely.
Check the contact details associated with important accounts through the relevant authorised person. Avoid making an employee's temporary personal email the only recovery route without a clear business continuity plan. If the supplier holds the account, ask how the business's rights and recovery process are documented in the service agreement.
A useful handover note explains what is included in the current plan and what requires a separate payment or request. It should also name the person responsible for reviewing renewal messages. A calendar reminder can support that process, but it should not be the only record of a service the business relies on.
Demonstrate the updates your team actually needs
Choose a few routine tasks and ask the staff member who will maintain the site to perform them during handover. Examples include changing office hours, updating a service description, replacing a downloadable document or publishing a news item. The test should reflect your actual website rather than a generic training presentation.
Use a safe preview or demonstration environment where possible. Agree which changes can be practised on the live site and how they will be checked. Do not use real customer records as training material when examples will do. Record any steps that remain confusing and request a short guide for those tasks.
Be precise about the limits of editing access. Some sites allow staff to change content while layout or functionality changes require developer support. That is a legitimate arrangement when it matches the agreement. The problem is discovering that a promised routine update cannot be made after the project has already been accepted.
Verify enquiry routing without creating misleading records
Ask the developer to demonstrate how a website enquiry reaches the correct person. Check the destination mailbox or workflow with the person responsible for responding. A success message on the form does not by itself prove that the business received anything or that someone will act on it.
Plan the test with your team. Use an agreed test environment or clearly identified internal test that does not trigger advertising conversions, sales follow-ups or unwanted messages to customers. Confirm who removes or excludes any approved test record from operational reporting. A handover should not distort the lead counts the business later uses to judge performance.
Also check alternative contact routes such as telephone, email and WhatsApp links. The person testing should verify that the destination is correct rather than relying on the label printed beside the button. Record who can update those details when the business changes its number or moves its office.
Confirm access to reporting in the right accounts
Ask which analytics and search tools have been configured and what each one measures. The handover should identify the website property, account and authorised business user. Do not accept a dashboard screenshot as a substitute for access if the agreement says the business will receive its own reporting access.
Google's Search Console permissions guide distinguishes owners from users with more limited rights. The relevant question is whether the business has the access needed for its responsibilities. Ask the developer to explain the selected arrangement and document it without sharing verification secrets in the handover pack.
Request a simple demonstration of a useful report, such as search queries or landing pages, and explain that reporting is not a ranking guarantee. Agree who reviews the reports and how findings become practical improvements. An analytics installation has limited value if nobody knows which account contains it or what the figures mean.
Agree backup, recovery and support expectations
Ask what is backed up, where responsibility sits and how a restore is requested. A copy of the website files may not include its database, uploaded assets or external configuration. The answer should describe the actual arrangement rather than promise that everything is backed up somewhere.
Discuss how restoration has been checked and what evidence can be shared. A recovery demonstration should use a suitable non-production destination rather than overwrite a working live site. Ask what information the business needs to retain for recovery and whether keeping that information current is included in the support arrangement.
Write down the support channel, hours and escalation contact. Separate a response target from a resolution promise. A developer may acknowledge an issue quickly while a third-party outage takes longer to resolve. Clear expectations help the business report the problem appropriately instead of sending urgent messages to several unrelated contacts.
Review deliverables and remaining work before acceptance
Compare the delivered website with the agreed scope. Record any outstanding content, integrations or corrections, together with an owner and next action. If an item is deferred, state how the site should behave until it is completed. Do not let a verbal “we will sort that later” become the only record.
Ask which source files, design assets and licences are included in your agreement. Different project models have different deliverables, so avoid assuming that one handover format applies to every agency or hosted platform. Confirm the actual terms and ensure the business can find the relevant agreements when needed.
Keep the accepted version, account inventory and support information together. Our website project planning guide covers the broader scope of an online store. For any project, operational handover should be a defined deliverable rather than something improvised at the end.
A practical acceptance record
Your final handover record can be a short table or checklist covering:
Domain, hosting and other required service references.
Authorised business access and recovery responsibility.
Renewal dates, billing contacts and plan inclusions.
Routine content tasks demonstrated by the intended staff member.
Agreed enquiry-routing checks and response ownership.
Reporting properties and access arrangements.
Backup scope, recovery process and support contact.
Remaining work, agreed deliverables and acceptance date.
Keep sensitive access information separate. Review the record when suppliers, staff or services change. A handover is useful only if it continues to describe the website the business is operating, rather than a project setup that ceased to exist months earlier.
Frequently asked questions
Is an administrator login enough for a handover?
It is one part of the process. Check the domain, hosting, renewal responsibilities and connected services too. The website editor may not control those accounts, and a supplier's dashboard demonstration does not establish the business's own authorised access.
Should I request every password in one document?
Use a secure access process and avoid placing passwords in a broadly shared handover pack. The document should identify services and responsibilities. Confirm access with the authorised people rather than distributing credentials to everyone involved in the project.
Can handover happen while small corrections remain?
Yes, if the remaining work is clearly recorded and the arrangement matches your agreement. Identify which items are incomplete, who owns them and how acceptance relates to them. Do not treat an undocumented promise as a completed deliverable.
How do I include handover in a new website brief?
Tell Mocky's website team who will operate the site, which updates staff need to make and what support you require. Ask for those tasks, account responsibilities and acceptance checks to be included in the proposed scope before development starts.
