“You own it” should survive a real handoff.

What website ownership actually means.

Ownership is not a single checkbox. A practice may own original design and code while still renting hosting, licensing a typeface, embedding a scheduling service, or depending on a proprietary content system.

The useful question is not only “Do we own the website?” It is: what can we access, move, edit, export, continue using, or replace without the current vendor?

The eight layers to inspect.

1. Domain registration

Identify the registrar, registrant, administrative access, renewal method, and recovery information. A domain can point to a website without being controlled by the practice.

2. Hosting and deployment

Know where the site runs, who owns the billing relationship, whether it can be transferred, and what happens when the agency relationship ends.

3. Source code and repository

For a custom build, clarify access to the complete source, version history, build instructions, dependencies, and the repository where development occurs.

4. Content and media

Distinguish practice-supplied content, agency-created content, stock assets, commissioned photography, embedded media, and anything licensed only for a specific use.

5. Design files and brand assets

Editable masters, exports, fonts, tokens, component libraries, and usage guidelines have different practical value. Ask what is included and in what formats.

6. Analytics and search accounts

Review account-level access for analytics, Search Console, tag management, call tracking, and other measurement systems—not only emailed reports.

7. Integrations

Scheduling, forms, email, CRM, payments, maps, chat, and automation may use separate vendors, credentials, data rules, and billing.

8. Documentation and portability

A transfer is safer when the stack, environment settings, deployment steps, licenses, vendors, and known limitations are documented.

Questions to ask before the agreement.

• Which deliverables become ours, and when?
• Which accounts will be opened in the practice’s name?
• Will we have administrator and repository access during the engagement?
• Which components are proprietary, licensed, rented, or non-transferable?
• Who pays each third-party vendor, and what survives cancellation?
• Can another qualified developer deploy and maintain the site?
• What export, documentation, and credential handoff is included?
• What happens to forms and stored data during offboarding?
• What support channel, response expectations, update process, and separate costs apply after launch?

A practical offboarding checklist.

1. Inventory every vendor, account, credential, file, repository, integration, and billing relationship.
2. Confirm domain and DNS access before changing hosting.
3. Export source, content, databases when applicable, media, design masters, and configuration documentation.
4. Preserve analytics, Search Console, advertising history, conversion definitions, and reporting context.
5. Map current URLs and redirects before any rebuild or platform move.
6. Rotate credentials after the handoff without disabling services prematurely.
7. Verify the new deployment, forms, scheduling, measurement, redirects, and backups end to end.
8. Document unresolved licenses, subscriptions, and vendor dependencies.

Important limits.

This guide and the self-assessment are operational checklists, not legal advice. Contract rights, copyright ownership, privacy obligations, healthcare rules, data-processing terms, and license interpretation require qualified professional review.

“Open source,” “custom,” and “admin access” do not automatically mean that every element is transferable or that no subscription remains. Verify the actual agreement and vendor terms.