Who Owns Your Website? A Business Owner's Guide to Agency Handover

Your logo is on the homepage. Your business paid for the project. Your team can edit a paragraph. Those facts still do not answer every question hidden inside “Who owns our website?”

A website is a collection of accounts, content, software, design assets, data and service relationships. The business may control some parts, license others and depend on an agency for access to the rest. The practical problem usually appears when someone needs to renew the domain, change providers, investigate a missing enquiry or bring in a new developer.

The best time to clarify ownership is before the project starts. The next best time is while the relationship is working well. This guide provides an operational checklist for that conversation and a structured handover process. It is not legal advice or a substitute for reviewing your contract with a qualified professional.

If you are still comparing suppliers, read Webcurry's guide to choosing a web design agency. Here, the focus is narrower: understanding what your business controls and what must be documented or transferred.

The short answer: ownership has four separate layers

Ask four different questions instead of relying on one broad assurance:

• Rights: What content, design and code can the business use, modify and transfer under its agreements and licences?

• Account control: Who holds the owner or primary administrator role for each important service?

• Operational access: Can the business complete essential tasks without waiting for one particular person?

• Portability: What can be exported, transferred or rebuilt if the business changes suppliers or platforms?

These layers overlap, but they are not identical. An administrator can have technical access without settling copyright questions. A contract can describe rights without supplying the credentials needed to operate a service. A platform-account transfer does not necessarily export the website to a different technology.

Start with an asset register, not a password request

Create a shared inventory with one row per asset or service. Record its purpose, provider, business owner, current administrator, billing contact, renewal date, access method and handover status. Add a separate column for the relevant agreement or licence.

Include the domain, DNS service, hosting or website platform, email, analytics, Search Console, design files, repository, premium extensions, booking tools, CRM connections and backup arrangements. If the website takes payments, include the payment service as a separate operational relationship rather than assuming it moves with the website.

Do not put passwords, recovery codes or secret keys into an ordinary handover spreadsheet. Use the provider's role invitations and an appropriate secure credential-sharing process where necessary. The register should tell you where control resides, not become a collection of exposed credentials.

An agency that manages these services can help complete the register. The goal is reliable continuity, not removing useful professional support.

1. Domain registration: who can renew and manage the name?

The domain is the address customers use to reach the business. Identify the registrar, the recorded registrant information, the account controlling the registration and the people receiving renewal notices. Check whether the registration is held through the business's own account or an agency-managed arrangement.

ICANN's guidance for registrants explains the relationship between a registrant and registrar and the management responsibilities associated with a domain registration. Exact rules and transfer processes can differ by domain ending and provider, so check the documentation applicable to your registration.

Ask practical questions: can an authorised business representative reach the account, see the renewal date, update contact details and identify the support process? Who pays the renewal, and what happens if the usual contact leaves?

Domain registration and DNS are different controls

The registrar account and the service hosting your DNS records may be different. DNS can direct website traffic and email to separate providers. Document both before requesting changes. Moving a website does not automatically require moving the domain registration, and a domain transfer is not a substitute for planning the website migration.

2. Hosting or platform account: distinguish owner from editor

An editor role may allow someone to change text without managing subscriptions, inviting administrators or transferring the site. Ask the provider to show the actual roles and permissions rather than relying on the informal word access.

For a business-controlled arrangement, identify the appropriate owner account and give the agency the access needed for its work. Some managed-service contracts use a different structure; if so, the agreement should explain that structure, the service obligations and the exit process clearly.

Check which business email receives account notices and how account recovery works. Avoid a continuity plan that depends entirely on an employee's personal inbox or an agency contact who is no longer assigned to the project.

Also separate billing from ownership. The person paying an invoice may not hold the account-owner role. Record both and test the important administrative tasks during handover instead of discovering restrictions during an urgent change.

3. Website copy, photographs and brand assets

List what the business supplied, what the agency created and what came from third parties. These groups may have different permissions and delivery requirements. Keep the relevant agreements and licence records with the project files.

For written content, confirm the deliverables covered by the engagement and the agreed rights to reuse or modify them. For photography, illustrations, icons, fonts and video, ask what licence applies and whether there are restrictions on transfer, editing or use outside the website.

Request usable originals where they are part of the agreement. A compressed image downloaded from a live page may not replace the agreed high-resolution source. Equally, do not assume that every stock asset includes an unrestricted editable source file.

If AI-generated assets are involved, document the tool and any applicable commercial-use terms. Have someone review the output for inaccurate business claims, unintended branding and inappropriate representations. The word generated does not answer every rights or suitability question.

4. Design files: ask what is actually included

The finished page and the editable design project are different deliverables. A contract may include one, both or a specific set of exports. Clarify this before work starts, especially if your internal team will create future pages or marketing materials.

Useful handover assets can include a component library, colour and typography specifications, responsive layout notes, image guidelines and editable source files. Identify the software required to open them and whether the business needs its own subscription.

Ask whether the design project uses agency-owned shared libraries or third-party assets. A copied file can still depend on resources that are not accessible to your account. Test opening and editing the agreed deliverables rather than accepting a folder link as proof of a complete handover.

The objective is not to demand every internal sketch or rejected concept. It is to receive the agreed materials needed to operate and extend the final design responsibly.

5. Code, repositories and custom functionality

If the project includes custom code, identify where it lives and how it is deployed. A zip file can contain source code while omitting the configuration, dependency information or build instructions needed to run it.

Ask for the agreed repository access, deployment instructions, environment-variable names, integration documentation and a description of any externally hosted components. Secret values should be transferred through an appropriate secure process, not placed in a public repository or casually pasted into documentation.

Distinguish project-specific work from pre-existing agency tools and third-party libraries. Ask which parts are assigned, licensed or provided as a managed service. Have the relevant agreement reviewed if those distinctions are unclear; technical possession does not resolve the legal interpretation.

For continuity, another competent developer should be able to understand the supported setup. That does not mean every unfamiliar developer will maintain it without onboarding, but it should not depend on undocumented knowledge held by one person.

6. Themes, plugins, apps and recurring licences

Create a renewal list for every paid dependency. Record what the subscription provides: software access, updates, support, usage capacity, hosting or a connection to another service. Ask whether it belongs to the business, the agency or a third-party account.

Do not assume that a tool stops working immediately when a subscription ends, or that it continues unchanged forever. Behaviour varies by provider and product. Check the actual licence and subscription terms and record what would need replacing if the agency engagement ends.

For each dependency, answer: is it essential to a customer journey, can the business purchase its own licence, and who will perform that change? This prevents a routine supplier change from becoming an unexpected rebuild.

Webcurry's website maintenance budgeting guide can help organise the cost categories. Use the providers' current invoices and terms for the amounts and obligations that apply to your website.

7. WordPress ownership: include more than the dashboard

For self-hosted WordPress, review the domain, hosting account, WordPress users, database, uploaded media, theme, plugins and any external services separately. A WordPress administrator login does not necessarily provide control over hosting billing or the domain registration.

The WordPress software licence states that WordPress is released under GPLv2 or later. That does not mean every photograph, logo, commercial service subscription or item of project documentation has the same licence. Keep software licensing separate from the rights and service terms attached to other assets.

Ask what a complete recovery would require. Confirm who holds backups, what they contain, where they are stored and whether a restore has been tested. The WordPress backup guidance distinguishes database and file backups. A content export and a complete operational recovery package should not be treated as interchangeable without checking their contents.

Finally, document customisations. A future maintainer needs to know whether changes sit in a child theme, a custom plugin, a page-builder template or another component. Unrecorded customisation makes even ordinary updates harder to assess.

8. Wix ownership: check the transfer and subscription boundaries

For a Wix website, distinguish being a collaborator from holding ownership of the site. Establish which Wix account should own the finished website and what access the agency should retain for the agreed support arrangement.

Wix documents a premium-site transfer process, including associated services and transfer restrictions. Review the current process for your particular site rather than assuming every subscription or connected account moves automatically. Wix Payments accounts, for example, are not transferred between Wix accounts through that site-transfer process.

Ask the agency to list what transfers, what remains separately managed and what needs action from the business. Verify acceptance of the transfer, future billing responsibility, domain arrangements and business-email continuity where applicable.

A transfer between Wix accounts is also different from moving the website to another platform. If future portability matters, discuss what content and assets you can retrieve and what would require rebuilding elsewhere. Make that decision with realistic expectations before committing to the platform.

9. Shopify ownership: separate the merchant from collaborators

For Shopify, identify the store owner and the agency's collaborator relationship. Shopify's partner documentation distinguishes stores created for client transfer from collaborator access to stores the merchant already owns. The working arrangement should match the intended long-term control.

Check domains, theme arrangements, apps, integrations, payment services and billing individually. A store handover is not finished simply because the business can add a product. The people running operations need to understand orders, notifications, refunds, stock updates and the services involved in those workflows.

Record custom theme changes and the method used to deploy them. If the agency maintains a separate code repository, agree how it is handed over or licensed and how future changes will be coordinated.

Do not remove the previous team's access before checking dependencies and agreeing a transition plan. First establish the business's access and verify ordinary operations, then adjust collaborator permissions in a controlled way.

10. Analytics, Search Console and lead data

Your website may be published in one platform while its measurement and customer data live elsewhere. List analytics properties, Search Console access, tag-management containers, advertising connections, CRM destinations and form-submission storage.

Ask who can manage users and settings, not just view a report. A monthly PDF is useful reporting, but it does not replace the business's agreed access to its measurement systems. Record property identifiers so a future supplier does not accidentally create duplicate tracking.

For enquiries, document the complete route from form submission to inbox or CRM. Verify where records are retained and what the business can retrieve under its policies and applicable obligations. Do not move customer data to a new provider without considering those requirements.

Keep measurement changes separate from the account handover where possible. If traffic, tags and permissions all change at once, it becomes harder to establish why reporting looks different afterwards.

An illustrative handover: a small service business

Imagine a maintenance company that wants a new agency to manage its existing website. The owner has an editor login, but the outgoing supplier handles the domain, platform subscription and form integration. The first step is an inventory, not an urgent password reset.

The business and both suppliers agree a handover window. They identify the domain registrar, current DNS service, website owner account, licence dependencies and the CRM receiving enquiries. They record the current configuration and preserve the agreed recovery materials before making changes.

Next, the business accepts the appropriate ownership or administrator invitations. The new maintainer confirms access, edits a harmless test item where appropriate and checks the published enquiry journey using clearly labelled test data. The teams verify that email and the domain still behave as expected.

Finally, they record remaining issues, confirm ongoing billing and adjust outgoing access according to the agreed transition. This is a hypothetical workflow, not a promise that every provider supports an identical transfer or that contractual disagreements can be solved technically.

A practical handover acceptance checklist

Treat handover as a small project with evidence of completion. Work through the following checks with the responsible people:

• The asset register names the business owner and provider for every critical service.

• The appropriate business representatives can access their agreed owner or administrator roles.

• Domain renewal, DNS, website billing and email arrangements are understood.

• Agreed source files, content, documentation and licence records have been delivered.

• Custom functionality has deployment and maintenance notes where applicable.

• Forms, bookings or checkout journeys have been tested after the transfer.

• Analytics and Search Console access are recorded, with no accidental duplicate setup.

• Backup or recovery arrangements and responsible contacts are documented.

• Open issues, support boundaries and future renewal responsibilities are acknowledged.

• Outgoing access is reviewed only after necessary continuity checks are complete.

Record the date, the person who checked each item and any unresolved exception. An exception is better documented than hidden behind a blanket statement that everything has been handed over.

Questions to settle before signing with an agency

Ask the agency to explain the proposed ownership model in writing. Which accounts should the business create? Which can the agency create and later transfer? What assets are licensed rather than assigned? What happens to agency-managed subscriptions when support ends?

Also ask about the handover trigger and process. It may be tied to agreed milestones or commercial terms, which should be understood before the project begins. If a disagreement arises, refer to the agreement and appropriate professional advice rather than attempting to bypass account controls.

Add the answers to the final scope. The web design proposal checklist covers the wider delivery questions around timelines, acceptance and ongoing support. Ownership is one part of a workable relationship, but it is too important to leave as a verbal assumption.

Frequently asked questions

Does paying an agency mean I own every part of the website?

Payment alone does not describe all the rights, licences and account arrangements involved. Review what the agreement says about content, design, code and third-party assets, and separately verify operational access. A website can contain business-owned material alongside licensed software and services. Obtain qualified legal advice where the rights are unclear.

Should my business control the domain account?

Your business should understand and agree how domain control, renewal and recovery are managed. A business-controlled account can simplify continuity, while a managed arrangement needs clear responsibilities and an exit process. Verify the actual registrant and provider records rather than relying on a verbal statement that the domain is yours.

Is a website administrator login enough for a complete handover?

No. It may cover content editing while leaving the domain, billing, hosting, analytics or integrations elsewhere. Use an asset register to identify the required access for each service. Then test the ordinary administrative tasks your team must perform and document any functions that remain with an agreed service provider.

Can I transfer a Wix website to my own account?

Wix provides a site-ownership transfer process, subject to the site's services and applicable restrictions. Review the current transfer guidance and confirm which subscriptions, domain and email arrangements are included. Treat payment services and other connected accounts separately, and verify that the recipient has accepted the transfer before calling the handover complete.

Does a Shopify collaborator own my store?

Shopify distinguishes collaborator access from store ownership. A collaborator can be authorised to work on a merchant-owned store without owning it. Check the actual owner role, the permissions granted and any separate client-transfer arrangement. Also review apps, domains and billing so the business understands all dependencies around the store.

Do I need the original design files?

You need the deliverables agreed for operating and extending the site. Editable design files can be valuable, but their inclusion should be explicit rather than assumed. Confirm the required software, linked assets and relevant licences. Ask for enough documentation to keep future changes consistent with the approved design.

What happens to premium plugins when I leave an agency?

The answer depends on the product, subscription and agency arrangement. Some dependencies may need a new business-owned subscription or a different maintenance plan. Ask the provider what changes when the current licence ends and document the transition. Do not assume every tool stops immediately or remains fully supported indefinitely.

Can I move a website to another platform without rebuilding it?

Not necessarily. Account ownership, content export and platform portability are different things. Check what the current platform can export and what the destination can import. Layouts, custom features and integrations may need rebuilding. Plan the move around the actual assets and supported processes rather than the general promise of website ownership.

Should I remove the old agency's access immediately?

Use a controlled transition agreed with the relevant parties. First verify business access, dependencies, recovery arrangements and essential journeys, then review outgoing permissions. Urgent security concerns may require a different response from the appropriate administrator. Do not bypass ownership controls or treat a contractual dispute as a technical permission problem.

What if an agency refuses to hand over an account?

Review the agreement, invoices, provider records and written correspondence to establish what was promised and who controls the account. Ask for a documented explanation and use the provider's legitimate ownership or recovery process where appropriate. Seek qualified advice if there is a dispute; technical access should not be obtained by circumventing controls.

Ownership should make continuity easier

A successful agency relationship does not require the business to manage every technical detail. It does require a clear answer to who controls each important asset, what the business is entitled to receive and how the site continues operating when people or suppliers change.

Before your next build or redesign, bring that asset register into the conversation with Webcurry. Clear responsibilities at the start make the eventual handover a planned milestone rather than a stressful surprise.