Website Handoff: An Ownership Checklist for Businesses

A website handoff is not complete when someone emails a password and a ZIP file. It is complete when the business can identify the accounts that keep the site running, recover access, understand its responsibilities, and obtain help without depending on one person’s memory.

This guide is for owners commissioning a website, changing agencies, or reviewing an older arrangement. It is an operational checklist, not a legal opinion about ownership under a particular contract. Use it to make the assets, permissions, recurring costs, and handoff obligations concrete before an urgent situation forces the conversation.

What does website ownership actually include?

Separate legal rights, account control, and operational knowledge. They are related but not identical. A contract may grant rights to custom work while a provider controls hosting; an owner may control a domain while lacking the files needed to rebuild the site. A useful handoff identifies each layer explicitly.

Start with six asset groups: domain and DNS, hosting and deployment, source code and content, connected services, analytics and search accounts, and documentation. For each group, name the account owner, administrators, billing contact, recovery method, and transfer or export process. Record where the evidence is stored without placing secrets in a general document.

Do not assume that paying an invoice transfers every third-party license or platform subscription. Photography, fonts, plugins, stock assets, and hosted software can have separate terms. Ask the provider to identify what is custom, what is licensed, and what depends on an ongoing subscription. Refer unresolved rights questions to the agreement and appropriate professional advice.

The practical question is: “If our usual provider is unavailable for two weeks, can an authorized person keep the business functioning?” You do not need every owner to become a developer. You need an arrangement that can survive staff changes, forgotten credentials, and ordinary vendor transitions without turning into an emergency.

Who should control the domain and DNS?

The business should know which registrar holds its domain, who is recorded as the registrant, how renewal is paid, and who can recover access. DNS administration may be delegated, but that delegation should be visible and reversible. Document the distinction between registrar, DNS provider, website host, and email provider.

Those services are often separate. Moving a website does not automatically move email. Changing nameservers can affect mail routing, verification records, and other services that have nothing to do with the homepage. Before any change, export or record the existing DNS configuration and identify the owner of each important record.

Use the ICANN domain-transfer FAQs as a starting reference for registrar transfers. Transfer eligibility and timing depend on the domain’s circumstances and applicable policies. Do not promise a same-day transfer before checking those conditions, and do not begin one just because the website host is changing.

Verify renewal notifications and recovery addresses. An account tied only to an employee who left years ago is a predictable continuity problem. Keep authorized business recovery routes current and use appropriately protected accounts. Never put a domain authorization code, backup code, or password into a public project ticket or shared marketing spreadsheet.

What hosting and deployment information is necessary?

Identify the production host, project, domain aliases, repository connection, deployment branch, and billing owner. Record how a release reaches the public domain and how to restore the prior version. A provider dashboard that says “deployed” is not enough if it belongs to an old project that no longer serves the site.

Ask for a simple architecture map. It should show the browser-facing website, any content management system, database, file storage, email service, and external integrations. Include which organization owns each service. The map does not need to expose secret values or internal infrastructure details to everyone; its purpose is to make responsibility understandable.

Confirm the difference between production and preview environments. A preview address may work perfectly while the real domain still points elsewhere. For handoff acceptance, visit the actual public domain and verify a harmless known change or release identifier. Record the authoritative project so the next person does not deploy to a stale connection.

Ask what the hosting bill includes. Build minutes, storage, bandwidth, functions, databases, and image processing may be billed separately. The handoff should identify recurring services and who receives budget alerts. Avoid exact future cost promises when usage can vary; document the assumptions and where the owner can inspect current charges.

What source files and content should be delivered?

Deliver the assets needed to understand, maintain, and rebuild the agreed website, subject to the contract and third-party terms. That commonly includes the source repository, content exports, original media where permitted, build instructions, and a list of dependencies. A compressed copy of rendered pages may not be a usable development handoff.

A repository should have a clear default branch and a readable history of the delivered work. Confirm that the business has the agreed access level and that another authorized developer can clone it. Do not place production credentials in the repository. If secrets were previously committed, merely deleting the visible file is not a complete response.

For a content-managed site, export representative content and explain the schema. Pages, posts, categories, authors, redirects, and media relationships may need more than a folder of HTML files. Test a small restore or import in a safe environment so the export is more than a theoretical backup. Document anything the platform cannot export cleanly.

Include editable design assets when they are part of the agreement. Distinguish them from final web images. An optimized photograph may not be suitable for a large printed sign; a flattened logo may not replace the original vector file. Make these limits visible during procurement rather than discovering them after the design tool subscription expires.

How should accounts and credentials be transferred?

Use named accounts, role-based access, and secure credential-sharing methods rather than circulating one administrator password. The receiving owner should demonstrate access and recovery. After acceptance, remove access that is no longer authorized, while preserving any provider permissions required by the continuing support agreement.

A password manager can support controlled sharing, but the tool alone does not define ownership. Decide who administers the vault, who can recover it, and which people need which credentials. Keep a separate nonsecret account register so an owner can locate services without exposing every secret to everyone who reads the handoff document.

Enable multifactor authentication where supported and maintain recovery procedures appropriate to the business. The CISA multifactor-authentication guidance is a useful baseline. Avoid making one personal phone the only route to a critical business account. Recovery needs attention before the device is lost or the person is unavailable.

Treat API keys and integration tokens as a separate inventory. A website can continue using credentials owned by a former provider even after dashboard access changes. Identify the issuing account, scope, expiry behavior, and rotation procedure. Plan changes carefully because rotating a key without updating the dependent service can break a working integration.

What should happen to forms, payments, and integrations?

Trace every business-critical integration to its owner, permissions, data destination, and failure path. Test controlled examples during handoff, not merely the presence of a configuration screen. Separate website maintenance from responsibility for the connected business account. An agency may build a payment interface without owning the merchant relationship.

Forms deserve particular attention. Confirm recipients, reply behavior, stored records, spam controls, and staff assignment. Use our contact-form testing checklist to verify the whole inquiry journey. A form that still sends to the outgoing developer’s inbox is not a successful handoff, even if the page looks correct.

For payments or bookings, distinguish sandbox tests from live transactions. Agree on any real test before executing it and reconcile the resulting records. Do not create charges, refunds, appointments, or customer emails casually as part of a broad “smoke test.” The evidence should say exactly which path was tested and which operational effects occurred.

Document the response to an integration failure. Who receives an alert? Can the business process requests manually? Is there a queue to reconcile when service returns? A short operational note is more useful than a list of API names without any explanation of what the team should do when one stops working.

Which analytics and search assets need attention?

Verify access to the analytics property, tag manager, search tools, business profiles, and any reporting dashboards included in the engagement. Record the property identifiers and account owners. A screenshot of a report is not a transfer of access, and a new empty property is not equivalent to the historical one.

Check that reports describe the correct domain and date range. Old agencies, staging domains, duplicate tags, and renamed properties can make this surprisingly confusing. Identify which events represent useful outcomes and which are merely interface interactions. A button click should not silently become a confirmed lead in the owner’s reporting expectations.

Preserve verification methods during a migration. A file or DNS record may support search-account access even though nobody notices it in ordinary website browsing. The Google site-move documentation discusses maintaining verification and related migration details. Review the relevant items before deleting old files or changing DNS.

Document reporting limits. Consent settings, browser blocking, missing integrations, and attribution rules affect what the owner can see. The handoff should explain those limits in practical language, not promise perfect tracking. Give the owner a baseline report and a schedule for reviewing meaningful changes with the person responsible for marketing decisions.

What documentation is enough for a small business?

Create a short runbook that answers common operational questions, plus links to deeper technical material. Include editing instructions, account ownership, release and rollback steps, backup and restore procedures, contact routes, and known limitations. The documentation should help another authorized person act, not simply prove that a document exists.

Record the tasks the business actually expects to perform: changing opening hours, publishing a post, replacing a staff photo, updating a service description, or reviewing a form inquiry. Use screenshots only when they clarify the current interface, and date them so future readers know they may become stale after a platform update.

For technical recovery, identify the last tested restore and the environment used. “Backups enabled” is not evidence that a restore works. Clarify which assets are backed up and which are not. Source code, uploaded media, database records, and third-party settings can require separate recovery methods and different retention periods.

A modest company does not need a hundred-page operations manual. It does need a usable first page: what runs the site, who owns it, who to contact, and how to avoid making a small problem worse. Organize the runbook around actions and decisions, with secret values stored securely elsewhere.

How do you accept the handoff rather than just receive it?

Use a live walkthrough in which the receiving owner performs the agreed tasks. Verify access, a safe content edit, the production release path, a controlled inquiry, and recovery documentation. Record open items with owners and dates. Do not mark the handoff complete solely because a folder was delivered.

Choose a low-risk edit for the demonstration and decide whether it belongs in staging or production. The purpose is to prove that the instructions work and that the receiving person has the right permissions. If the provider performs every action while the owner watches, you have demonstrated the provider’s access, not the owner’s readiness.

Have another authorized person locate the domain, hosting, and support details without prompting. This tests continuity in a way that a checklist signature cannot. If they cannot find a critical account, improve the register. If recovery requires an absent individual, resolve that dependency before treating the arrangement as resilient.

Finish with a status list: accepted, accepted with documented limits, or outstanding. Separate genuinely unfinished delivery from optional future improvements. This keeps the handoff fair to both sides and prevents the support relationship from becoming an undefined extension of the original build. For early-stage projects, establish these criteria in the website project brief.

Website continuity register

Complete this with the person who currently maintains the website and verify it with the receiving owner. Store only account names and secure references here, not passwords or recovery codes. Use a second authorized person to test whether the register is understandable without oral instructions. Record any access that depends on an individual who may be unavailable.

Use the notes to identify the next decision, not to create an appearance of completeness. Mark unknowns openly, assign an owner, and attach a safe evidence reference where appropriate. Do not put passwords, customer records, or private correspondence in a worksheet that will be shared widely.

Review the completed sheet with someone who actually performs the work. Ask them to walk through one ordinary example and one exception using only the recorded instructions. Update the unclear parts, then save a dated version. That small exercise turns a planning template into a practical operating artifact and gives future reviewers a clear starting point.

How should ongoing support be defined after handoff?

Define support hours, communication routes, response expectations, included work, exclusions, and responsibility for third-party fees. Distinguish an acknowledgment from a resolution commitment. Clarify whether new features, content production, analytics reviews, and emergency recovery are included, separately quoted, or owned by the business.

Use examples to test the agreement. Ask how a broken inquiry form, a new service page, an expired card, and an integration outage would be handled. These are different types of work. A useful support scope explains the path for each without pretending that every future issue can be priced or resolved in the same way.

Set a review cadence for the account register and runbook. Staff changes, platform migrations, and new integrations can quietly make a good handoff obsolete. Treat continuity as a maintained business asset. A brief periodic access review is generally easier than reconstructing the entire system during a provider transition.

If you need help assessing your current arrangement, contact Button Block. Our web development work can include an ownership and handoff review, scoped around the systems you actually use. The objective is a website your business can operate confidently, with clear rights, dependable access, and a support relationship everyone understands.