Small-Business Website Ownership Handoff: A Vendor-Exit Checklist

Use this checklist when a business is taking control of its website from an agency, freelancer, employee, or former provider. It is not legal, tax, privacy, security, licensing, or registrar-specific advice; contracts and current provider terms control each handoff.

A small business can pay for a website for years without controlling the systems required to keep it online. The domain may be registered in a vendor account. Source code may exist only on one laptop. The public site may deploy from an unknown branch. Form submissions may route through a former employee's mailbox. Analytics and the Google Business Profile may list the agency as the only owner.

A vendor exit exposes those dependencies at the worst possible time. The solution is not a single download. It is a verified transfer packet that proves the owner can operate, restore, update, and reassign the website without depending on the outgoing provider.

What matters most

1. Possession and control are different. A folder of HTML does not confer control of the domain, DNS, hosting account, deployment keys, form endpoint, analytics property, business profile, licensed assets, or billing relationship.
2. Primary ownership should follow the business. Vendors can be delegated as users or managers. The business should retain an owner-controlled account, recovery method, and billing view for critical services whenever the provider supports that model.
3. Exports need restoration tests. A repository mirror, database export, media archive, or DNS zone is evidence only after the receiving team can inspect it, rebuild it, and explain how it would be restored.
4. Revocation comes after acceptance. Removing the outgoing team too early can interrupt a launch or erase the only recovery path. Leaving access indefinitely creates a different risk. Use a dated acceptance gate and revocation record.

How to complete the handoff

Freeze the handoff boundary

Record the effective date, current vendor, receiving owner, receiving technical contact, websites and subdomains, environments, and maintenance responsibilities included. State what is excluded: email administration, advertising accounts, photography rights, customer data, a separate CRM, or an unrelated application should not disappear into “website access.”

Pause nonessential changes during the final export and record the deployed revision. If work must continue, define who can change which environment and how the final difference will be reconciled.

Build an authoritative asset register

Use one row per asset or account:

Asset	Primary owner	Authoritative location	Export or transfer	Verification	Recovery contact
Domain registration	Business account	Registrar	Account change or registrar transfer	Registrant, expiration, lock, nameservers and renewal confirmed	Named owner and registrar support path
DNS zone	Business or approved infrastructure account	DNS provider	Zone export plus human-readable record list	Authoritative queries match expected records	Provider owner and emergency contact
Source code	Business-owned organization	Git host	Repository ownership transfer or mirror	Fresh clone, history, tags, branches and build pass	Organization owners
Hosting and deployment	Business account	Host/CDN	Owner role, project transfer, environment inventory	Known revision deploys to preview and production	Account owners and provider support
Database and uploads	Business account	Managed service or storage	Dated export and media archive	Restore rehearsal in an isolated environment	Data owner and technical custodian
Forms and email delivery	Business account	Endpoint and mail provider	Configuration export and verified recipients	Synthetic submission reaches the intended queue	Operations owner
Analytics and search tools	Business account	Analytics/Search Console platforms	Owner/admin role	Owner can view property, settings and history	Named marketing owner
Business profiles	Business owner	Listing platform	Owner role; vendor remains manager if needed	Owner can edit and manage access	Primary owner
Content and media rights	Business records	Repository/DAM/contract file	Originals and rights schedule	License, attribution, territory and term reviewed	Contract owner

Do not put passwords, private keys, recovery codes, customer exports, and ordinary inventory notes in the same shared spreadsheet. The register can identify where secrets are stored without exposing them.

Verify domain control without creating an outage

Record the registrar of record, registered name holder information available to the owner, account owner, recovery email and phone, expiration date, auto-renew state, billing method, transfer lock, authorization-code process, nameservers, DNSSEC state, and any registry-specific requirements.

Transferring a domain between registrars is not always required. Moving the domain into an owner-controlled account at the existing registrar may be enough. If a registrar transfer is selected, use the registrar's current workflow and ICANN transfer policy rather than copying an old checklist. Preserve the existing DNS service until the new authority and records are verified.

Capture the DNS zone before any change, including A, AAAA, CNAME, MX, TXT, CAA, verification, DKIM, SPF-related, DMARC, and service-specific records. Query authoritative DNS and common recursive resolvers before and after the transition. A screenshot of a provider dashboard does not prove what the public DNS is serving.

Transfer source as a reproducible system

The receiving team should obtain the Git repository with history, default branch, protected-branch rules, tags, releases, submodules, Git LFS objects, CI configuration, issue or migration records needed by the contract, and a map of deployment integrations. GitHub documents that a mirror clone can preserve repository files and revision history, while other platform metadata may need a separate export.

Require a clean-room test:

1. Clone into an empty directory using the access a future maintainer will have.
2. Follow the written runtime and dependency setup.
3. Build without undocumented files from the outgoing developer's computer.
4. Run the test suite and record versions and results.
5. Deploy to an isolated preview using newly issued credentials.
6. Compare routes, forms, metadata, redirects, analytics configuration, and critical assets.
7. Document how to roll back to the accepted production release.

A passing local build is not proof that production can be operated. A production deployment is not proof that the repository can be restored. Test both.

Inventory third-party dependencies and licenses

List fonts, images, video, themes, plugins, APIs, maps, review widgets, consent tools, form providers, email delivery, CAPTCHA, monitoring, CDN, payment services, and automation. For each, record the contracting account, billing owner, plan, renewal, usage limit, data handled, export path, license or terms reference, and replacement consequence.

Avoid transferring a vendor's multi-client API key or software license into the owner's repository. Create an owner-controlled subscription or document the approved continuing arrangement. Rotate secrets during the handoff and test the new credentials before retiring the old ones.

Preserve measurement and business identity

Transfer owner or administrator access for analytics, tag management, search tools, ad accounts in scope, call tracking, conversion endpoints, and the business profile. Preserve property IDs, data streams, event definitions, filters, exclusions, conversion definitions, audiences, consent settings, retention settings, and known reporting breaks.

Google's Business Profile guidance distinguishes owners and managers and advises against password sharing. The business can hold ownership while an authorized provider receives a delegated role. Record the primary owner, other owners, managers, recovery account, and the date former access will be removed.

Write the operating runbook

The handoff is incomplete until an unfamiliar but qualified person can answer:

• How does a content edit move from source to production?
• Which branch and commit are deployed now?
• How are preview and production separated?
• Where do form submissions go, and how is a failure detected?
• How are domains, certificates, dependencies, backups and licenses renewed?
• What is monitored, who receives alerts, and what is the response path?
• How is the prior release restored?
• Where are privacy requests, retention, and customer-data procedures documented?
• Which changes require business approval?

Include commands and links, but explain the expected result and failure path. A runbook made only of copy-and-paste commands becomes dangerous when an account, branch, or environment changes.

Use a two-person acceptance gate

The business owner confirms control, billing, and recovery. The receiving technical custodian confirms reproducibility and operation. Both review an exceptions register with owner, risk, due date, and workaround.

Acceptance evidence should include:

• Owner login and recovery verified for critical services
• Domain, DNS and renewal state recorded
• Repository cloned and built cleanly
• Preview and production deployments verified
• Forms and notification routing tested with synthetic data
• Backup inspected and at least one restore path rehearsed
• Analytics, search and profile access verified
• License and renewal schedule delivered
• Runbook and architecture map delivered
• Former access revocation date scheduled

After acceptance, revoke personal accounts, old deploy keys, shared passwords, stale OAuth grants, former webhooks, unused API keys, and obsolete recovery methods. Save a revocation log without storing the secret values.

What this checklist cannot decide

This checklist cannot determine contract ownership, copyright, work-made-for-hire status, privacy obligations, record-retention duties, tax treatment, or whether a provider must transfer a specific platform asset. It does not make a proprietary hosted system portable when the platform does not provide source or a complete export.

Repository mirrors may omit issues, pull requests, packages, discussions, hosted build artifacts, secrets, LFS objects, or provider-specific settings. Domain and Business Profile transfers can have waiting periods, verification requirements, and product-specific restrictions. Current provider documentation and qualified counsel should resolve the specific case.

The handoff also cannot prove that the inherited site is secure, accessible, compliant, accurate, or maintainable. Those require separate reviews.

Put the checklist into practice

A verified handoff needs more than a list of logins. Pair every asset with five facts: owner, authoritative location, transfer mechanism, acceptance test, and recovery contact. A clean build, isolated deployment, synthetic form test, restore rehearsal, and two-person acceptance review turn “we sent the files” into evidence that the business can continue operating.

The same register can be used at the start of a vendor relationship. Recording ownership and exit paths before work begins makes future transitions less disruptive and gives both parties a clear boundary. Mendola.Tech can help document and verify the handoff when a business needs an independent technical review.

Official references

• Transfer Policy — ICANN; accessed 2026-08-11. Supports using the current registrar-transfer policy and authorization process rather than an improvised domain handoff.
• A Registrant's Guide to Protecting Domain Name Registration Accounts — ICANN Security and Stability Advisory Committee; accessed 2026-08-11. Supports registrant account control, recovery, and domain-account security planning.
• Backing up a repository — GitHub Docs; accessed 2026-08-11. Supports mirror cloning for repository files and revision history and notes limitations of other archive formats.
• Manage your Business Profile owners and managers — Google Business Profile Help; accessed 2026-08-11. Supports owner/manager roles and individual account access rather than shared credentials.
• Business eligibility and ownership guidelines — Google Business Profile Help; accessed 2026-08-11. Supports owner control and the authorized representative's responsibility to transfer profile ownership on request.