Website Handover Checklist: Verify Ownership, Access and Your Exit Plan

Your new website is live. The final invoice is ready. Then someone asks a simple question: could another developer operate it next month without borrowing the agency founder's login? A polished launch does not answer that question. A usable handover does.

The direct answer: a website handover should give the business verified control of the relevant accounts, the agreed editable assets and data, a clear record of third-party rights and costs, and instructions that another authorised team can use. Check those deliverables through a controlled handover exercise. Receiving a password list or a ZIP file alone does not establish ownership, completeness or operational independence.

This guide is for Indian business owners commissioning or taking over a website in 2026. It focuses on evidence at the transfer point, rather than ongoing support targets. Examples are fictional planning exercises, not WSC client records or contractual promises. The actual rights and deliverables depend on the signed agreement and applicable provider terms.

Define what is being handed over

Start with the business capability you bought. A brochure website, an online shop and a custom customer portal have different dependencies. List the live domain, application, content, customer-facing integrations and operating accounts. Include the staging environment if it forms part of the agreed deliverable. Identify which items are transferring and which remain provided as an ongoing service.

Separate legal rights, account control and technical possession. Your team might possess an export without permission to reuse a licensed photograph. It might have permission to edit content without access to deploy application changes. It might pay hosting invoices while the recovery address belongs to a former employee. These are different gaps, requiring different evidence.

Agree boundaries before the last week

Put the handover schedule in the project plan. The website design brief template helps turn business requirements into agreed responsibilities before development begins. Ask what happens after approval, final payment and the end of any support period. Identify who supplies each item, who accepts it and how an incomplete item is resolved. Do not invent new rights at sign-off or assume that a supplier's reusable tools become your exclusive property.

Use the website quotation comparison worksheet when defining deliverables before purchase. At handover, the task changes: demonstrate that the agreed items exist, are current and can be used. Where the contract is ambiguous about rights or restrictions, obtain appropriate professional advice rather than treating technical access as a legal conclusion.

Build an account and dependency register

Create one concise register with the service, account identifier, business owner, current administrator, recovery route, billing owner, renewal date and transfer requirement. Store secret values in your approved password manager, not in the register. A record can identify where a credential is held without exposing it in a spreadsheet emailed to several suppliers.

Cover domain registration, DNS, hosting, content administration, code storage, deployment, backups, business email, analytics and search tools. Add services actually used by the website: transactional email, maps, booking, payment processing, search or storage. A dependency is relevant even when it has a free allowance or no invoice this month.

Distinguish ownership from delegated work

Prefer business-controlled accounts with named users and suitable roles where the provider supports them. The developer can retain authorised access for support without being the only person who can recover the account. Record exceptions, such as an agency-managed platform, and specify the export, migration or replacement options the business receives.

Test an invitation through acceptance and a fresh sign-in. An email saying that access was granted is incomplete evidence if the invitation expired or points to another account. Confirm the correct website or property after login. A screenshot of a familiar dashboard is useful only when its identity and permissions are clear.

Evidence that makes a website handover reviewable

Deliverable	Useful evidence	Question it answers
Domain control	Correct domain in the business-controlled registrar account; recovery and renewal reviewed	Can the business maintain registration?
Editable build	Current source, dependency instructions and controlled setup demonstration	Can an authorised replacement team work on it?
Design and media	Agreed editable files plus asset-level licence records	What can be changed, reused or transferred?
Measurement	Correct property identifiers and verified business permissions	Will existing reporting remain accessible?
Supplier exit	Sequenced access changes and post-change checks	Can responsibilities change without losing essential functions?

This is an acceptance aid, not a certification. Adjust it to the platform and agreed scope. A hosted service may provide supported exports rather than server source code. The important point is that its limits are understood before the business relies on a transfer that the provider cannot perform.

Verify domain and hosting control

Open the registrar account using the business's own authorised identity. Check the exact domain spelling, registration details available in the account, expiry, renewal settings, payment route and recovery contacts. Document who receives expiry notices. Do not make a surprise registrant change or begin a registrar transfer simply to demonstrate access.

For generic top-level domains, ICANN explains transfer eligibility and possible restrictions. A change to registrant details can affect when an inter-registrar transfer is permitted. Confirm the current rules with the registrar before sequencing changes; country-code domains may follow different registry policies. Avoid promising a universal transfer timetable.

Keep DNS and email visible

The registrar, DNS provider and web host can be three different companies. Record each separately. Retain a current DNS export or readable record inventory in a protected location. Identify website records, mail routing and verification records, with their owners. Changing nameservers without accounting for email can affect a service that was outside the design brief.

Record the authorised process for obtaining a transfer code when required. ICANN describes an authorization code as a protection used in generic-domain transfers. It is a sensitive value, not a permanent item for a general handover PDF. Share it only through the agreed secure channel when the transfer is actually authorised.

For hosting, confirm the correct subscription and website directory or application identity. Establish whether access covers only this site or a shared account containing unrelated customers. A handover must not expose another client's files or credentials. Ask for an appropriate isolated account, delegated access or provider-supported migration when separation is necessary.

Check continuity without changing production

Ask the technical team to show where the live release, database and uploaded media reside. Record certificate management, scheduled tasks and the deployment route. The business does not need to run server commands during a meeting. It needs a capable authorised operator to confirm the map is accurate and explain the safe process for future changes.

Keep continuity checks separate from a live migration. Moving hosting, changing DNS and replacing email credentials together makes problems harder to isolate. Agree individual steps, approval points and a fallback before touching production. Handover can be accepted in stages when the remaining dependencies and responsibilities are explicit.

Inspect source files, data and licences

A folder named final does not prove that its contents match the live website. Ask for a release identifier, date and description connecting the delivered files to production. Include the agreed application source, custom themes or extensions, database structure, configuration instructions and content exports. Document exclusions rather than quietly assuming every service can be copied.

For a repository, check who controls the organisation, who can administer access and whether the business can obtain the relevant history and branches. GitHub's repository transfer guidance shows why transfer alone is insufficient: existing collaborators and associated deployment mechanisms need review. Have the technical owner inspect permissions and integrations after any authorised transfer.

Ask for a usable setup record

The receiving developer should be able to identify required runtime versions, dependency installation, environment settings and the normal deployment procedure. Supply an example configuration with placeholders. Deliver real secrets through a protected system with clearly assigned custodians. Avoid hiding the only operational instructions inside one person's chat history.

Request a small, controlled setup demonstration away from the live website. Use sanitised test data and an isolated environment. The aim is to reveal missing dependencies and undocumented assumptions, not to duplicate every production record. Record what was demonstrated, what remains untested and who will close each gap.

Track editable design and usage rights

List agreed design source files, brand assets, original supplied content and current media. Identify stock photos, fonts, icons, themes and plugins separately. For each third-party item, retain its source, licence or purchase reference, permitted use, renewal owner and any transfer restriction. Do not assume that a supplier's subscription follows the website automatically.

An editable file and a usage licence solve different problems. A flattened banner may be usable but expensive to revise. A premium template may work today while future updates depend on an agency subscription. Ask for the permitted alternative if a licence cannot transfer. Record the accepted replacement cost or limitation without representing it as an unexpected technical defect.

CMS content exports also need context. Check whether they include media, redirects, product relationships and custom fields, or only text. WSC's CMS editing demonstration guide helps assess everyday editing. The handover question is whether the business retains the agreed content and supported export route when the operating team changes.

Retain analytics and search access

Record the analytics account and property identifiers, website stream, tag deployment location and responsible administrators. Sign in through an authorised business user and verify the correct property. Access to a report link is different from the ability to manage permissions. Keep measurement continuity visible when the agency relationship changes.

Google's Analytics access guidance distinguishes account-level and property-level administration. Review the actual scope granted to the business rather than treating every invitation as equivalent. Choose permissions appropriate to the responsibilities and record any retained agency access.

For Search Console, identify the exact property and its verification method. Google's ownership guidance distinguishes verified owners from delegated owners. It also explains that removing access without addressing verification tokens can leave a route to regain ownership. Have an authorised specialist plan token changes while preserving valid business ownership.

Do not delete historical reporting or create replacement properties merely to make the account list look tidy. If a transfer or restructuring is needed, document what can and cannot move and the effect on reporting. The handover record should preserve identifiers, access decisions and known gaps, without promising that changing administrators improves rankings.

Run a practical handover exercise

Consider a fictional Delhi training business preparing to replace its website supplier. Its site includes course pages, enquiry delivery, a downloadable brochure and analytics. The outgoing team has supplied files and invited a business manager to several services. No customer data or actual WSC project is involved in this example.

First, prove account identity and recovery responsibility

The manager signs into the nominated business accounts and checks the domain, hosting subscription and reporting identifiers against the register. An invitation has gone to an old personal address, so that item remains open. The team agrees a supported correction and retest. Nobody records a pass simply because the invitation email exists.

Next, connect delivered files to the live release

The receiving developer identifies the release and sets up a sanitised copy using the supplied instructions. A brochure directory is missing from the export. The team adds it to the agreed delivery and checks a sample course page and download in the isolated environment. The record distinguishes this setup evidence from a full security or performance assessment.

Then, rehearse the dependency change

The enquiry service uses an agency-controlled sending identity. The teams document whether delegation can continue or a business-controlled replacement is required. They agree the change window, protected credential exchange and a controlled delivery check. Existing access stays available until the replacement is verified under the approved plan.

Finally, the business accepts the completed items and assigns dated actions for the rest. A handover issue log contains the item, expected evidence, current state, owner and retest result. This is more actionable than an email saying everything is transferred. It also lets both suppliers distinguish missing deliverables from newly requested work.

Plan the supplier transition in sequence

Agree who is authorised to approve account changes and who performs them. Start by establishing valid business access and confirming deliverables. Complete necessary provider-supported transfers. Verify the website's important journeys. Then remove access that is no longer required and rotate affected credentials through a coordinated plan.

Revoking everything at the start can disable deployment, backups or integrations before replacements are ready. Leaving every former user indefinitely creates a different problem. Use named responsibilities and verification between stages. Review human accounts, automation tokens, deployment keys, external integrations and recovery contacts, rather than focusing only on the CMS password.

Keep technical handover separate from commercial settlement and contractual disagreements. Document unresolved items and use the agreed escalation route. This guide does not establish payment withholding rights or determine intellectual-property ownership. It provides a practical evidence framework for the people implementing the agreement.

For ongoing response and recovery commitments after transfer, use the website maintenance agreement guide. Handover should leave the incoming operator with the agreed materials and control; maintenance defines how that operator supports the service afterwards.

Handle hosted platforms and agency services explicitly

Some websites depend on a platform that supplies the hosting, application and updates as one service. In that arrangement, requesting the provider's complete software source may be neither available nor part of the purchase. Ask instead what the business account controls, what data can be exported, which design elements can be retained and what a replacement platform would require.

Likewise, a shared agency tool may remain the agency's property while your business receives a defined service. Record that dependency honestly. Ask whether another supplier can take over the configuration, whether the service can continue under a separate agreement, or whether a replacement must be commissioned. These options have different cost and continuity implications. A documented limitation is easier to evaluate before launch than during a hurried exit.

Agree how incomplete evidence affects acceptance

Classify gaps by their consequences. Missing access to the domain recovery route deserves different attention from an optional design reference that was never included in scope. Record whether a gap blocks the agreed transfer, permits conditional acceptance or belongs to a separately approved enhancement. Avoid automatically treating every preference as a launch blocker.

For a conditional item, state the temporary arrangement, accountable person, completion date and retest. If the business accepts continued reliance on a supplier-controlled service, document how access, renewal and termination will work during that period. A vague promise to sort it out later leaves the same uncertainty in place.

Retain a concise acceptance record after the meeting: register version, delivered release, files received, demonstrations performed, open exceptions and the people who approved the result. Keep private screenshots and account identifiers in a protected business location. Share redacted evidence with reviewers who do not need operational access. This makes later changes understandable without distributing credentials or customer records.

Revisit the register when a new integration, employee or supplier is added. The handover is a dated checkpoint, not a permanent guarantee that control will remain correct. Assign one internal custodian to maintain the record and arrange a review when responsibilities change. That modest administrative step protects the usefulness of the original work.

Avoid common website handover mistakes

• Accepting access without checking identity. Verify the exact domain, subscription and property, not just a successful login.
• Treating payment as proof of every usage right. Check the agreement and third-party licence conditions.
• Keeping secrets in the handover spreadsheet. Record secure locations and custodians instead.
• Accepting a stale export. Connect files to a known release and demonstrate the agreed setup.
• Changing DNS without mapping email. Preserve unrelated services and verification records.
• Removing the outgoing team too early. Establish and test replacement access before planned revocation.
• Signing off undocumented exceptions. Give each remaining gap an owner, consequence and next action.

Use the website handover sign-off checklist

• The agreement identifies deliverables, rights, exclusions and acceptance responsibilities.
• The register names accounts, business owners, billing and recovery routes.
• Domain, DNS and hosting control are verified separately.
• Business access has been accepted and tested against the correct service.
• Current source, content and media match the agreed release.
• Setup instructions and protected configuration exchange are usable.
• Third-party licences, renewals and transfer limits are recorded.
• Analytics and Search Console identities and permissions are checked.
• A controlled exercise reveals missing dependencies without exposing live customer data.
• Access removal, credential changes and journey checks have a sequence.
• Open issues have owners, retest evidence and explicit acceptance decisions.

Make a proportionate handover decision

A small brochure site needs less documentation than a custom trading platform. Both need a truthful answer to who controls the essential assets and how another authorised person could continue the work. Ask for evidence proportionate to the system, and recognise supported platform limitations before approving a transition.

Build these requirements into the original brief, review them before launch and close gaps while both teams are available. For help defining the scope of a new or replacement website, contact Web Solution Centre with your current platform, dependencies and handover questions. Confirm the proposed deliverables and terms rather than assuming a standard package covers every item.

Sources

• ICANN: domain transfer considerations
• ICANN: authorization codes
• GitHub: repository transfers
• Google Analytics: access management
• Google Search Console: owners and permissions

Sources checked on 29 October 2026. Photography: SHVETS production, Ron Lach, Anna Shvets on Pexels, used under the Pexels licence. All photographs are illustrative, with no client, employee or endorsement claim.