Who owns your business website? An access and handover checklist

Separate the agreed rights from the accounts you can use

A working website can hide an awkward dependency: the only person who can renew the domain, restore a backup or invite another developer is someone outside the business. Start the conversation before a build begins, or while your existing provider is still available to help.

Ask the proposal to identify the custom work, supplied content and third-party products, and to explain what your business receives and can use when the engagement ends. Then check practical access separately. A folder of files is useful only if the next person knows how it relates to the live website.

WordPress.com provides a clear platform example: the site owner and subscription owner can be different people. Its documentation says a site owner cannot renew or cancel a subscription owned by another administrator. An administrator login alone therefore does not settle every handover question.

Keep readingCompare agency scope and responsibilities

Check the domain record and the person who can manage it

For a com.au domain, auDA says a developer registering it on your behalf should use your business’s registrant details. Those details identify the licence holder. Check the record through auDA’s WHOIS service and ask the registrar to explain any mismatch; having a password does not by itself establish that the registration details are correct.

Record the registrar, renewal date, renewal contact and the account used to manage DNS, which directs services connected to the domain. Confirm who can receive account recovery messages. Keep the business’s authorised contact involved even when a provider handles the technical work.

Treat a website move and an email move as separate tasks in the plan. Ask the technical owner to identify which DNS records support the current website, email and other services before changing them. A handover should explain what each planned change affects.

Keep readingPlan a full domain name change

Make a handover register the next person can actually use

Use one row per service. Record its purpose, provider, account or project identifier, business owner, current agency access, renewal responsibility and a short acceptance test. Keep passwords and recovery codes in your approved password manager, with the register pointing to their secure location.

Include only the services your website actually uses. For a custom build, ask for the source repository, deployment instructions and the location of configuration needed to run it. For a hosted website builder, ask what can be exported or transferred and what depends on the existing subscription.

• Domain and DNS: recorded registrant, renewal contact and authorised access.
• Website platform and hosting: account ownership, administrator role and billing contact.
• Files and content: repository or export, original images, design files and applicable usage terms.
• Forms and connected tools: where submissions arrive and who handles delivery failures.
• Measurement: the correct Analytics, Search Console and other reporting properties.
• Recovery and support: backup location, restore procedure and the person responsible after handover.

Test the handover while both parties are available

Hold a short screen-sharing session using the business’s own authorised accounts. Have the receiving person open the correct website project, find the billing settings, locate a backup and make a harmless edit in a preview. Record what worked and what still needs action. Watching the departing provider use their login is not the same test.

Hypothetical example: a business can edit its homepage, but the hosting subscription still belongs to the previous developer. Mark content access complete and billing transfer outstanding. Assign the remaining task and a completion date, then repeat that check after the transfer. Avoid calling the whole handover finished because one login worked.

Where the platform supports it, use individual invitations and roles matched to the work. Arrange the replacement access and recovery route before removing the old access. Keep any agreed maintenance access explicit, with a named person and review date.

Keep readingPlan the wider website launch checks

Check reporting access and a real enquiry handoff

Google Analytics distinguishes viewing reports from managing users. Its Administrator role can manage access; the Editor role cannot. Check the actual role on the correct account or property, and decide who in the business must be able to invite a replacement provider.

Search Console has a separate ownership system. Google explains that removing a verified owner does not remove their verification tokens, which can allow them to regain access. Ask the technical owner to review the relevant tokens during offboarding and check other services that may rely on them before removal.

With permission, submit a clearly labelled test enquiry. Confirm the form result, receipt in the agreed destination and the person responsible for follow-up. Record enough detail to reproduce a failure without placing real customer information in a widely shared handover document.

Agree who looks after the website after handover

Close with a short responsibility list: who renews services, updates content, maintains software, checks form delivery and responds to an outage. Name the contact and escalation route. Separate work included in an ongoing engagement from changes that need a new brief.

Keep unresolved items visible. A missing export, unclear subscription owner or untested restore process needs an owner and next action. Review the register when a provider, staff member or core platform changes so it remains useful.

When discussing a custom website with Demandify, bring the current website, your intended enquiry journey and this access register. Ask for the build, launch and handover responsibilities to be included in the scope, alongside any ongoing support you need.