A website can be live, beautiful and apparently finished while the business still does not truly know how to operate it.
The problem usually appears later: the domain renewal goes to an old email address, nobody has administrator access to analytics, the contact form depends on an account owned by the designer, or a new developer cannot find the source code.
That is why website handover should be treated as a real project stage, not a final email saying “all done.”
Before final payment or formal project closure, verify this chain:
ownership → access → operation → measurement → recovery → support
The goal is not to remove the designer from every account. It is to make sure your business can keep functioning if that designer is unavailable tomorrow.
1. Confirm who controls the domain
Start with the domain because everything else can become difficult if the business loses control of its address.
Record:
- the registrar holding the domain;
- the registrant or business responsible for it;
- the account used to manage it;
- the recovery email or responsible role;
- the renewal date and who pays it;
- whether two-factor authentication is enabled where available.
ICANN explains that the registrant is the individual or entity that registers a domain and that registrants have rights related to managing, renewing and transferring the registration. It also notes that the registrant of record or administrative contact is important when initiating a transfer. See ICANN’s information for domain registrants and its domain transfer guidance.
A developer can manage DNS for you. That is different from the business having no idea where the domain lives or how to recover it.
2. Map hosting, deployment and DNS separately
“The website is hosted online” is not enough documentation.
A modern site may have the domain at one registrar, DNS at another provider, the frontend on a deployment platform, images in separate storage and email somewhere else entirely.
Your handover should name each important service and what it does.
For example:
- Domain registrar: where the domain registration is managed.
- DNS provider: where records point the domain to web, email and other services.
- Hosting/deployment: where the website actually runs.
- Storage/CDN: where uploaded files or media live, if separate.
- Email provider: where business email is delivered.
You do not need to understand every DNS record. You do need an operating map so the next responsible person knows where to look.
3. Verify CMS or admin access with a real edit
If the project includes a CMS or admin area, do not treat “login created” as proof that handover is complete.
Log in with the business account and perform one ordinary task the team will actually need to do: change a phone number, publish an article, replace a team photo, update a room, edit a service or change an announcement.
This catches a common handover problem: the client technically has an account, but the permissions or editing model do not match the promised workflow.
Also document what the team should not edit. A good admin experience is not the same as unrestricted access to deployment settings, database policies or payment secrets.
4. Make sure analytics belongs to an account the business can keep
Analytics history becomes more valuable over time. Do not leave it trapped inside one freelancer’s personal account.
For Google Analytics, verify that the appropriate business-controlled Google account has the access level it needs. Google supports adding users at account or property level and assigning permissions rather than sharing one password. See Google Analytics user and access management.
Then test that tracking is actually receiving production traffic. “Analytics installed” and “analytics working” are different statements.
If important actions are meant to be measured, confirm those too: form submissions, booked calls, purchases, registrations or other meaningful conversions.
5. Verify Search Console ownership and sitemap access
Search Console is easy to forget because the website works without it. That does not make it optional for a business that expects organic search to matter.
Confirm that the business has appropriate access to the correct Search Console property and that the property is not dependent on one outside person’s account for ownership.
Also verify the production sitemap and canonical domain. A redesign or migration can look perfect while Google is still being pointed at old URLs, a staging host or incomplete indexing signals.
If the project changed URLs, the handover should also include the redirect plan rather than leaving it inside the developer’s memory.
6. Test every lead, booking or payment path after launch
A handover is not complete because the homepage loads.
Test the actual commercial journeys in production:
contact form → stored enquiry → notification → human response
booking → confirmation → calendar or operational system
checkout → payment confirmation → order state → receipt or fulfilment
Use realistic test data and confirm the destination, not just the success message shown to the visitor.
A form can say “sent” while its notification email is failing. If that is happening, use my separate guide on contact forms that say sent when the email never arrives.
7. List every recurring cost and renewal owner
The build price is not the whole operating cost.
Your handover should list recurring services that can stop the site or an important feature if they expire. Depending on the project, that can include:
- domain renewal;
- hosting or deployment;
- email;
- CMS or plugin licences;
- booking software;
- payment or commerce subscriptions;
- image or file storage;
- monitoring;
- premium fonts, stock assets or APIs.
For each one, record what it does, who owns the account, who pays, and when it renews.
This is more useful than a folder containing random invoices.
8. Receive the source assets you are entitled to keep
The exact deliverables depend on the contract and stack, so do not assume every project includes the same files.
Where applicable, confirm delivery or access to:
- website source code or repository;
- approved logos and brand assets;
- final copy and content files;
- original or licensed images and their usage terms;
- design source files if included in scope;
- database/export procedures where relevant;
- documentation for important integrations.
For a custom application, repository ownership and deployment access matter much more than receiving a ZIP file once. For a managed website platform, the important handover may instead be account ownership, admin roles and export limitations.
The question is not “Did I get a folder?” It is “Could another qualified person maintain or move this system with what we have?”
9. Document recovery, backup and failure paths
Ask what happens when something breaks.
Where are backups kept? Who can restore them? How often are they created? What happens if the domain account is locked? Who receives service alerts? If an integration fails, where would somebody see the error?
Do not accept “we have backups” as the whole answer. A backup that nobody can locate or restore is only a comforting idea.
For a simple marketing website, this section can be short. For an app handling users, payments or business records, it should be much more explicit.
10. Separate passwords from the handover document
The handover document should identify accounts, owners, responsibilities and access routes. It should not become a permanent list of passwords, API keys and recovery codes.
Use account invitations and role-based access where the service supports them. Where a credential genuinely has to be transferred, use an appropriate secure method and rotate it when necessary.
That also makes offboarding cleaner later: access can be removed without changing one shared password used by five people.
11. Define what happens after handover
A final source of confusion is the sentence “support is included.”
Included for how long? For what kind of problem? Through which channel? What counts as a bug from the original scope, and what counts as a new request?
Write down:
- the post-launch support window;
- the contact route;
- expected response times if promised;
- what maintenance covers;
- what is billed separately;
- who is responsible for future content and software updates.
A clean handover does not end the relationship. It removes dependence and makes any ongoing relationship deliberate.
The final test: could the business operate without the original designer for 30 days?
That is the simplest handover test I know.
Could the business renew the domain, receive enquiries, make routine content changes, see its analytics, verify search performance, identify recurring bills and give a new qualified developer the access they need?
If the answer is no, the project may be launched, but the handover is not finished.
If you are commissioning a website and want the ownership, editing, analytics and post-launch operating model planned before development begins, see my web design service or contact me.
