A website handover should leave you able to understand and manage the business asset you have commissioned. That does not mean learning to maintain every technical component yourself. It means knowing which accounts, materials and responsibilities belong to the business, and who will handle the rest.
Whether you are commissioning a website in Cheltenham or reviewing an older arrangement, ask these questions before launch. They are practical questions about access and delivery, not a legal interpretation of ownership rights.
The details depend on your agreement and the tools used. "You own the website" is too broad to settle them by itself.
Distinguish rights, access and responsibility
These are related, but different.
Rights concern what your agreement allows you to use, change or transfer. Access concerns whether you can actually sign in to the accounts or obtain the materials. Responsibility concerns who is expected to keep the site working and pay for its services.
You might have access to a site editor without control of the domain. You might receive source files while relying on someone else to deploy changes. Neither arrangement is automatically wrong, but you should understand it before deciding whether it suits the business.
Ask the developer to describe each part separately.
Make the domain arrangements clear
The domain is the address customers use to find your business. Record which account holds it, who controls renewals and which email address receives important notices.
Confirm that the business has an agreed recovery route if the usual contact becomes unavailable. Avoid relying on a single person's memory or an inbox nobody checks.
If a provider manages the domain for you, ask what process would be used to transfer it or grant another authorised person access. You do not need to move it immediately to understand those arrangements.
Identify the materials included at handover
The deliverables should reflect the kind of site being built. Ask which of the following are included and in what form:
- Final approved text and original business images.
- Design files, where agreed.
- Website source files or repository access, where applicable.
- A content export or backup appropriate to the platform.
- A list of connected services and their owners.
- Instructions for routine updates and recovery.
- A record of third-party assets or subscriptions used.
A managed platform may not provide an export that reproduces every aspect of the site elsewhere. A source-code handover may require technical work to run in a different environment. Ask what the provided materials actually allow you to do.
Do not assume that all third-party software or imagery becomes your exclusive property. Clarify the relevant usage arrangements in the project agreement.
Decide which updates you will make
Being able to edit a paragraph is different from being responsible for software updates, backups or deployment. Agree the tasks you want to handle and the tasks you want support with.
Typical owner tasks include changing opening hours, replacing an approved photograph and updating a service description. More involved changes may need developer input.
At handover, try one representative edit yourself. Follow the instructions, preview the result and check that you understand how to correct a mistake. A short practical walkthrough is more useful than a long document you have never tested.
Record recurring services and responsibilities
Create a simple service register. For each item, record its purpose, account owner, billing contact, renewal pattern and support contact.
Include domain registration, hosting, platform subscriptions, email, form services and any other tools the website depends on. The costs may be paid directly or included in a support agreement; either way, the responsibility should be visible.
Agree what happens when something stops working. Who diagnoses a failed enquiry form? Who contacts a third-party provider? What support is included, and what is a separately scoped change?
This avoids treating every future request as either automatically free or automatically outside the relationship.
A practical handover acceptance exercise
Imagine a Cheltenham business has just approved its new website. This is a hypothetical exercise, not a description of an existing client project.
Before calling handover complete, the owner signs in using their own authorised access, finds the renewal information, changes a draft paragraph and sends a test enquiry. They locate the agreed files and know who to contact if the site becomes unavailable.
The developer confirms the backup or recovery arrangement, the support boundary and any remaining actions. Unfinished items are written down with an owner rather than being hidden behind the word "launched".
Use that exercise as a starting point and adapt it to the actual system. A static site, an online shop and a managed booking site will need different checks.
Put the agreement in place early
Ask about ownership and handover while choosing a web developer. It is easier to agree deliverables before the work starts than to reconstruct expectations after a supplier change.
If you are already preparing to move, the new developer transfer checklist helps identify access and continuity questions.
For website design and development in Cheltenham, James can discuss how the ongoing arrangement should fit your business. Share what you want to manage yourself, what support you need and any existing setup that the project must preserve.