Leave with
control.

What good handover means

Handover is not just receiving a live link. A client should be able to identify what was delivered, who controls essential accounts, which third-party licences apply and how to find the final files later. The simplest test is this: could the business appoint another provider without guessing what exists or where it is held?

For a service-business website, the handover should be concise, dated and tied to the written scope. It should distinguish client-specific work from third-party products and from a provider's own reusable tools.

Before work starts: agree the control points

1. Name the account owners. Record who controls the domain, hosting, billing, analytics, email and any platform account. New client-facing accounts should normally be created in the client's name where practical.
2. List the handover items in scope. Specify which source code, editable designs, content exports, asset folders, access roles and written notes will be delivered.
3. Separate third-party items. Fonts, stock images, plugins, templates and hosted platforms have their own licences. List the supplier, licence route and renewal responsibility instead of implying the client owns them outright.
4. Choose the client-controlled archive location. Agree a client folder, repository or account before delivery. A project archive stored only in a provider's workspace is not a completed handover.

Final handover checklist

1. Live service record

• The final live URL and the date of handover.
• The pages, features and changes included in the agreed delivery.
• Any known platform limitation or excluded item that the client should not mistake for a fault.

2. Files and creative material

• Client-specific source code and editable design files only where they were expressly included in the written scope.
• Client-provided logos, copy, images and other project materials held for the work.
• Project-specific assets created for the project, with a note of their format and location.
• A list of relevant third-party fonts, images, plugins, templates and licences, including any renewal or account action the client must take.

3. Access and accounts

• The relevant administrator roles, plus a record of which provider access should be removed or reduced after handover.
• A confirmation that passwords are shared through a separate safe method, not pasted into an ordinary handover email.
• Any account that cannot be transferred, with the reason and the client's practical next step.

4. Backup and restoration note

• The archive contents, file versions and date.
• The client-controlled folder, repository or account where the archive is stored.
• The available content or database export, only if the relevant platform permits one.
• The practical restoration route: which account is required, which platform steps apply and any dependency that must be restored first.

What should not be promised

A handover note should not pretend that every platform can export everything, that a host's backup can be restored instantly or that a third-party licence can be transferred when its own terms say otherwise. State the actual route, the account needed and the limit.

Likewise, a short post-handover fault window is not an unlimited maintenance service. For Linshi Studio business projects, confirmed faults in the agreed delivered scope reported within seven calendar days are reviewed and repaired without an additional fee. Ongoing maintenance, new requests and third-party outages need their own scope.

A usable final record

Keep the final record short enough to use. A business should be able to open it six months later and answer five questions: what is live; what files exist; which accounts matter; what has to be renewed; and how to restore or appoint a new provider. That is more useful than a large unlabelled folder.

Linshi Studio's public business project agreement template describes the standard ownership, account-control, backup and restoration boundaries used as a starting point. The project-specific written scope remains the controlling record for an individual project.