Ownership & handover
Website ownership, hosting and handover checklist
A finished website is not a complete handover if the buyer still does not know who owns the domain, where the source lives, which third-party accounts are required or how to recover access when the original provider is unavailable.
Practitioner review
Rana Shakeel
Backend & Systems Engineer
Reviewed
2026-09-17
Meaningful update: 2026-09-17
Direct answer
Website ownership, hosting and handover checklist
Before signing, confirm who controls the domain, hosting and third-party accounts; what custom source and documentation are handed over; which reusable or licensed assets are excluded from transfer; how backups and credentials are handled; and whether maintenance is included or separately scoped.
Assumptions
- The written project terms identify the deliverables and payment conditions that trigger handover.
- Third-party services remain governed by their own licences, account rules and recurring charges.
Limits
- Ownership of custom project code does not transfer ownership of third-party libraries, fonts, media or platform services beyond their licences.
- Operational maintenance responsibilities should be documented separately from one-time source handover.
Ownership should be decided before launch, not discovered after it
A website normally depends on several separate assets: the domain, DNS, hosting, repository/source code, analytics, email, forms, fonts, imagery, payment tools and other integrations. These do not automatically share the same owner just because one provider configured them.
The safest project structure makes each ownership boundary explicit before implementation expands. That reduces lock-in, prevents billing surprises and makes future maintenance easier to transfer.
Core ownership checklist
| Asset | What the buyer should know | Preferred evidence |
|---|---|---|
| Domain and DNS | Which account owns the domain, renewal responsibility and who can change DNS. | Registrar account ownership and recovery access. |
| Hosting | Provider, plan, billing owner, deployment access and commercial-use constraints. | Account owner plus documented project/environment name. |
| Source code | What custom project source is included, when it is handed over and what reusable/third-party code keeps separate terms. | Repository/archive plus written ownership terms. |
| Analytics/search accounts | Who owns Analytics, Search Console, Bing Webmaster and related verification methods. | Client-controlled account access where practical. |
| Third-party services | Email, booking, payments, CRM, maps, storage, APIs and their own quotas/fees. | Account register with owner and billing responsibility. |
| Content and media | Who supplied each logo, photo, font or licensed asset and whether continued use is permitted. | Asset/source record or licence where applicable. |
| Credentials | How access is transferred without exposing secrets in source control or public documents. | Secure transfer and recovery procedure. |
What source-code handover means at Zolesco
Zolesco's published policy is that custom project source code is provided after full payment according to the written project terms. Pre-existing reusable components, generic utilities and third-party packages keep their original ownership or licence terms.
That distinction matters because a project can contain both bespoke client work and dependencies that no agency has the right to relicense as exclusive property. The proposal should describe the handover in practical terms rather than using a vague “you own everything” promise.
Before final acceptance
1. Verify production access
Confirm the client can access the relevant domain, hosting, analytics and third-party accounts.
2. Receive the agreed source and documentation
The handover package should match the written scope and not contain secrets that belong outside source control.
3. Record recurring dependencies
List services with renewals, quotas or paid plans so the operating cost is not hidden after launch.
4. Confirm support boundaries
Know the defect-correction window, what counts as maintenance and how new changes are estimated.
5. Test recovery
At minimum, make sure account recovery and project restore responsibilities are known before the original implementation context fades.
Build an acceptance evidence pack, not just a handover email
| Control | Acceptance evidence | Why it matters |
|---|---|---|
| Owner vs access | Record who owns each domain, DNS, hosting, repository, analytics and third-party account and who merely has delegated access. | Access can be revoked; durable control should be explicit. |
| Repository / buildability | Confirm the agreed source archive/repository is accessible and the documented build/deploy path is usable without hidden credentials. | Source possession is weaker if nobody can reproduce the delivered project. |
| Recovery | Record account recovery, backup/restore and emergency ownership responsibilities without placing secrets in the handover document. | A transfer is incomplete if the buyer cannot recover critical systems. |
| Renewals | List recurring domain, hosting, licence and third-party service renewals with billing responsibility. | Prevents operational surprise after the implementation context fades. |
| Support boundary | Record the defect-correction window, optional maintenance scope and how future changes are estimated. | Separates acceptance from an assumption of unlimited support. |
Hosting and maintenance are separate decisions
Owning the source does not remove the need for hosting, domain renewal, third-party services or future maintenance. Likewise, paying a provider for maintenance does not require that the provider permanently own the domain or business accounts.
For Zolesco projects, domains, hosting and paid third-party services retain their own provider charges unless the written proposal states otherwise. Post-launch support is defined in the project terms rather than implied to be unlimited.
Working conclusion
A clean handover makes the buyer's control visible: domain, hosting, source, analytics, integrations, credentials, licences, recurring costs and support responsibility should all have an identifiable owner.
Evidence and further reading
Zolesco sources describe our own published scope and policies. External sources are used as decision-context evidence; they are not proof of Zolesco outcomes or endorsements.
Continue planning
Related buyer guides
How to choose a website redesign partner without relying on the sales pitch
The right provider is the one whose delivery model matches the risk and complexity of the project. A useful evaluation looks beyond portfolio aesthetics to scope clarity, who actually does the work, migration planning, acceptance, ownership and post-launch responsibility.
Read guide Website rebuild costWebsite redesign cost: what actually changes the quote?
A useful website redesign quote is not just a page-count number. It should make the work, responsibilities, exclusions and technical risk visible enough that two proposals can be compared on the same basis.
Read guide Timeline & readinessWebsite redesign timeline: what makes a project move faster or slower?
A redesign schedule is usually controlled less by the calendar than by readiness: agreed scope, available content, timely decisions, integration access and a review process that prevents the project from repeatedly reopening finished work.
Read guide