Website Project Handoff Checklist

Website handoff is often compressed into one email: "Source code is attached; admin credentials are below." Six months later, when a certificate expires, a form fails, or an employee leaves, the company discovers it needs not an archive but asset records that support recovery, maintenance, and accountability.

Organize handoff across accounts, code, data, content, licenses, and operations. The principle is simple: the corporate entity owns core assets, roles receive only daily permissions, and every critical operation has backup and recovery procedures.

01 Create a Master Website Asset Register

The master register is the future entry point when people change, not an appendix to a technical checklist. For every item, record platform, URL, purpose, owner, administrators, renewal date, two-factor authentication, and recovery. Store actual passwords in a corporate password manager, not the register.

02 Remove Domains and DNS from Personal Control

Register the domain with a corporate email, enable two-factor authentication, and assign at least two administrators. Verify registrant, expiration, automatic renewal, and payment method at handoff.

Export and archive DNS records and document the system each serves. Do not delete unfamiliar TXT records; they may support email, certificates, search verification, or third-party services.

03 Hosting, CDN, and Backups Must Support Independent Recovery

Handoff requires more than an IP and password. Document OS version, deployment path, processes, database, certificates, logs, monitoring, backups, and updates. The company should own the cloud master account and grant vendors subaccounts.

A backup task labeled "successful" does not prove recovery. Test restoration regularly. Preserve code, databases, and uploads and define retention and offsite backups.

□ Highest privileges for hosting and cloud projects;

□ Differences among production, test, and preview;

□ Commands for deployment, restart, rollback, and troubleshooting;

□ Database and file backups and restoration steps;

□ Monitoring, alerts, and log access;

□ Security-update, certificate, and renewal ownership.

04 Validate That Source Code Can Build and Deploy

The repository should contain the final release, commit history, dependency lockfiles, sample environment variables, and README. Document licenses and alternatives for commercial plugins and private components.

The most direct acceptance is asking a new developer to deploy once in a test environment from the documentation. If every step requires the original developer, the documentation is incomplete.

05 CMS, Content, and Media Need an Exit

The company should control CMS administrator accounts and understand roles, publishing, trash, versions, and media handling. Content sites also need content-model and field documentation.

Confirm that articles, products, cases, forms, and media can be exported. A platform that works today may not be permanent; without data portability, future choices are locked in.

06 Preserve Analytics, Search, and Marketing Accounts

Retain historical data in Analytics, Search Console, Tag Manager, advertising pixels, and heatmaps, with the company as administrator. New accounts break before-and-after comparisons.

Review events, forms, UTM rules, and reports, and ensure no vendor personal email is the sole owner. Disable unused tools to reduce scripts and privacy burden.

07 Organize Licenses and Renewals Before Fonts or Plugins Disappear

Commercial fonts, stock, themes, plugins, maps, video, and email services may renew annually. Record purchaser, license scope, invoice, renewal date, and the impact of cancellation.

If a license belongs to the vendor account, transfer it or have the client repurchase before project close. Do not wait for a function to fail to discover that a license cannot transfer.

08 Complete Four Live Actions in the Handoff Meeting

After sending documentation, hold a meeting where the client logs into critical accounts, reviews deployment, edits content, and triggers a backup. The vendor explains known issues and future maintenance boundaries.

Afterward, remove unnecessary temporary accounts, rotate shared passwords, and archive meeting records and the final checklist. Update the asset register for accounts and configurations added during maintenance.

1. Corporate administrators log into domain, cloud, CMS, and code repository;

2. A third party deploys or publishes content in a test environment;

3. Trigger and restore a backup and confirm monitoring alerts;

4. Sign off on unresolved issues, maintenance scope, and response contacts.

09 Run a Team-Replacement Drill on Handoff Day

Complete files do not prove a new team can take over. Ask someone uninvolved in development to follow the documentation for local startup, test deployment, content changes, backup restoration, and DNS lookup. Add every step that still requires the original developer.

Include emergencies: recovering administrator access, alert recipients, third-party key updates, and domain-renewal notifications. Asset gaps often appear only when staff leave or vendors change.

After handoff, rotate temporary passwords and keys, revoke unnecessary permissions, and save a read-only asset register. Handoff does not merely give a new team access; it returns control to the company.

Frequently Asked Questions

Should every password be changed during handoff?

Rotate shared or vendor-held credentials; revoke permissions for personal accounts. Assess service impact before rotating keys.

Can the domain remain in the vendor's account?

Avoid it long term. The corporate entity should control the domain and grant the vendor necessary permissions.

Can the original vendor still access the server after handoff?

It depends on maintenance terms. Use individual least-privilege accounts and review them regularly.

How can a company without technical staff complete handoff?

Hire an independent technical advisor to validate ownership, portability, and backup restoration at minimum.

Must handoff documentation be maintained afterward?

Yes. Versions, accounts, architecture, and third-party services change, so the register should remain a living operating document.