A website can be live, paid for, and impossible for the business to manage safely.
The domain may sit in a former employee’s account. The developer may be the only person who can reach the hosting service. Form submissions may go to an inbox nobody checks. A backup may exist without anyone knowing how to restore it. The site works today, but one expired card or lost login could turn an ordinary update into an emergency.
A good website handoff prevents that problem by assigning control, maintenance, renewal, and recovery separately. It does not assume that one person must perform every task. It makes sure the business knows who can do each task, how that access is recovered, and what happens when a provider relationship changes.
This article uses “ownership” in that operational sense. Legal rights to code, copy, photography, fonts, designs, and other assets depend on contracts and licenses. A handoff checklist cannot decide those rights for you, but it can expose the questions that still need an answer.
Separate four kinds of ownership
The sentence “we own the website” can hide four different claims.
Legal rights
Who has the right to use, edit, transfer, or reuse the site and its assets? The answer may differ for custom code, licensed software, stock photography, fonts, plugins, and written content. Record the relevant contract or license instead of relying on a verbal summary.
Account control
Which person or organization controls the domain registrar, DNS, hosting, content system, source repository, analytics, and other services? Account control determines who can make a change today. It does not automatically answer who owns the underlying work.
Maintenance responsibility
Who handles content corrections, software updates, form failures, accessibility issues, broken links, security notices, and ordinary support? A provider may maintain the site while the business controls the primary accounts. That can be a healthy arrangement when the boundary is written down.
Recovery authority
Who can restore access or service when the usual operator is unavailable? Recovery may depend on a verified email address, a second administrator, registrar support, backup files, billing records, or a documented rollback process. If nobody has tested the route, it is only a recovery assumption.
The purpose of the handoff is not to make the owner a webmaster. It is to keep the business from depending on an invisible single point of failure.
Start with the domain
The domain is the public address customers use. Losing control of it can affect the website, email, and other services connected through DNS.
ICANN describes a domain registrant as the person or entity that registers a domain and enters into an agreement with a registrar. Registrants manage the domain through that registrar and have responsibilities related to registration information, renewal, transfer, and security. ICANN also explains that registration contact information must remain accurate under the applicable registration agreement.
For the handoff, record:
- the domain name and registrar;
- the registrant or account holder shown by the registrar;
- the business-controlled email address used for notices and recovery;
- the expiration date and renewal setting;
- the payment owner;
- who may change nameservers, DNS records, transfer settings, and contact details;
- the support and recovery route.
Auto-renew is helpful, but it is not a complete continuity plan. A stored card can expire. A notice can go to an abandoned inbox. An administrator can leave. Confirm the payment method, notice destination, and backup administrator without changing live DNS.
Do not move a domain or rewrite DNS simply to make the checklist look complete. Domain, email, verification, and security records can share the same zone. Inventory the current state first, then plan any change with a tested rollback path.
Inventory every system behind the page
The visible site is usually the front of several connected systems. Your inventory should include the systems required to publish, operate, measure, and recover it.
Hosting and delivery
Record the hosting provider, account owner, service plan, billing owner, renewal date, support route, and any content-delivery or security service in front of the host. Confirm where production configuration lives and who is allowed to change it.
Source files and content system
Identify the authoritative version of the site. That may be a source-code repository, a hosted site builder, a content management system, or a combination. Record how a change moves from draft to production, where media files live, and how the current version can be exported.
Do not accept “the developer has the files” as a source-control policy. The business needs a durable way to identify the version that is live and retrieve the material it is entitled to receive.
Contact paths and business email
Follow each form, booking button, phone link, checkout link, and support address. Record the destination, account owner, and person responsible for responding. A form that displays a success message but delivers to an abandoned inbox is not a working customer path.
Search and analytics access
Measurement accounts need their own handoff. Google documents separate roles for Search Console owners and users and for Analytics account and property access. Access granted at one level can carry different permissions than access granted at another.
Confirm that the business has an appropriate administrator or verified owner, that provider access is assigned to individual accounts when the platform permits it, and that stale access can be identified. Do not share one password to avoid learning the permission model.
Licensed assets and paid services
List themes, plugins, fonts, stock images, maps, booking services, form tools, email services, and other paid dependencies. Record who purchased each item, what use is permitted, whether updates require an active subscription, and what happens if it is not renewed.
A file in the website folder is not proof that the business may reuse it forever or move it to another project.
Copy this website ownership matrix
Use one row per system. Add rows when the site depends on separate vendors, properties, repositories, or accounts.
| System or asset | Business-controlled account | Day-to-day owner | Renewal or billing owner | Recovery or export route | Last verified | Open issue |
|---|---|---|---|---|---|---|
| Domain registration | | | | | | |
| DNS and email records | | | | | | |
| Hosting and CDN | | | | | | |
| Source repository or site builder | | | | | | |
| CMS administrators | | | | | | |
| Forms, booking, or checkout | | | | | | |
| Analytics and Search Console | | | | | | |
| Backups and rollback artifacts | | | | | | |
| Fonts, images, themes, and plugins | | | | | | |
| Support and maintenance agreement | | | | | | |
“Business-controlled account” does not mean every service must use the exact legal business name. Provider account models differ. It means the business has durable, authorized control that does not disappear when one outside provider or staff member leaves.
Do not put passwords, recovery codes, private keys, or payment details in the matrix. Record the approved vault or recovery process, not the secret itself.
Secure access without creating another lockout
Each person should use an individual account when the service supports it. Give the provider the access required for the work, and keep higher-risk administrative privileges limited to the people who need them.
NIST’s Cybersecurity Framework 2.0 Small Business Quick-Start Guide recommends multifactor authentication for accounts that offer it and limiting access to people who need it. Apply the strongest supported method the business can operate reliably.
Then document recovery. Know which email address, device, administrator, support process, or stored recovery material is required. A security control that only one unavailable person can satisfy may protect the account while still leaving the business locked out.
When a provider relationship ends, do not delete access first and discover the dependency later. Verify the replacement administrator, source files, production path, billing, recovery method, and customer-facing workflows. Then remove access that is no longer needed and preserve a record of the change.
A backup is not the same as a recovery plan
A backup answers, “Do we have another copy?” A recovery plan answers, “Can the right person use that copy to restore an acceptable version within the business’s operating constraints?”
Record:
- what is backed up;
- how often it is captured;
- where it is stored;
- who can access it;
- how long it is retained;
- which configuration, database, uploaded files, and external dependencies are not included;
- how a restore or rollback is performed;
- when that process was last tested.
NIST’s small-business guide recommends regularly backing up data and testing backups; its recovery guidance separately asks businesses to assign recovery responsibilities and assess backup integrity before restoration. Treat those as separate handoff controls too. A hosting snapshot may not include the domain, email routing, analytics, third-party forms, licenses, or the instructions needed to rebuild the complete service.
Test recovery in a bounded way. Restore into a non-public location, verify an export can be read, or rehearse the documented rollback against a safe fixture. Do not take a working production site offline merely to prove the plan exists.
Run a website handoff acceptance drill
A folder of credentials is not acceptance evidence. Run a short drill while the current builder or provider is still available.
- Sign in independently. A business-authorized person signs in to the registrar, hosting, authoritative source, and measurement accounts without borrowing the provider’s session.
- Confirm roles. Verify the business’s administrative control and the provider’s named, appropriately scoped access.
- Trace one customer path. Submit a clearly labeled test through the main contact, booking, or purchase path and verify the expected destination and confirmation. Do not treat the test as a real lead or sale.
- Identify the live version. Connect the public site to a recorded source version, export, or deployment record.
- Check renewal continuity. Confirm the expiration date, notice inbox, billing owner, and support route without making an unnecessary purchase or account change.
- Exercise safe recovery. Read an export, restore a non-public copy, or run the approved rollback drill. Record exactly what the check proves and what remains untested.
- Review access. Identify stale users, tokens, and verification methods. Remove them only after continued control has been established.
If a step fails, record the exact system, impact, current owner, and condition required to close it. Do not mark the handoff complete because the homepage still loads.
Set the maintenance rhythm before the launch team leaves
Ownership decays when every check is tied to a one-time project.
Assign a practical review rhythm:
- Routine: customer forms, booking paths, checkout destinations, broken links, and public facts that change often.
- Monthly or quarterly: administrator lists, backups, updates, analytics access, support queues, and unresolved errors, according to the site’s risk and change rate.
- Before renewal: domains, hosting, paid plugins, certificates where applicable, and licensed services.
- After a role or provider change: account access, recovery methods, billing responsibility, source ownership, and support routing.
- After a significant release: the original customer task, a bounded rollback check, and the ownership matrix.
The exact interval should fit the business. A frequently changing store needs a different schedule from a five-page information site. The important part is that each review has a named owner, evidence, and a response when something fails.
Our small-business website launch checklist covers the work from source facts through production verification. The five-minute website brief helps establish the business facts before the build begins. This ownership matrix handles the part that comes next: keeping the website controllable after the launch team steps away.
The handoff is part of the website
A finished website is not only a set of pages. It is a maintained relationship between public content, business accounts, customer paths, source files, licenses, renewals, backups, and people.
The business does not need to perform every technical task. It does need to know who is responsible, what access exists, what evidence proves the site can be maintained, and how control survives an ordinary personnel or provider change.
If your site is live but its ownership and recovery path are unclear, talk to Fireproof Studio about a website handoff or maintenance project. We can start by mapping the systems and open questions before recommending changes.