# Website Project Handover Checklist: Accounts, Source Code, Domain, Hosting, and Documentation

Source: https://www.jvds.cn/en/share/website-design/website-project-handover-checklist
Language: en
Published: 2026-09-19
Author: JVDS Design Studio

Website handover should involve more than an email containing a source-code attachment and a CMS account. The company needs to know where assets are held, who can manage them, what requires ongoing payment, how to recover after a failure, and whether the site can keep running after personnel changes. Check accounts, code, data, content, licenses, and operations separately, and confirm them through an actual takeover exercise.

The company should hold agreed control over core assets, with routine operations assigned by role. If a platform prohibits a particular transfer, files cannot be exported, or a license is non-transferable, explain the current limits and alternative arrangements. Receiving a ZIP file does not establish complete ownership or unrestricted migration.

## Build an Asset Register and Distinguish Owners From Administrators

List domains and DNS, hosting and CDN, code and deployment, CMS and media, analytics and email tools, and third-party licenses. For each, record the platform, address, purpose, owning entity, administrator, payer, expiration or renewal time, recovery channels, and responsible staff.

The ability to log in does not mean the owner, payer, or highest level of control has changed. First verify the company’s permissions and who controls the recovery email and authentication methods. If the supplier’s personal email is the only recovery route, a takeover gap remains. Use roles or subaccounts where supported instead of sharing the primary account among everyone.

Where two-factor authentication is involved, also check authentication devices, authenticator applications, backup recovery channels, and responsibility for keeping recovery codes. Use the platform’s supported procedure to verify that the new responsible person can take over. Changing a password is insufficient if login still depends on the former owner’s device. Deliver recovery codes through the agreed secure method rather than placing them in ordinary handover documents.

Do not put actual passwords or keys in the checklist; store them using the company’s agreed secure method. Handover documentation should explain how to obtain required access and who approves changes and recovery. Mark missing information as awaiting confirmation, rather than filling gaps with guessed platform names or renewal dates.

## For Domain Handover, Identify Which Layer Needs to Change

Confirm the registrar, management account, registered holder, DNS service, and renewal responsibility separately. “Transferring a domain” can mean changing registrars, moving it between accounts on the same platform, or changing the registrant. These affect different objects. Alibaba Cloud’s official guidance also distinguishes these three situations; they cannot be treated as one button.

If the company is already the registered holder and the domain merely sits in the supplier’s account, assess account and permission takeover first. Check transfer-out and transfer-in conditions when changing registrars. If registrant details need changing, follow the relevant procedure. Changing the website supplier alone does not require every action at once.

Before making changes, export current DNS records and document dependencies such as the website, email, certificates, and search verification. Registration and DNS may use different providers. Transferring domain management does not guarantee that DNS configuration moves with it. Do not delete unfamiliar TXT or email records; ask the maintainer to confirm their purpose first.

Check actual restrictions, verification requirements, and migration arrangements with the relevant platform. Afterward, verify new management access, the expected registrant information, DNS, and critical services such as the website and email, then update renewal and recovery responsibilities. A successful transfer message alone does not guarantee uninterrupted service.

## Code, Hosting, and Backups Must Support Redeployment and Recovery

Source-code handover should cover the final published version, corresponding history or version records, dependencies, build instructions, and necessary configuration examples. Handle sensitive credentials separately. Explain the usage conditions for commercial plugins and private components. A package of source files does not mean all third-party licenses have also been transferred. [The boundaries of website source-code delivery](https://www.jvds.cn/en/share/website-design/website-source-code-ownership) can help establish scope in advance.

Hosting and deployment documentation should cover environment versions, deployment locations, processes and databases, certificates, logs, monitoring, updates, and rollback procedures. Distinguish production, test, and preview environments so the new maintainer can find the version currently in use without guessing from directory dates.

Backups should cover code, databases, and uploaded materials as required by the actual architecture, with retention periods and storage locations documented. A successful backup job does not establish recoverability. Verify reading and restoration in an authorized isolated environment; do not overwrite live business systems simply to run an exercise.

Have someone who did not develop the site build or deploy a test version using the instructions, recording steps that require ad hoc questions. Turn missing dependencies, private download access, or configuration into explicit action items. An application running on the original computer does not establish independent deployability.

![Backup](https://www.jvds.cn/upload/2026/0824/1787562396048-494460.webp)

Conceptual illustration of hosting, CDN, and backups supporting independent recovery

## Identify Handover Items for the CMS, Content, Design, and Operational Tools

CMS documentation should explain actual roles, editing and approval, drafts and publication, file management, and recovery limits. When exporting articles, products, case studies, forms, and media, check fields, URLs, images, and relationships. For multiple languages, also preserve counterpart relationships, translation states, and regional differences.

For form data, confirm export scope, access roles, retention and deletion rules, and who implements those rules. Verify retention periods against the company’s actual policies. Unconfirmed items are handover gaps; the new maintainer must not arbitrarily erase the data or assume it should be retained forever.

Different platform scopes provide different export capabilities. Actually export representative content and open it for inspection, identifying what requires manual handling and what cannot be migrated. A usable current CMS does not prove that a future migration will be complete. The handover package must record real conditions.

Register design files, original images, and font assets separately from code, identifying editable items and license scope. Source files do not imply unrestricted use across all media, and handing third-party materials to the company does not automatically expand their licenses. [Brand design files and copyright handover](https://www.jvds.cn/en/share/brand-design/brand-design-copyright-deliverables) can supplement this category.

For analytics, search, tag management, notification email, and other operational assets, prioritize appropriate permission handover within existing assets to retain historical records. Creating another account may break historical comparisons. Check events, reports, recipient rules, and recovery routes. Schedule removal of unnecessary tools according to their actual impact.

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562397230-524049.webp)

Conceptual illustration of export routes for the CMS, content, and media files

## Separate Licenses, Renewals, and Maintenance From Claims of Permanent Availability

For fonts, images, themes, plugins, maps, video, email, and cloud services, record the purchaser, licensed or subscribed item, usage scope, expiration conditions, renewal owner, and consequences of discontinuation. One-time delivery, ongoing hosting, and external subscriptions are distinct matters.

Where a license belongs to the supplier’s account, check whether transfer is permitted, a separate purchase is required, or an alternative can be used. Follow the specific terms and project agreement. Do not promise that everything is transferable, or assume permanent dependence on the same supplier is the only option. Confirm permissions, file delivery, and contractual rights separately.

Renewal reminders need a company recipient and a review process after personnel changes. Verify payment methods, automatic renewal, and validity periods from actual records. “Activated” does not mean still valid years later. Ending a subscription may affect display, sending, or a feature; explain this from the real configuration instead of substituting a generic alarming checklist.

For ongoing maintenance, explain how defect handling, content changes, security updates, and new requirements are distinguished, who receives incident reports, and how problems should be reported. JVDS Design Studio’s website delivery and maintenance scope follows the project agreement and can be confirmed item by item in discussions of [corporate website development services](https://www.jvds.cn/en/service/web). Do not assume a fixed free-support period or unlimited revisions.

## Use a Personnel-Change Exercise to Confirm More Than Additional Access

At the handover meeting, have company administrators log into key assets and actually edit representative content. Have incoming technical staff test deployment and backup restoration, then verify actual receipt of notifications and alerts. A demonstration by the original supplier alone does not establish that the company can operate independently.

Also address emergencies: how to recover if an administrator loses access, who renews certificates and domains, who updates API credentials, and which contact takes over incidents. For tasks that cannot be completed, record the reason, owner, and deadline for supplying what is missing. Signing a handover document must not conceal problems.

After confirming new control and maintenance arrangements, revoke temporary access that is no longer needed. Assess dependencies before rotating shared credentials to avoid suddenly disrupting services. Necessary maintenance access should use individual identities and an agreed scope, with periodic review.

Keep the asset register updated as versions, accounts, and external services change. Success means the company can locate and control agreed assets, incoming staff can complete representative tasks from the documentation, recovery routes have been verified, and remaining limits and responsibilities are traceable.

![Artwork](https://www.jvds.cn/upload/2026/0824/1787562398977-550582.webp)

Conceptual illustration of four practical actions to complete at a handover meeting

## Frequently Asked Questions

**Does taking over a domain simply mean changing its password?**

Not necessarily. Check the account, registered holder, DNS, and renewal responsibilities separately. A password is only part of the access method.

**Does complete source code guarantee migration to any host?**

No. Environment, dependencies, platform conditions, data export, and licenses also require checking. Confirm the currently feasible scope through a test deployment.

**What if the company has no technical staff?**

Have a suitable technical specialist perform independent verification. The company remains responsible for ownership, payment, and business arrangements. A lack of developers does not justify losing control of key assets.